RFC: Inactive contributor policy + addition of the Emeritus role

Contributors,

As you’ve heard from Ted on June 10th, we are migrating Swift to its new home at GitHub.com/swiftlang. As part of this move, we’re building new roles and policies around access to the GitHub Swiftlang Organization, a collection of Swift repositories. We believe that the first major part of shaping this is to establish an inactive contributor policy and Emeritus clause. This will open up to future initiatives around defining “organization membership”, commit access, and code ownership aka a contributor ladder in many open source spaces.

We’d like to hear from you in the comments below. The Core Team meets on Mondays and this RFC will be discussed at the Core Team meeting on Monday, July 15th.

Who does this affect?
GitHub organization members of Swift repositories, which includes Swift Committers and Code Owners
(from GitHub docs: Organization members)

Why is this important?

  • Allows for focus on building contributor workflows for an active, engaged community.
    • Active reviewers are correctly paired with PRs to triage, allowing for a great contributor experience
    • Helps identify areas that need to mentor new contributors for future commit access and code ownership
  • It’s a security concern with inactive members and elevated permissions.
  • Celebrate the people who have helped us on our journey and open source retirement!

Draft policy language:

Active and engaged contributors for Swift is important for security, quality, and the contributor experience of the community. There are going to be times when contributors need to move on for whatever reason like having other time commitments that take precedence. Due to this, project leaders will remove inactive Swiftlang GitHub Organization members on a yearly basis to encourage a healthy community. Removal will mean loss of access to elevated permissions like running CI.

What does inactivity mean?

  • You have not contributed in 6 consecutive months:

Emeritus

We encourage Swift committers, CODEOWNERs, and group members to think about using the term Emeritus when the situation arises that you can no longer maintain. If you’d like to come back when the time and space allows - please reach back out!

Submit a proactive PR:

  • If you’re in a CODEOWNERS or related file, comment out your new Emeritus status
  • If you’re a member of a group, add your name to the Emeritus section of the charter, or start one. See the Website Workgroup as an example

Process

The Core Team, or a delegated group(s), will conduct a yearly check for inactivity with GitHub organization members, committers, and codeowners around the time the Year in Swift blog post is composed or at another reflection point to be determined. The groups will work on removing the members from the organization and making any Emeritus comments where necessary.

If you’d like to return, or if a removal is in error, contributors should reach out to the Core Team.


Thoughts?

10 Likes

I don't know what is planned for this ladder, but it would help if the only two roles weren't committer and non-committer. Two more roles like CI access and reviewer would be useful, ie a non-committer would be given CI control once they need it then, after some time, could level up to reviewer and review others code without being able to commit it, ideally only for the parts of the code they know well (while the Swift CI control is off-github so would be possible to implement, not sure if github supports non-committer reviewers like this). Finally, contributors could be granted commit access, after showing their worth in those more circumscribed roles.

9 Likes

Agreed! :slight_smile: