On Tue, Jan 5, 2016 at 5:18 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 5 January 2016 at 10:42, Brett Cannon <br...@python.org> wrote: >> ... >> >> First, we need to decide how we are going to handle adding all the core devs >> to GitHub. Are we simply going to add all of them to the python >> organization, or do we want something like a specific python-dev gteamroup >> that gets added to all of the relevant repos? Basically I'm not sure how >> picky we want to be about the people who already have organization access on >> GitHub about them implicitly getting access to the cpython repo at the end >> of the day (and the same goes for any of the other repos in the python >> organization). For tracking names, I figure we will create a file in the >> devguide where people can check in their GitHub usernames and I can manually >> add people as people add themselves to the file. > > I think we want at least one group to track CPython commit privileges > and potentially a second to track CLA signatories. > > For collecting GitHub username info, I think it makes more sense to > add a new User profile field in Roundup than it does to use a text > file in the devguide: > http://roundup.sourceforge.net/docs/customizing.html#tracker-schema >
Agreed. > That way whether or not someone has signed the CLA and whether or not > they have commit privileges is directly associated with both their > Roundup user ID and their GitHub one, but the latter is only linked if > they choose to provide it. > > It also means that if we eventually have a Roundup hook submitting > patches on behalf of people (perhaps triggered by a "Create PR" link > on the patch display rather than implicitly), it can set "Author" on > the PR correctly if the author has provided a GitHub username. > > We should also consider the question of who needs to be added to the > admin group for the GitHub python organisation. > >> Second, CLA enforcement. As of right now people go to >> https://www.python.org/psf/contrib/contrib-form/, fill in the form, and then >> Ewa gets an email where she manually flips a flag in Roundup. If we want to >> use a web hook to verify someone has signed a CLA then we need to decide >> where the ground truth for CLAs are. Do we want to keep using Roundup to >> manage CLA agreements and thus add a GitHub field in bugs.python.org for >> people's profile and a web hook or bot that will signal if someone has the >> flag flipped on bugs.python.org? Or is there some prepackaged service that >> we can use that will keep track of this which would cause us to not use >> Roundup (which might be easier, but depending on the service require >> everyone to re-sign)? There's also the issue of supporting people who want >> to submit code by uploading a patch to bugs.python.org but not use GitHub. >> Either way I don't want to have to ask everyone who submits a PR what their >> bugs.python.org username is and then go check that manually. > > The way kubernetes does this is that googlebot checks if the submitter > has signed the CLA, and if they have it sets a green "cla: yes" flag > on the PR: https://github.com/kubernetes/kubernetes/labels/cla%3A%20yes > > If they haven't, then it posts a message asking them to sign it and > applies a red "cla: no" label: > https://github.com/kubernetes/kubernetes/pull/19271#issuecomment-168836357 > > For us, I think the approach that makes the most sense depends on > whether or not it's easy to query the Roundup user DB based on a > custom field. If it's easy, then I think we should just have the bot > query Roundup to ask "Is this GitHub user id linked to a user account > that has signed the CLA?". > It should be easy. Best Regards, Ezio Melotti > If querying by custom field is a pain, then I think we should instead > have a GitHub group to track CLA signatories and tweak Roundup to add > someone to that group with their signatory status is updated. The bot > would then check the derived GitHub group rather than querying Roundup > directly. > _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
