Maintainer Guidelines: Alumni and Active status

[chendaniely]

Hi Everyone:

There was some confusion around the different "statuses" in the original RFC (#15). After looking through the comments, I realized that the original structure was way too complex, and I'm hoping that this refactor will clarify a few things.

The Problem

We need to distinguish who is actively maintaining which lessons without alienating the maintainers who volunteered in the past.

Solution: Make an Alumni status

• The Alumni status will be used to designate any maintainer who is not currently listed as an active maintainer on a lesson
• There are a few ways to be given "alumni" status:
  • A "No" or non-response from the yearly check-in ( #19)
  • Letting us (The Carpentries) know you want to step down anytime during the year
  • Is already a former maintainer.

Implementation details

• Main difference between "Active" and "Alumni" will be committed and write access to the lesson.
• You will not be removed from any of the maintainer-specific communication channels (e.g., topicbox, slack, maintainer meetings, etc)
• You can send us (The Carpentries) an email at any time if you wish to be "Active" again on lesson maintenance.

Rationale

• The "alumni" status is really a mechanism to count who is actually "active" on a lesson to help with maintainer onboarding planning.
• If you want to be an active maintainer, we will try to put the fewest amount of barriers in the way to let you be an active maintainer. An email to The Carpentries team will be sufficient if you want to go from "alumni" -> "active" at any point during the year.

Question for the group

1. There might be cases where people want to step down as maintainers and ALSO be removed from communication channels. I think instead of making a separate "inactive" status those individuals can change email and slack preferences manually to opt-out of communication channels. If they want to be a maintainer again, they can email The Carpentries to get everything set up again.

[emcaulay]

Where is "alumni" status recorded?

[chendaniely]

See reply from @HaoZeke for the full context: https://github.com/carpentries/maintainer-RFCs/issues/19#issuecomment-1011765064 also see replies in #15

Paraphrasing their main concerns that seem to apply to alumni status, specifically:

1. We don't want to alienate previous maintainers by immediately revoking write access to lessons
2. Revoking write access will add more friction for previous maintainers when they need to make a change to the lesson
3. Maintainers and previous maintainers should have the same amount of credit, and those who step down should not have a sense of any diminished credit.

Part of my response to the comment linked: https://github.com/carpentries/maintainer-RFCs/issues/19#issuecomment-1012389043

1. "alumni" status may have to be recorded within a github team/permission model at the repo level since we can't use AMY.
2. will need to look into this: using GitHub will maybe give us the permission/control/badging specifications to distinguish "active" from "alumni" (this also may answer the comment above)