Skip to content

Conversation

@ahoppen
Copy link
Member

@ahoppen ahoppen commented Feb 24, 2025

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 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.

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.
@0xTim
Copy link
Member

0xTim commented Feb 24, 2025

Isn't the ordering the wrong way around? Shouldn't it be:

  • Contributor - has contributed to the project, can trigger CI, cannot merge PRs, is not a member of SwiftLang
  • Member - one up from contributor. Can trigger CI, merge PRs and is a member of SwiftLang
  • Code owner - as it currently is.

That matches GHs UI, and definitions of most other open source projects

@0xTim
Copy link
Member

0xTim commented Feb 24, 2025

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

@ahoppen
Copy link
Member Author

ahoppen commented Feb 24, 2025

Isn't the ordering the wrong way around?

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.

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

This is the role of Contributor. The document says:

Contributor is anyone who has contributed to Swift by writing code, answering questions on the forums, reporting or triaging bugs, participating in the Swift evolution process, or other ways

@shahmishal shahmishal merged commit b71adcc into swiftlang:main Feb 24, 2025
3 checks passed
@ahoppen ahoppen deleted the member-role branch February 24, 2025 23:06
@0xTim
Copy link
Member

0xTim commented Feb 25, 2025

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?

@ahoppen
Copy link
Member Author

ahoppen commented Feb 26, 2025

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.

@0xTim
Copy link
Member

0xTim commented Feb 27, 2025

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.

@ahoppen
Copy link
Member Author

ahoppen commented Feb 27, 2025

Yes, we decided against that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants