RFC: Inactive contributor policy + addition of the Emeritus role

Development Announcements
1

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?

11 Likes
2

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.

11 Likes
3

Agreed! :slight_smile:

4

I would prefer if the loss of code ownership (I’m just talking about code ownership, not committer status) is not something that happens automatically, but something that fellow code owners need to actively decide upon. My proposal would be

If a maintainer hasn’t made any contributions to the component in 6 months, their code ownership status can be changed to emeritus by another code owner of the directory or a parent directory.

In my opinion, this solves the following problems, especially for components with low activity:

  • If a component has only had no changes in the last year, there is no doubt of removing a code owner and the code becoming ownerless
  • A group of code owners might decide that somebody else (eg. a coworker in the same team) might be a good code owner of a component, even if they don’t make regular contributions to it.
1 Like
5

I strongly support using the term 'emeritus' and noting the status of those people. I think it fosters a sense of community and also history of a project or group recognizing the people who have come before.

My assumption is that these criteria are on a repository by repository basis.

Are there additional criteria that should be spelled out in terms of being removed from the Github swiftlang organization itself?

That may be as straightforward as something like "A member will be removed as a member of the swiftlang organization if they are no longer a code owner or committer in any swiftlang repository."

But there may be nuances I am not aware of.

1 Like
6

major +1, does anyone from the team have suggestions on how best to formally propose this? maybe a new Forums thread?

anecdotally, I feel like CI access is an incredibly useful stepping stone in working towards being a more active contributor. for example, I currently have to request that someone else trigger CI every single time I make a commit to one of my PRs, which significantly increases iteration time. (see the tail end of this PR for one; I would not have been able to get these checks passing if it weren't for Yuta and Evan proactively helping out.)

I also feel that the security considerations are very different between (1) CI access and (2) committer access. (1) the former entails that the community/team trust a contributor enough not to make intentionally malicious commits that would exploit elevated privileges on CI. meanwhile, (2) commit access entails trusting someone enough to actively understand the long-term effects of their code changes landing in production. I'd go as far as to say the inactive contributor policy is a great case study here — an inactive contributor can easily be said to no longer meet the second requirement (as they no longer have broader context on the codebase) whereas they could still be sufficiently trusted to trigger CI checks.

5 Likes
7

hey @kabiroberai, we are working on this in the contributor experience workgroup and have a framework together but not ready for wider feedback just yet. do you like doing this work? want to join the group? if so, DM us and we can get you added. we have this contributor ladder on deck as well as contributor guides, etc. and would love to have more folks!

for those who can't dedicate the time right now but still want to be involved in the convo, we will put out a RFC/update with the progress asap. Our next meeting is August 9th so that could be a good check point. :)

2 Likes
8

thanks Paris, not quite ready to apply to any of the workgroups yet (lots in flux rn personally) but I’m looking forward to the RFC/update!

1 Like
9

Updates for this thread:

We've received a lot of feedback and want to propose the following edits and modifications to the above to iterate based on that. Thank you!!

Changelog:

  • The first major change would be the title of the document
  • Removing the messaging about forum inactivity
  • Addition of 'GitHub' in various places

Summary of changes:

  • This document is about GitHub access at the root vs defining someone's general contributor status. Being a contributor to Swift means you are helping the community on GitHub, the forums, giving talks, and more. This document has a very specific purpose, which is GitHub, and should be scoped for that only.
  • There is also a burden of capturing data for forums + GitHub + aligning them which leaves a lot of room for error and removing people by accident. We can better scope the data collection with one source - GitHub.

New Text ---

Title: Inactive GitHub Contributor Policy + Addition of the Emeritus Roles

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 to the /swiftlang GitHub Org:

Emeritus

(same text as the original document)

1 Like
10

Updates for this thread about a separate, yet related topic, the contributor ladder:

The Core Team is meeting with the Contributor Experience Workgroup today, September 20th, during the workgroups regular meeting to start discussions on the groups Draft proposal. Once the Core Team has provided feedback, the workgroup will prepare an RFC to the community for further feedback and iterations.

A separate thread in -dev category will be created for this.

2 Likes