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
ᐧ
Hi everyone,
After talking with Victor Stinner on some ideas on how to encourage
contributions to CPython and how to give more visibility to contributors
(see Victor notes: http://pythondev.readthedocs.io/community.html),
based on the https://thanks.rust-lang.org/ project (than in turn was based
on http://contributors.rubyonrails.org/) I have created the following
prototype
in my daily commute time:
https://thanks-python.herokuapp.com/
The project runs on Heroku at this moment, it fetches the latest changes
from the git
repository and updates every 30 minutes to get the latest information. You
can click on
any release to get the contributor names:
Example: https://thanks-python.herokuapp.com/tag/v3.6.5
(the names are obtained from the commit messages)
and you can in turn click any contributor name to get the list of commits:
https://thanks-python.herokuapp.com/contributor/Mariatta
You can also obtain a list of all contributors (all time contributors):
https://thanks-python.herokuapp.com/all_time
I want also to emphasize that this is just a very basic prototype made for
evaluating the idea and
the possible benefit that it has,
but is functional
:)
The repo is located here:
https://github.com/pablogsal/thanks-python
At this point is a very simple flask app with a celery worker running in
the background and a redis
interface for celery and for storing the git data (so is very easy to
bootstrap as the first thing it does
when started is to clone the repo and fetch the data again).
What are your opinions on the matter?
P.S. Don't be to critic on my horrible html and web design skills ;)
Regards from sunny London
Pablo Galindo Salgado
