Following up from past thread about Improving CLA signing process (https://email@example.com/thread/2OY2KGVCKIRJDX325DGKZSVY2IKSDTJJ/
I've checked with Van, and from legal point of view, he has no problem with using cla-assistant, and he said that he can do what is needed to support it. Brett and Zach both sounds supportive too.
question: Is there any objection if we start using cla-assistant instead of the-knights-who-say-ni? (I'm going to take silence as :"no objection" :) )
What we will need to do order to start using cla-assistant:
- Export the currently signed cla info from bpo to cla-assistant. We need to come up with a .csv containing a list of GitHub usernames of people who has signed Python's CLA.
- Create a GitHub gist that represents Python's CLA and any additional info we need (some instruction here
- Install cla-assistant in Python organization on GitHub, and enable it for the various repositories: cpython, devguide, peps, core-workflow, bedevere, miss-islington. Perhaps we start with just devguide at first, and see how it goes.
- Update documentation surrounding CLA signing process.
- Make the cla status check required.
- We can remove the CLA signing page
, or keep it up only for those who submits patch to bpo
- I think we can stop maintaining the-knights-who-say-ni?
Things that we will lose if we go with this new workflow:
- Since cla-assistant works with GitHub usernames, people who has signed the CLA but did not associate their GitHub username will need to either associate their GitHub username before the move, or sign the CLA again once the move.
- since the cla status check will be required, we may not be able to "ignore"
- 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 can't check the CLA for people who contribute by submitting a patch in bpo. I guess in this case, we will fallback to the cla record in bpo. This situation should be quite rare. Most of us prefer GitHub PRs over bpo patch.
- Any other issue I didn't think of?
If nobody has strong objections or raised any issues, I plan to get this started and set up during Core sprint in a couple weeks.
I'm hoping we don't have to wait until we have the next BDFL/COP/TOP*/voting committee to decide on this.
BDFL: Benevolent Dictator For Life
COP: Council of Pythonistas
TOP: Trio of Pythonistas