> > 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 CLA > 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 > strictly enforced). 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 infrastructure. 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 and > Betsy on the PSF staff (as I believe they're the ones that handle the eSign > -> bugs.python.org 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 that >> 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" trivial contributions like typo fixes. (FWIW, these days I will still wait for them to sign CLA anyway, even for typo fixes.) 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 trivial PRs. 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 we go. Changing this from "required" to "not required" is a matter of several 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, Ernest's time. 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 CLA anymore. 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. Mariatta ᐧ
_______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-le...@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
