On Thu, Aug 30, 2018 at 1:15 AM Mariatta Wijaya wrote:

- 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. 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 :) --Berker

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 ᐧ

On Wednesday, August 29, 2018 6:14:52 PM EDT Mariatta Wijaya wrote:

- 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)

It is possible to set the minimum number of lines changed required to trigger a CLA check. There's also a minimum number of files, although that seems less useful. Elvis

On Fri, 31 Aug 2018 at 09:36 Mariatta Wijaya wrote:

It is possible to set the minimum number of lines changed required to

...

trigger a CLA check. There's also a minimum number of files, although that seems less useful.

I find it is tricky with CPython. one line change in any .rst file, perhaps trivial. One line change in *.py or *.c file, might not be trivial and require CLA, issue number, news entry and so on. I guess if we do it this way, we need better guidelines of what requires CLA and what's not.

To see this in different perspective, if someone wants to propose a trivial change and then refused to sign the CLA, I think it won't be hard for us to find another contributor who has signed the CLA to make that change instead. So I'm inclined to make this a requirement.

If you chose to use that, I would prefer to use our own instance to

...

manage the database ourself, especially make backup. It would be bad for a legal point of view if suddently https://cla-assistant.io/ instance goes away and loose all its data.

I've pinged Ernest about this. He said it is reasonable for The PSF to host an instance of cla-assistant. And he will look into it.

I also wonder though, instead of hosting it ourselves, can't we just keep daily backups of the signed CLA? It's basically a list of GitHub usernames?

Perhaps that would be an easier task than hosting and maintaining it.

I think the key question is what sort of resiliency would we have in making this potential change? If we can backup the data regularly so that if we have to quickly turn around and either stand up our own instance of cla-assistant or tweak our CLA bot then I would assume this would take care of the biggest concerns people have. Basically we need to have a plan in place if the hosted cla-assistant disappeared today without notice. -Brett

Mariatta

ᐧ

On Fri, Aug 31, 2018 at 8:26 AM Elvis Pranskevichus wrote:

...

On Wednesday, August 29, 2018 6:14:52 PM EDT Mariatta Wijaya wrote:

...

- 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)

It is possible to set the minimum number of lines changed required to trigger a CLA check. There's also a minimum number of files, although that seems less useful.

Elvis

_______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@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

Thanks for all the inputs. I've chatted with Brett at the sprint about this, and this is our current thinking: - We will go with cla-assistant, hosted by them. - We will keep daily backups of signed CLA ( a list of GitHub usernames of people who have signed the CLA ) - We will keep daily backups of cla-assistant's source code I understand that people are worried about the possibility that the service suddenly go away without notice. I'm personally not too worried about it, but having a daily backups of both data and source code should keep us covered. With the backups, if the service go away suddenly one day, we can spin up our own version of it. In addition, the code for the-knights-who-say-ni will be made read-only and not deleted, and it can be re-activated. The reason I don't want to host our own cla-assistant is to reduce our burden of having to maintain it, keeping the server alive, updating the running service and the code every once in a while. And by "us", I actually mean the PSF infrastructure team, Brett, and myself who are volunteering to keep the CLA bot service up and running. For me, the sooner we can get cla-assistant set up, the easier all our life is going to be. So these are the things I plan to do today: - contact Ernest about getting daily backups in place - create the gist of the CLA, and have Van L review it - obtain an export of signed CLA from bpo as of today Mariatta ᐧ On Sat, Sep 1, 2018 at 9:25 PM Nick Coghlan wrote:

On Sat, 1 Sep 2018 at 02:53, Brett Cannon wrote:

...

On Fri, 31 Aug 2018 at 09:36 Mariatta Wijaya wrote:

...

I also wonder though, instead of hosting it ourselves, can't we just keep daily backups of the signed CLA? It's basically a list of GitHub usernames?

...

Perhaps that would be an easier task than hosting and maintaining it.

I think the key question is what sort of resiliency would we have in making this potential change? If we can backup the data regularly so that if we have to quickly turn around and either stand up our own instance of cla-assistant or tweak our CLA bot then I would assume this would take care of the biggest concerns people have. Basically we need to have a plan in place if the hosted cla-assistant disappeared today without notice.

Given the infrastructure that the PSF has already set up to handle the modern incarnation of PyPI, I suspect adding our own instance of cla-assistant to that (and hence being able to easily integrate it with the PSF's existing monitoring and management tools, like DataDog) will actually be easier than devising and managing a custom cla-assistant-specific disaster recovery plan.

'tis the beauty and wonder of combining traditional three-tier open source web applications with an automated app management platform like Kubernetes :)

Cheers, Nick.

P.S. See https://p.datadoghq.com/sb/7dc8b3250-85dcf667bd for the current PyPI/PSF metrics dashboard.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia