Following up from past thread about Improving CLA signing process (
Over in Zulip
Yury suggested using cla-assistant
<https://github.com/cla-assistant/cla-assistant>, which he used in EdgeDB
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
- 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
- since the cla status check will be required, we may not be able to
- 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
When core dev creates PR, "Awaiting merge" label is
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.
INADA Naoki <songofacandy(a)gmail.com>
[Added core workflow and removed python-dev]
On Sun, Nov 11, 2018, 6:37 AM Stephane Wirtel <stephane(a)wirtel.be wrote:
> Do you think we could add a webhook for the build of the documentation
> for each PR where the build of the doc works?
I can setup webhooks for CPython. Do you have the URL for the webhook?
Or is this still in development?