Using CLA Assistant for Python

Core Workflow
1

Following up on previous thread in core-workflow mailing list and the original thread here, I’d like to get us start using CLA assistant for CPython in lieu of the-knights-who-say-ni.

(Sorry this has been taking too long for me to continue)

I’ve previously brought this up in the mailing list, and I’ve discussed this with various people:

  • with @brettcannon during core Python sprint
  • with @EWDurbin via emails and video chats
  • with Ewa, Betsy, Van via emails

Ernest had set up our own instance of the CLA assistant at: https://psf-cla-assistant-staging.herokuapp.com/

If you’d like you can install it in your own repo, or see a couple examples of how it works:


We’ve also asked several core developers to try it out and give feedback.

At this point, if there is no strong objection from the core developers, Steering Council and active core contributors, I’d like to get this rolled out soon (in the next couple weeks before I go OOOS).

The one important information with this new workflow:

Instead of trying to “migrate” our existing CLA records from bpo to CLA-assistant, we will be asking folks to re-sign the CLA in CLA-assistant. It will take several clicks, which might seem bothersome, but it will take effect immediately, instead of waiting for a staff from The PSF to review your CLA (one or two business days), and you only do this once.
(@EWDurbin can clarify in case I misunderstood this part?)

Other changes based on early testing (thanks to @willingc and Van L for feedback and clarification)

  • we’ve made bpo field optional in the CLA.
  • CLA will only be accepted under Apache v2 (removed the option of Academic Free license)

Let me know if you have any questions or concerns.

EDITED with link to the original thread in core-workflow ML: https://mail.python.org/archives/list/core-workflow@python.org/thread/2OY2KGVCKIRJDX325DGKZSVY2IKSDTJJ/

EDIT #2: The PSF still has records of your previously signed CLA. You will only need to re-sign if you make new pull requests to Python.

6 Likes
2

Can we have the PSF provide a very clear statement that the new CLA is identical to the old one and that this is purely for tracking purposes? That should help those of us who need to consult our own lawyers before signing any CLA. (Meanwhile, I’m also contacting my legal contact to get their opinion on this in case they either don’t care or care even more than I expect.)

3

Also, for those of us who didn’t follow the earlier threads, can you say a few words about what this is about? From clicking through a few layers of links I think the idea is just that CLA assistant has a nicer UX than our current stuff, and the goal is just to make it easier for contributors to get through the process. Is that right?

1 Like
4

I think we copy-pasted from the text from the old CLA, just removing the option to sign under Academic Free license. If you signed under Apache v2 before then it is the same. But let me try to get a hold of PSF legal on this.

5

The goal is to make it easier for everyone. Current CLA process requires PSF staff members to check the record, and then manually update your bpo’s record to state that CLA has been received. This process can take one to two business days. By using CLA assistant, not only we will free up time from PSF staff to do this manual work (that can actually be automated). In addition, speeding up the turnaround, first time contributors don’t have to wait two days for it.

I might not have referenced the right core-workflow thread, sorry. Please check also this other thread:
(the original thread)
https://mail.python.org/archives/list/core-workflow@python.org/thread/2OY2KGVCKIRJDX325DGKZSVY2IKSDTJJ/

3 Likes
6

This is legally identical to the prior CLA, with exactly the same scope and effects.

Thanks,
VanL (w/ PSF hat on).

6 Likes
7

It could be worse than bothersome if the dev has to cycle back with their own legal departments in order to re-sign. Or maybe, they signed it when they were employed elsewhere and now have to navigate an entirely new legal regime.

Is the hesitancy to prepopulate CLA assistant purely technical, or is there a PSF legal reason to do so? Maybe the latter if they signed under Academic previously?

I think it would be better for the community if we can prepopulate with those folks who have already signed it, and just use CLA assistant moving forward.

8

As Van has stated, this is the same CLA as before. In addition, if people are now employed elsewhere, wouldn’t it make sense for the to re-sign / re-check with their own current legal department anyway?

Personally I don’t even have visibility or access to current CLA records, so I don’t know what it will take to perform the data export. Perhaps @EWDurbin has more insight? But I think “the simplicity of signing the CLA in the new system” was a main consideration.

9

Possibly so, but I’d hate to have to force them to.

10

Perhaps most people won’t even feel like they’re being “forced” to do this, and we’re worrying for nothing :slight_smile: I hope people will see that this is just a tiny bit of inconvenience from their part, but it will greatly improve our workflow and future new contributors for years to come.

11

I’d be happy to find that my concerns are unwarranted!

1 Like
12

@VanL could you provide an answer to this?

1 Like
13

I’ll also mention we are maintaining a bespoke bot for this.

So to reiterate what Mariatta pointed out, the amount of energy going into our current workflow is:

  • maintaining the CLA bot
  • the bpo webhook
  • PSF staff to manually check and enter CLA signing
  • Mariatta’s site to forcibly check for a newly signed CLA
  • the usual messages from folks about their CLA status.

Moving to CLA Assistant does away with all of that.

3 Likes
14

I should point out that while I’ve signed the current CLA, and gained confirmation from my employer that I was OK to do so, if I were asked to re-sign, I would need to renegotiate that acceptance, and I have no assurance in advance that I would get approval (the existing agreement is in place and will remain, but things have changed since I signed it and my employer may take a different view if asked again). Furthermore, having to ask again could jeopardise my participation in other open source projects, as it could trigger a complete reassessment of the previous agreement, which went beyond “contributions to CPython”.

Worst case scenario, I may have to consider whether this “tiny bit of inconvenience” is worth risking my overall participation in open source. Obviously I’d love my concerns to be unwarranted, and it is a worst-case scenario, but the problem is that I may not have a way of even asking the question without triggering a review (I think I know of a way that I could, but I need to check).

So even with the above assurance, I still think it’s important that we make every possible effort to migrate over existing CLA acceptances without needing re-signing.

4 Likes
15

Everyone with Developer access to bugs.python.org has access to the current CLA records. It’s the “Contributor Form Received” radio button and date/time field on the User page.

If all that is needed is simple affirmation that a particular GitHub user has already signed the CLA, then the same query that the current CLA bot runs could be used: https://bugs.python.org/user?@template=clacheck&github_names=ncoghlan,mariatta,brettcannon

However, if the migration needs the specifics of when the form was signed, then that would need to be retrieved another way (probably directly from the DB by @EWDurbin, since it’s a one-off migration, rather than an ongoing need).

16

I have just checked with Ernest on what we can do to export out current records from bpo to CLA assistant. Ernest will be following up on this discussion and can provide more details.

One concern with exporting current data from bpo is that the “GitHub username” field in bpo is just a text field, and technically people can enter any GitHub username in there. There is no easy way for us to verify if the bpo user is the same GitHub user. We might be able to make this guess/assumption for current/active contributors. Whether such assumption/guess will be good enough from legal perspective, I don’t know. I’ll leave that to The PSF legal to consider.

I’ve mentioned to Ernest that I’d like to turn on CLA assistant in the coming weeks, and ideally before the sprint at PyCon US. From here on, Ernest will be taking the lead and see to it that the transition to CLA assistant is happening.

Thanks!

17

As an alternative, would it be possible to set up some sort of (semi-) manual approach, where individuals could request that their existing CLA got transferred (providing their bpo and github usernames as verification)? That would certainly satisfy my need, where continuing (transferring) an existing agreement is different from signing a new (even if technically identical) agreement.

1 Like
18

I’ve created a project in core-workflow repo, to keep track things that need to be done when we migrate to CLA assistant.

Please add action items that you can think of in case I miss anything. @brettcannon @EWDurbin
Thanks.

19

Note that we already trust the BPO GitHub entries for the current CLA bot. Yes, it does mean that someone can get someone else flagged as having signed the CLA, but we’ve mostly had problems in the other direction: the bot wasn’t acknowledging the CLA as signed because the GH username was missing or wrong.

That said, I think an export that was limited to cases where we were confident the usernames were correct would be fine (e.g. automated for core devs, by request on the core-workflow repo for others)

3 Likes
20

There is no broadly-applicable legal reason for people to re-sign.

That said, if people have changed employers and their new employer is not on board with them re-signing the exact agreement previously in place, I would appreciate if that could be brought up with me directly (at my @python.org or @dykema.com addresses).

Edit: I should clarify. This is not Paul Moore’s situation, where the employer is aware of and has agreed to the existing CLA - but would use the re-signing as an opportunity to re-negotiate Paul’s participation in open source. I am fine with migrating over Paul’s existing information to avoid a re-negotiation.

I just don’t want to have a situation where someone has switched employers and the new employer has had the employee sign an assignment agreement which would contradict the terms of the CLA. That puts both Python and the employee at risk.

4 Likes