Mailman 3 September 2018 - core-workflow

Using CLA-assistant for Python
by Mariatta Wijaya March 6, 2019

March 6, 2019

Following up from past thread about Improving CLA signing process ( https://mail.python.org/mm3/archives/list/core-workflow@python.org/thread/2… ) Over in Zulip <https://python.zulipchat.com/#narrow/stream/130206-pep581/subject/CLA/near/…>, Yury suggested using cla-assistant <https://github.com/cla-assistant/cla-assistant>, which he used in EdgeDB project. 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 <https://github.com/cla-assistant/cla-assistant#request-more-information-fro…> ) - 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 <https://www.python.org/psf/contrib/contrib-form/>, or keep it up only for those who submits patch to bpo - check-python-cla.herokuapp.com can be shut down, there will be no more use of it. - 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. *acronyms: BDFL: Benevolent Dictator For Life COP: Council of Pythonistas TOP: Trio of Pythonistas ᐧ

8 11

"Awaiting merge" label for PRs from core devs
by INADA Naoki March 1, 2019

March 1, 2019

Hi. When core dev creates PR, "Awaiting merge" label is set automatically. It makes many "awaiting merge" PRs. It makes the label less useful, in my opinion. How about stop setting the label automatically? If the author wants review from other core-devs, they can set "awaiting core review" label manually. Other option is set "awaiting review" label instead of "awaiting merge", like PRs from other contributors. Regards, -- INADA Naoki <songofacandy(a)gmail.com>

6 10

DO-NOT-MERGE-UNTIL-3.9
by Ethan Furman Sept. 21, 2018

Sept. 21, 2018

Can we get the above tag added? -- ~Ethan~

5 5