-
Notifications
You must be signed in to change notification settings - Fork 255
A new Member contributor role that can trigger CI #917
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
We currently have three roles that contributors to the Swift project on GitHub can have: 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 can request [*Commit Access*](https://www.swift.org/contributing/#commit-access), which allows them to merge PRs and also trigger CI. Finally, contributors can become [*Code Owners*](https://www.swift.org/community/#code-owners). With the current structure, gaining the ability to trigger CI has 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. For now, this is not indented to change any of the other roles. We are working on improvements and clarifications to the other roles as well but would like to keep this change focused on the *Member* role. Finally a word on the role’s naming: Becoming a *Member* will be implemented by adding the user to the `swiftlang` organization on GitHub, which also displays a *Member* badge next in PRs opened by that user. We want to align the naming in Swift’s contributor ladder with that of GitHub to avoid confusion.
|
Isn't the ordering the wrong way around? Shouldn't it be:
That matches GHs UI, and definitions of most other open source projects |
|
On a second read, it actually sounds like these changes are more aligned with what's expected. It feels like we need a rung below contributor, who is someone who has created a PR or so but can't trigger CI etc |
If you mean the ordering in index.md, I chose to keep the current ordering that has the higher roles further up (eg. Code Owner above Committer). I will continue working on this and am happy to re-consider this ordering in a follow-up change.
This is the role of Contributor. The document says:
|
Right, but is there not scope for a role for people who are not part of the SwiftLang org but can still create PRs that automatically trigger CI without needing approval? If contributors are able to do this then ignore me but if not is it worth discussing? |
|
Sorry, I don’t fully understand what you mean. Becoming part of the swiftlang or is exactly what gives you the privilege to trigger CI. |
Sorry, to be clear I meant do we want a role where you don't have to be part of swiftlang to trigger CI, much like other open source projects. (Similar to the old allowlist of the SwiftCI of old.) It may be that this has been decided against and that's fine, just worth an ask. |
|
Yes, we decided against that. |
We currently have three roles that contributors to the Swift project on GitHub can have: 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 can request Commit Access, which allows them to merge PRs and also trigger CI. Finally, contributors can become Code Owners.
With the current structure, gaining the ability to trigger CI has 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.
For now, this is not indented to change any of the other roles. We are working on improvements and clarifications to the other roles as well but would like to keep this change focused on the Member role.
Finally a word on the role’s naming: Becoming a Member will be implemented by adding the user to the
swiftlangorganization on GitHub, which also displays a Member badge next in PRs opened by that user. We want to align the naming in Swift’s contributor ladder with that of GitHub to avoid confusion.