Open chendaniely opened 2 years ago
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).
This sounds reasonable to me!
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.
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.
Is there a process to "officially retire"?
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?
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:
@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.
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.
@chendaniely, As AMY does not have the support yet, should we request the AMY feature so that the maintainers can indicate their preferences?
@annajiat : yes this is something that @fmichonneau and @tobyhodges are working on. but IIRC the AMY feature is still something in the process.
A GitHub bot might be a better way to do this than an email.
It's an interesting thought to use bots, but I think this should be a thing for humans staying in contact with one another.
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.
This problem has caused a few secondary side effects:
Solution: Yearly Check-Ins
A google form that will be sent out to all our active core lesson maintainers asking them:
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
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.