@VanL Given that, it sounds like a by-request migration model will be the way to go then: if folks are in a situation where signing the CLA again is fine, then we can just do that, and it’s only the folks in situations like Paul’s that will need to contact the PSF by a TBD mechanism to say “Please transfer my CLA signature from the old CLA tracking system to the new one”.
Could we just have them email an appropriate person to check the records and then manually add them (assuming CLA Assistant has a manual way to add someone after the instance is set up versus a bulk import)? Are we worried about a flood of folks? We could keep this part a little quiet to encourage people to sign up using the new system and only point people who ask to the email address solution.
I may be late to the party but I just wanted to ask whether you considered using something from the GitHub Apps world…
Using a dedicated GH user account seems “not cool in 2019”: the access control is far from being granular, it’s got user-bound rate limits, can’t use some of the fancy APIs (Checks API, for example).
Here’s a few apps I’ve found with quick googling:
– https://github.com/apps/cla-bot / https://colineberhardt.github.io/cla-bot/ / https://github.com/ColinEberhardt/cla-bot
– https://github.com/apps/adobe-cla-bot / https://github.com/adobe/cla-bot
All in JS. Python doesn’t have a strong ecosystem for developing GitHub Apps yet. (I’m trying to start one, though)
I agree that nowadays GitHub App is a better way, but I also want this to happen as soon as possible. So I don’t want to derail the progress of using a new cla host much longer.
@EWDurbin Let me know what can I help with to move this forward. What’s still pending before we can start using cla-assistant? Thanks.