Maintainer Guidelines: Yearly Check-ins for Maintainers

[chendaniely]

Hi everyone:

Thank you for all the feedback ~in the Spring~ earlier this year and RFCs (#15) when we first proposed maintainer guidelines. The original RFC was very loaded, and there were many moving parts that made the discussion a bit more difficult to track where actual suggestions and objections were. This is one of the new RFCs that refactor the original on (#15).

The Problem

The primary problem I am working on is dealing with the core lessons that have inactive maintainers.

• Some lessons are only being actively maintained by a single person.
• Others have zero active maintainers.

This problem has caused a few secondary side effects:

1. Maintainers are feeling discouraged, unsupported, and burned out.
2. The Carpentries do not know how many new maintainers need to be onboarded.

Solution: Yearly Check-Ins

A google form that will be sent out to all our active core lesson maintainers asking them:

1. Name
2. E-mail
3. Lesson(s) they maintain
4. Yes/No will they like to continue maintaining their lessons
5. If Yes: Are you feeling burnt-out and would like to step down / retire soon. We'll work on finding someone to take over your role.

This is similar to the survey that was sent out around April/May of this year when we were planing for new maintainers for onboarding.

The main difference between the one sent out earlier this year and the proposed changes are to make this survey "mandatory" (or really opt-in).

Implementation details

• Survey will go out in Q1 of each year
• Survey will be sent out via email (TopicBox) and slack with weekly reminders for about 1 month
• You will need to opt-in to stay listed as an active maintainer
• A "No" or non-response will move you to "alumni" maintainer (#20)
• If you do not respond we will attempt to reach out 1 last time for a response.
• You can email us back at any time to be put back into "active" maintainer (#20)

Rationale

Even though being a maintainer is a volunteer position. I think it's reasonable to also expect some amount of commitment from both sides: The Carpentries will do their best to support maintainers, and maintainers do their best to maintain the lesson.

• Some of the feedback we (The Carpentries) have been getting is joining a lesson that is inactive and the new maintainer is the only person working on the project.

• A yearly check-in will take a lot of the guesswork out for many people involved with lesson maintenance and planning resources.

• We need a more accurate way to count which lessons need help

• When we submitted the lesson maintenance survey earlier this year, we did not get any responses from some of the non-maintained lessons. The opt-in will help with identifying truly unmaintained lessons for us to find people to support.

• "losing access" isn't permanent (#20): even though it's opt-in and you will be moved to "alumni" status if you do not respond, if you email us that you lost commit privileges to your repository later on in the year, you'll be listed again as an active maintainer.

[emcaulay]

I fully support this new guideline and I think it's very effective. If the maintainer can't respond to an email message from The Carpentries, then it's unlikely they are responsive to the community related to their responsibilities of maintaining a lesson.

I'll be honest, too, and say it's also discouraging to know that you're the only one maintaining a lesson and see other people's names listed as maintainers (feels like they're getting credit they don't deserve).

[ChristinaLK]

This sounds reasonable to me!

[ragamouf]

I agree, this looks sufficiently light touch to implement and it will help maintainers move to the next step once it's clear who's available for lesson maintenance.

[HaoZeke]

This RFC in its previous iterations has garnered negative comments from me. I will not rehash them all here again, but I do not believe this exercise is worthwhile. Though the current guidelines mention sending an email will be sufficient, it is still too high a barrier.

Consider the following scenario:

A retired maintainer but active instructor would like to merge a few nitpicky changes to a lesson.

In the context of this proposal, said retiree would have to undergo a relatively long process for making a simple change.

I stand by my previous comments stating that a community is not reduced by including multiple maintainers, even if they are not all active. Write access should be given to all those who have proven competence and in good faith I see no reason to revoke said access by any automatic mechanism.

For the situation where there are inactive maintainers, I believe pinging them on issues and PRs will either make them take on some of the load, or they will request to officially retire.

A mandatory response required form promising punitive action in exchange for not making a yearly commitment seems like a step in the wrong direction and shows a profound lack of faith in our volunteer maintainers.

There have been no arguments presented for why it would make sense to forcibly retire people on a yearly basis. It would make more sense to have a fixed schedule for people to become maintainers throughout the year, eg. If someone reviews x PRs and shows up at meetings they should be offered write access.

I do not understand the concept of diminished maintainer credit. On the contrary, to have many maintainers should be seen as a sign of healthy growth.

However, these arguments have been made by me and others previously to no avail. I state them only for completeness.

At this stage it would be best to just move forward with this instead of more RFCs with no substantial changes.

[jsta]

Is there a process to "officially retire"?

[amzoss]

I don't share the concerns mentioned above. I do think asking people to declare their intention to actively help on lesson issues makes sense. As I am finding in just my first few months of being a maintainer, It is all too easy to just hope that someone else on the maintainer list is available to work on issues that come up, and it doesn't do anyone good to think that there are many people with availability to take on tasks if that's not accurate.

I wonder, though, why a retired or inactive maintainer necessarily has to lose edit privileges. Is that a policy decision or a technical decision? In principle, if they've already been trained as a maintainer, they can be trusted to make edits responsibly. Is there a way to allow them to retain commit permissions but just not be listed/counted as an active maintainer?

[chendaniely]

Just so I'm more explicit on how we used (and will use) the opt-in process:

Before we ran maintainer onboarding this past summer, we used the survey results to have potential new members select which software stack or topic they will want to maintain. This is how @ErinBecker and I assigned the new maintainers from onboarding to their respective lessons. We still had an issue where completely inactive lessons got zero assignments because we didn't get any response from the lesson.

@HaoZeke, following up on your concerns:

1. The previous RFC (#15) was trying to talk about too many things at once. This current RFC was split off because some of the counterpoints were getting mixed around with other proposed changes
   • Your comment (https://github.com/carpentries/maintainer-RFCs/issues/15#issuecomment-819723364) is the reason why this RFC doesn't talk about the lead maintainer role anymore, and why the badges are only "active" and "alumni" now. You brought up a good point about adding too many artificial structures that might not be needed.
   • I did try my best to separate and match up all the comments to the initial proposed changes, but I wanted to clarify some things here since I missed something.
2. I'm not opposed to having people retain some kind of write permission, maybe we can solve this issue of "active" "alumni" with GitHub teams/groups. the main issue right now is there is zero way to know who is active/inactive since AMY does not have that level of detail.
   • I've also heard of arguments where an uncurated list of people with write/push access to a repository can be considered a security risk
   • If you're okay with simply using this opt-in mechanism as a "headcount". I can update RFC #20 to reflect your comments there and we can wait on immediately removing permissions until we can better count which lessons need maintainers.
3. The current mechanism of pinging someone on GitHub is not working for a lot of maintainers because the person pinged still is not inclined to respond, and there's no other way to know how many people are active and can help out with maintenance duties
   • I've been trying to use the co-working and meeting sessions to have some kind of crosstalk between related lessons to offset inactivity within lesson co-maintainers.
4. This provides a more formal way for people to step down instead of fading out and having to guess whether or not they are going to be a maintainer
5. (added 2022-01-13 18:42 UTC): I don't think it will be good to keep some kind of "point" system where meeting attendance or counting PRs before we internally determine a lesson needs more maintainers will go well. This might lead to even more confusion and feelings of diffusion of responsibility (a problem we have now). I would suggest maybe we can write that down in a guideline so people know roughly how much work to expect.

@HaoZeke: I don't want to dismiss your concerns, but would like to hear if you had any other approaches in dealing with trying to figure out how many lessons need maintenance help.

[ldko]

As a former active maintainer on a Software Carpentry lesson, my opinion about GitHub repo write permissions for maintainers stepping down from "active", is that they should be removed. While I somewhat agree that it would be nice to be able to merge some minor changes here and there though I am no longer "active", I feel like once you have said you don't want to be "active" anymore, then you should not have write privileges to the repo. Not because one should assume the "alumni" is no longer trustworthy, but in the long run, it leads to a lot of people having write privileges to a lesson repo, and possibly new maintainers having people they have never spoken to and don't know as a past maintainer make commits to the repo they are trying to currently maintain (in some cases it may be welcome, in others it could feel like "stepping on toes").

Also, while it would be a convenience for past maintainers themselves to retain write permissions for freedom to do what they want, I do see it as a security risk with more and more people having access to changing the lesson without structured oversight. It would be difficult to monitor and maintain these privileges enough not to consider it a security risk as time goes on. While an alumni maintainer pinging a current maintainer about changes they think should be merged will cause some work for the current maintainer, that is what the current maintainer is there for, and I think it is the better way to go about it. If it is happening enough to seem like an inconvenience to go through the process for one or the other person, than the alumni maintainer could discuss getting added back as active and communicating with the other active maintainers about what they intend their role to be.

[annajiat]

@chendaniely, As AMY does not have the support yet, should we request the AMY feature so that the maintainers can indicate their preferences?

[chendaniely]

@annajiat : yes this is something that @fmichonneau and @tobyhodges are working on. but IIRC the AMY feature is still something in the process.

[bkmgit]

A GitHub bot might be a better way to do this than an email.

[bencomp]

It's an interesting thought to use bots, but I think this should be a thing for humans staying in contact with one another.