Following the procedure outlined in OEP-54, I’d like to nominate the core-contributor members of the Build-Test-Release (BTR) working group to expand their rights to include closing and assigning issues the build-test-release-wg repository.
working group members who are core contributors and need their rights expanded:
- Dean Jay Mathew DeanJayMathew
- Ghassan Maslamani ghassanmas
- Jhony Avella jfavellar90
- Maria Grimaldi mariajgrimaldi
- Peter Pinch pdpinch
- Pierre Mailhot sambapete
- Régis Behmo regisb
(Note that this nomination includes myself. If I’ve missed anyone, let me know.)
Allowing the members of the working group to assign and close issues in the repository will make us much more efficient and improve communications. In particular, it will allow us to assign issues to ourselves and close them when they are done.
All our relevant work to this request is Issues · openedx/build-test-release-wg · GitHub
Please provide review comments by June 9th.
+1 From me.
This remove a lot of bottlenecks in the BTR group processes!
+1 from me too – it makes sense for the group members to be able to edit issues, and everyone in the list definitely deserves it!
I think on the OpenCraft side @mtyaka is looking to join the group – sorry for the shuffle on our side for the group membership.
I mostly agree with this, however, Dean, Pierre, & Ghassan have joined the CC program as non-technical contributors, meaning they have not been approved to have write access to a GitHub repo - their roles are non-technical so this would not be a rights expansion request, this would be a new role request.
I do not know the best way to resolve this. We would need to induct Dean, Pierre, & Ghassan as Core Contributors (committer) to grant this access, and would likely want to go through a separate process for each candidate to discuss them holding this role. Legally, there will be a separate document to sign in order to have write access to a repo.
There’s nothing technical in GitHub - openedx/build-test-release-wg: Open edX Build / Test / Release Working Group
Contents of the repo is just a few decision records. It mostly exists for the issue tracker and the project board.
While I understand that, from a technical and legal perspective they would be getting write access to repos which requires you to join the CC program as a committer.
With that write access they could possibly commit any amount of code that did anything - so need to be covered by Committers Agreement.
Technically, correct me if am wrong, I am one of those special cases because I am both non-technical (translations working group) and technical (built-test-release working group)? As far as I know, I don’t have access to any repository right now…
@sambapete ah I’m sorry, I missed you. You’ve joined the CC program as a non-technical contributor. Being a member of a working group is not the same as being part of the CC program as a committer.
No problem. That’s what I originally thought when you didn’t mention me. Still, I am the quality assurance manager for the tests. I guess this is partially technical but not committers technical.
For the BTR WG, some of us have write permissions on the release branches of repos we are not CC by the way of a GitHub action. Can we use a similar solution?
Beyond the BTR WG, is the situation the same for all WG?
By situation I mean, some active members of a working group need permissions that are only granted to CCs.
Yes, it would be the same case. I know how it seems, but the legal around who can write to repos is pretty strict. I think it may take an amount of backflipping to try to somehow craft legal language to separate one type of commit access from another. Also I bet, a fair amount of time.
I am not certain the same concept would apply. I don’t know how Projects or that API or permissions work there. For the releasers, your account doesn’t have write access - the bot does - and it checks the command against an allowlist of people. I guess it may be possible to write a github action or bot that monitors comments and performs actions based on an allow list of users, but that would certainly involve understanding the projects API which I don’t know. Are you using an old style project or a beta project? I’d be hesitant to write bespoke tooling for an old style project when the majority of Open edX projects are beta style.