So far contributors to the Swift project on GitHub could have three roles: Everybody can participate the Swift open source project and become a Contributor. After creating a track record by creating 5 non-trivial pull requests that were accepted without modifications, contributors could request Commit Access, which allowed them to merge PRs and also trigger CI. Finally, contributors could become Code Owners.
With that structure, gaining the ability to trigger CI had quite a high bar and hinders new contributors from accelerating their contributions to Swift. We are thus introducing a new role: After contributing to Swift multiple times, contributors can request to become a Member, which grants them the ability to trigger CI but does not give them commit access yet. This way they can test changes on their own schedule and taking the burden to trigger CI off those with commit access.
The details of the new Member role can be found on swift.org.
We are looking forward to your feedback and real-world experience with the new role here. Going forward, we are working on improvements and clarifications to the other roles as well and will post updates about these in the Contributor Experience Category. If you are interested in those updates, please subscribe to that category.
this change seems excellent to me. as someone who has tried to make some small-ish contributions, not being able to trigger CI independently has definitely added friction to the process. having to repeatedly ping busy people to effectively 'press a button' for me has never felt great, so i'm pleased to see this capability introduced.
a couple related questions that came to mind, as i didn't see them explicitly covered elsewhere:
will the role grant the ability to trigger CI on anyone's PR, or just those authored by the user with the member role?
will the role grant the ability to 'triage' GitHub issues by adding labels?
anyway, just wanted to re-iterate once more how great this change seems. if i'm not mistaken, it's an idea that's been floating around for quite a while, so really happy to see it become a reality – and thanks to whoever was involved in making it happen!
being able to trigger CI would save a lot of time for those of us working on external improvements to SwiftPM, like the Environment-Dependent Shared Libraries feature.
based on the description:
Make multiple constructive contributions to the Swift projects, this can be in the form of PRs, engagement on the Swift Forums, filing valuable issue, triaging them, or similar forms of contributions.
it sounds like simply opening a PR, and announcing the pitch on these Forums is sufficient to gain Member access, but i just wanted to confirm.
Even though I try to maintain up-to-date security best practices, it is still a lot of responsibility. If my home were to be burgled (has never happened to me, thankfully, but it has to some of my neighbours), among all the other stress and worries, I would need to consider that it is also a possible security breach in a critical piece of technology infrastructure. And then you consider how many people have commit access, and for whatever reason they might not all follow the latest best practices.
Besides, I have sometimes accidentally clicked things on the Github website on my phone. It's not impossible that I could scroll down to check the CI status bar and accidentally hit "merge".
Anyway, I don't see commit access as being any kind of privilege. It's responsibility I don't need and actively do not want. But I would like to contribute to the project and CI is really important for that.
So I find it a bit strange that it's pitched like that on the website.
Member
[...]
Growth
Show that you use the privileges constructively and continue contributing to gain commit access.
IMO, the criteria for commit access should be based on how frequently you contribute. For folks (at Apple or elsewhere) who work on the Swift projects every day, obviously it makes sense. If you make less frequent contributions, regardless of how brilliant they are, I can't see why the ability to merge and bypass code review would be necessary.
EDIT: Oh but member does not include "merge with approval". I think it should, or we should create some tier in the middle which does include it. If a patch has been reviewed and approved by the code owners (but the reviewer didn't click 'merge' themselves), I'm not sure why we would prevent the author from merging it.
You will be able to trigger CI on any PR as a Member.
Not at the moment. This is something we are currently working on.
We would like to see several constructive contributions that show that you will not abuse this new role. There specifically aren’t hard guidelines because there is no one-size-fits way to measure contributions but in the specific case you described, I would require a certain engagement with the community like replying to questions for the pitch, or to review comments before the Member role is granted.
We are currently re-considering the other roles like Commit Access as well and this is definitely something that’s on our mind.
Just wanted to give my support for @taylorswift to be given member access to be able to run CI in the above linked pitch - would be very helpful for validating the pitch.
This thread is for feedback and questions about the member role itself, and other potential improvements for the contributor ladder. If any individuals would like to gain access to "member" capabilities, please follow the instructions for self nomination listed on Swift.org/contributing:
If you would like to become a member, please send an email to the code owners list that includes your contribution and the GitHub user name that you want to use
All forms of contribution "count", whether that's GitHub issues you've filed, pitches you've started, or even simply engaging in other contributors' forum posts. Please provide the links to whatever contributions you'd like to highlight in your forum message/email.