1. Do we need to use their platform?
2. If they close the platform for any reason, there is the source code,
we could host it as well.
You'll also want to talk to Ernest (PSF Infrastructure director) about
either automating the periodic export of the csv file with all the
signatories, or else running the PSF's own instance of the service (which
may also provide some more freedom in making the check advisory rather than
I was thinking to just go with their platform, so we don't have to
maintain/pay for it.
I will check with Ernest if we can get this set up on our own
While I wouldn't expect them to object (since the proposal will save them a
currently manual step), it would be worth checking directly with Ewa
Betsy on the PSF staff (as I believe they're the ones that handle the eSign
step in the current process).
I've asked Ewa and Betsy just now, they're both ok with a new process
(using cla-assistant), and they also think it will be an improvement.
- Since the status check will be made required, it means every contribution
> no matter how trivial, requires CLA. Without it, we can't
merge the pull
> request. (Maybe only the admins can still merge). Sounds like this is a
> good thing anyway (for Python).
> I don't think this is a good idea. We are getting a good amount of PRs
> that fix typos or markup errors and requiring CLA would make people refrain
> from contributing to Python. Personally, I wouldn't bother contributing if
> I was asked to sign a CLA just to get a simple documentation fix merged.
Beyond that, my main concern would be the one Berker raised: the fact
> we allow reviewers to waive the CLA requirement for contributions that
> don't meet the standard of being copyrightable (most notably, typo fixes),
> is a feature, not a bug.
Fair point. We actually have several options here:
1. Always "require" the cla check to pass. But this could "block"
contributions like typo fixes.
(FWIW, these days I will still wait for them to sign CLA anyway, even for
2. "not require" the cla check to pass. This will allow any core devs to
merge the PR even if the cla was not signed.
3. "require" the cla check to pass, but allow only admins to merge the PR.
I've considered (3), but I kinda don't want to bother the admins to merge
I've thought of (2) as well, but in Zulip, Brett said, "we're talking about
legal stuff here, so paranoia typically wins out". And I think it makes
sense. His suggestion was to start with (1), and re-evaluate the policy as
Changing this from "required" to "not required" is a matter of
clicks in GitHub. (by an admin)
Also, the amount of work required just to make it usable on python/cpython
seems like a good indication that it's not worth the trouble :)
There are indeed some work involved to get this set up, probably mostly my
time (and a little bit of Brett's time), and if we host it ourselves,
If we use their platform, and not host it ourselves, most of the things are
done by clicking things on GitHub and cla-assistant, (trivial effort). The
biggest task will be to write up the gist, and writing the code to export
current status to a csv. I think these shouldn't take too long, perhaps one
afternoon during the sprint.
If we host it ourselves, it will take time from Ernest/ PSF Infrastructure
team to do the initial setup and then day to day maintenance. I doubt the
day to day maintenance will be any more than what we've been doing for
ni/bpo. But perhaps Ernest will know more about this.
Once it all set up, this will simplify the CLA signing process:
- new contributors don't have to wait at least one US business day for this
process to complete. It will be done in a matter of several clicks.
- new contributors don't have to create bpo account if they're contributing
to devguide or peps, or if they're fixing trivial typos
- saves time from Ewa and Betsy, so they don't need to manually check the
I think overall it is worth spending the time and effort to get the initial
setup going. At least I'm willing to do it for myself.