I am not sure a mailing list would be the best solution here. If any GitHub activity is posted there, it would become impossible to follow really quickly. Maybe a bot, which sends an email to the bpo-email of the original bpo-committer is a better approach.
Just to make sure everyone understands correctly. What I am saying here is that when a person with no GitHub access proposes a patch on the bpo, then the bot which converts the patch to a PR registers the contributors registered bpo-email to another bot(let’s call it the “mail(wo)man”), which then sends GitHub-like notifications to the contributor for every GitHub update.
I don’t really know, if that’s possible, but I think it is a more reasonable idea than a universal mailing list. Any thoughts?
The situation you described only covers people who contribute by submitting a patch.
We need to cover those who contribute by participating in issue discussions, bug reporting, and everything else.
I would like to hear from someone in one of the countries where this happened if that solution would not get them into even more trouble for trying to evade the restrictions.
In addition to @Mariatta’s comments, another potential reason for not requiring a github account is that github only permit any individual to have a single account (at least for the free tier) - that’s per individual, not per email address. If an individual wanted to contribute, but did not want to use their existing account, they would have a problem.
Cases where this could happen are people with a github account linked to their work email, who want to keep their Python activity associated with a personal email address.
I’ve heard this argument made before, but I have never heard anyone ever have an account shut down due to this. It would immediately shut down every oauth-based bot – including our own – and would ruin things for practically every person I know at Microsoft who very often have separate work and personal accounts.
So I get the worry, but if we were going to worry about this then we shouldn’t be on GitHub to begin with (or probably any other hosted platform).
Fair point. It’s definitely only a theoretical concern, like you I’ve never seen it happen. It’s also probably unenforceable in practice. But nevertheless it is a breach of the Github T&Cs, and we should consider contributors who feel that breaching the T&Cs is unacceptable.
My original comment was in response to @Mariatta’s point
and in that context “not being willing to deliberately breach Github’s T&Cs” is a valid reason for not being able to access github.
It’s not a major point, though, as having a way for people without github accounts to contribute was already noted as a requirement…
A machine account is used exclusively for performing automated tasks. […]
You may maintain no more than one free machine account in addition to your free User Account.
– GitHub Terms of Service - GitHub Docs
@Mariatta I don’t know if it’s answered somewhere but does GitHub provide granular user permissions for triaging (adding labels and closing) issues without write permissions to the repository? It would help me in triaging if I have access to add labels to the issues. An alternate would be to have one of the bots parse comments with specific phrases to add the relevant labels to the issue. I can write a text reply but access to add labels would help in filtering.
My preferred solution is to give write access to current active bug triagers, so they can apply labels and close issues, but merging will still be limited to miss-islington and core developers, by adding branch protection, similar to how 3.6 and 3.5 are currently protected and only release managers can merge to those branches.
I know I’ve seen code in Bedevere where Brett checks the committers list before letting Bedevere do certain things (like add awaiting merge). I thought something similar could be incorporated in the bot. So, if there was a valid list of triagers and a valid list of core devs, then if someone wanted to add a tag, the bot wouldn’t allow it unless they were on the list.
To be honest, I was just using zulipbot as an example not necessarily to use it exactly as is.
Gotcha. In either scenario, we still need to maintain the list of “issue triagers” and “core team”, ie adding the issue triagers as a team member on GitHub.
Granting write access and protecting the branch seems simpler than building and maintaining the bot, but perhaps this is something for the new steering council to decide.
It’s good to know that there are different options to solve this situation.
in another thread, could you elaborate on how you went about this and if it could be used for the bugs.python.org triagers issue above? If there is a new Github based solution then that would be ideal.
Github has a beta for a “triage” permission that sits between Write and Read. You have to get the org flagged for the beta, but otherwise it works the same as any other permission set in Github.
