[core-workflow] My initial thoughts on the steps/blockers of the transition

[Ezio Melotti]

On Tue, Jan 5, 2016 at 5:18 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 5 January 2016 at 10:42, Brett Cannon <brett at 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.
>