Currently, people wanting to contribute to projects like peps, devguide, core-workflow, bedevere, need to sign CLA, which requires a bpo account, and then they need to add their GitHub account to their bpo account.
I find this quite complicated process and a barrier of entry.
I think it will be great to have this process simplified. I think people should not need to have bpo account unless they're actually participating in the bug tracker for CPython.
1. Can we have people sign CLA and not require their bpo account?
2. Other big issue with bpo as CLA host is we don't have easy way that can let the-knights-who-say-ni update the label in the PR once the contributor has signed the CLA.
I've brought this up at the language summit, as one of the necessary step before we can start using GitHub issues. (that is not yet decided, and this is not the thread to argue about it).
But whether we are using GitHub issues or not, the current process needs improvement anyway.
Mariatta ᐧ
On Thu, Jun 14, 2018, 17:31 Mariatta Wijaya, mariatta.wijaya@gmail.com wrote:
Currently, people wanting to contribute to projects like peps, devguide, core-workflow, bedevere, need to sign CLA, which requires a bpo account, and then they need to add their GitHub account to their bpo account.
I find this quite complicated process and a barrier of entry.
I think it will be great to have this process simplified. I think people should not need to have bpo account unless they're actually participating in the bug tracker for CPython.
- Can we have people sign CLA and not require their bpo account?
Yes, we just need a record that's independent of GitHub (or can at least be easily backed up).
- Other big issue with bpo as CLA host is we don't have easy way that can
let the-knights-who-say-ni update the label in the PR once the contributor has signed the CLA.
I've been thinking about this and I think we can with a bit of effort (basically we need some way to know what repos Ni is hooked up to and then a cron job that checks all "CLA not signed" PRs). We could also provide a URL people can visit to trigger a check.
-Brett
I've brought this up at the language summit, as one of the necessary step before we can start using GitHub issues. (that is not yet decided, and this is not the thread to argue about it).
But whether we are using GitHub issues or not, the current process needs improvement anyway.
Mariatta ᐧ _______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On 15 June 2018 at 11:34, Brett Cannon brett@python.org wrote:
ther big issue with bpo as CLA host is we don't have easy way that can let
the-knights-who-say-ni update the label in the PR once the contributor has signed the CLA.
I've been thinking about this and I think we can with a bit of effort (basically we need some way to know what repos Ni is hooked up to and then a cron job that checks all "CLA not signed" PRs). We could also provide a URL people can visit to trigger a check.
bugs.python.org could also be updated to hit a knights-who-say-ni HTTPS endpoint whenever the CLA field or GitHub username field in a user account gets modified.
It's just a Python project - modifying it shouldn't be noticeably more scary than modifying any of the other web bots, and if there are process problems with that (which we know there are), then the first question should be "How do we help the bugs.python.org maintainers streamline their process?", not "How do we create yet another service to maintain?".
bugs.python.org maintenance processes aren't the way they are because the maintainers like them that way - they're the way they are because very few people are showing up to help with improving them.
Cheers, Nick.
On 15 June 2018 at 20:27, Nick Coghlan ncoghlan@gmail.com wrote:
On 15 June 2018 at 11:34, Brett Cannon brett@python.org wrote:
ther big issue with bpo as CLA host is we don't have easy way that can
let the-knights-who-say-ni update the label in the PR once the contributor has signed the CLA.
I've been thinking about this and I think we can with a bit of effort (basically we need some way to know what repos Ni is hooked up to and then a cron job that checks all "CLA not signed" PRs). We could also provide a URL people can visit to trigger a check.
bugs.python.org could also be updated to hit a knights-who-say-ni HTTPS endpoint whenever the CLA field or GitHub username field in a user account gets modified.
It's just a Python project - modifying it shouldn't be noticeably more scary than modifying any of the other web bots, and if there are process problems with that (which we know there are), then the first question should be "How do we help the bugs.python.org maintainers streamline their process?", not "How do we create yet another service to maintain?".
I've filed http://psf.upfronthosting.co.za/roundup/meta/issue655 to help turn this into a concrete process improvement proposal.
Cheers, Nick.
On 15 June 2018 at 20:49, Nick Coghlan ncoghlan@gmail.com wrote:
On 15 June 2018 at 20:27, Nick Coghlan ncoghlan@gmail.com wrote:
On 15 June 2018 at 11:34, Brett Cannon brett@python.org wrote:
ther big issue with bpo as CLA host is we don't have easy way that can
let the-knights-who-say-ni update the label in the PR once the contributor has signed the CLA.
I've been thinking about this and I think we can with a bit of effort (basically we need some way to know what repos Ni is hooked up to and then a cron job that checks all "CLA not signed" PRs). We could also provide a URL people can visit to trigger a check.
bugs.python.org could also be updated to hit a knights-who-say-ni HTTPS endpoint whenever the CLA field or GitHub username field in a user account gets modified.
It's just a Python project - modifying it shouldn't be noticeably more scary than modifying any of the other web bots, and if there are process problems with that (which we know there are), then the first question should be "How do we help the bugs.python.org maintainers streamline their process?", not "How do we create yet another service to maintain?".
I've filed http://psf.upfronthosting.co.za/roundup/meta/issue655 to help turn this into a concrete process improvement proposal.
Ezio was happy with the idea of migrating the meta-tracker, so the discussion of migrating the instance repo has moved to https://github.com/python/bugs.python.org/issues/2 (where Ernest has chimed in with several relevant technical details that suggest this should be quite a feasible change to make - the downstream Roundup fork would remain on hg.python.org, but the CPython specific templates, plugins, hook scripts, etc, could all migrate over to the new repo)
Cheers, Nick.
On 14 June 2018 at 18:34, Brett Cannon brett@python.org wrote:
On Thu, Jun 14, 2018, 17:31 Mariatta Wijaya, mariatta.wijaya@gmail.com wrote:
- Can we have people sign CLA and not require their bpo account?
Yes, we just need a record that's independent of GitHub (or can at least be easily backed up). ok
$work uses https://cla-assistant.io/ and we're pretty happy with it. Its easy, and can be backed up.
Hi Mariatta,
people contributing to Python will also have to sign up for maintaining the code they contribute to a certain extent, so why would they not need a bpo account ?
Also note that bpo is easy for us to customize, so the natural place to maintain such flags.
That said, the CLA process is manual (at least AFAIK), so if there's a way to set a flag in Github, perhaps this could be integrated into CLA process.
Thanks,
On Thu, Jun 14, 2018 at 6:30 PM Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
Currently, people wanting to contribute to projects like peps, devguide, core-workflow, bedevere, need to sign CLA, which requires a bpo account, and then they need to add their GitHub account to their bpo account.
I find this quite complicated process and a barrier of entry.
FWIW, for BPO authentication we currently have direct links (icons) for authenticating with Google and Launchpad (on the left side bar). Adding a similar link for GitHub would help make it easier for new contributors (and probably make sense anyway). I've opened http://psf.upfronthosting.co.za/roundup/meta/issue656 for this.
-eric
so the discussion of migrating the instance repo has moved to https://github.com/python/bugs.python.org/issues/2
Thanks!! I've filed several issues in my wishlist 🙇🏻♀️
Adding a similar link for GitHub would help make it easier for new contributors (and probably make sense anyway)
😅 I've opened https://github.com/python/bugs.python.org/issues/7
we currently have direct links (icons)
for authenticating with Google
What I heard is that Google login hasn't been working, only openid http://psf.upfronthosting.co.za/roundup/meta/issue647 http://psf.upfronthosting.co.za/roundup/meta/issue566 http://psf.upfronthosting.co.za/roundup/meta/issue559
bugs.python.org maintenance processes aren't the way they are because the maintainers like them that way - they're the way they are because very few people are showing up to help with improving them.
At its current state it doesn't seem like its even welcoming any contributions. I still have not figured out how to upload a patch there.
people contributing to Python will also have to sign up
for maintaining the code they contribute to a certain extent, so why would they not need a bpo account ?
bpo account is only needed to participate in issues for CPython. People editing PEPs and devguide and fixing typos should not be required to go to b.p.o and create account just to sign the CLA.
Also note that bpo is easy for us to customize, so the natural place to maintain such flags.
Easy is relative :) It can be customized, but only several people in the world are currently capable of customizing it.
Mariatta
ᐧ
On 16 June 2018 at 03:16, Mariatta Wijaya mariatta.wijaya@gmail.com wrote:
Also note that bpo is easy for us to customize, so the natural place to maintain such flags.
Easy is relative :) It can be customized, but only several people in the world are currently capable of customizing it.
Indeed, hence my proposal at https://github.com/python/bugs.python.org/issues/2 :)
Cheers, Nick.
participants (6)
-
Brett Cannon -
Eitan Adler -
Eric Snow -
M.-A. Lemburg -
Mariatta Wijaya -
Nick Coghlan