Maintainer (new) guidelines and yearly responsibilities

[chendaniely]

Written up from the ideas in inputs from the last few meetings and previous RFCs (#11 #12 #13 #14). This would make things simpler and more concrete. Treat the parts shown here as the new additions and sections to the current maintainer guidelines.

Maintainer guidelines and yearly responsibilities

Individual Yearly Check-ins

Once a year a survey poll will be sent out to each maintainer asking them if they are willing to sign on as a lesson maintainer for the next year. The survey will ask for the maintainer's name, email, and lesson followed by an option to continue on as a maintainer, or be moved to maintainer alumni status. This yearly ping will be required from all maintainers; if no response is given within the month, the response will automatically be recorded as passing on continuing as a maintainer and will be automatically moved into alumni status.

Rationale: We want to make sure that the maintainers are responsive and lessons have active maintainers without being overbearing. This will give The Carpentries time to figure out which lessons need more maintainers that need to be onboarded.

Lesson Yearly Check-ins

Every year, all the repositories will be randomly (without replacement) assigned to a particular month. These lessons will be the "lessons of the month" where those lessons will be the main focus for doing a mini-sprint to deal with issues and PRs. The maintainer meetings will provide a time for maintainers for these lessons to review PRs and address any issues. One of the maintainers from each of the lessons will need to respond to a ping about their lesson status and participation in that month's maintainer meetings. The maintainer meetings will not be mandatory for those lesson maintainers, and issues and PRs can be flagged for other maintainers to review during the meeting. This will give each lesson an opportunity to talk about issues they are having with their lesson.

Rationale: This makes it so that each lesson is at least touched upon once a year, and we can slowly work on clearing the backlog of issues and PRs that are years old. For new lesson template changes or other large Carpentries-wide changes, this will give each lesson an opportunity to work out any issues they may gave with migration.

Lead Maintainer

When a single point of contact is needed for a lesson, these inquiries will go to the lead maintainer. They can also serve as a liaison for other maintainers of their lesson if there are any issues. There should not be any more additional lesson maintenance work for the lead maintainer. The lead maintainer does not have to hold that position for a set amount of time, it's mainly just a point person if a more rapid response to a question arises. The lesson maintainers for that lesson can rotate the role among themselves as they need.

Rationale: We get inquiries from people in and out of the Carpentries about certain lessons and sometimes just need a single point of contact for repositories.

Stepping Down and Alumni Status

The yearly commitment maintainers make is not binding. Life happens. We do ask that maintainers who feel they are unable to meet the responsibility anymore contact the community maintainer lead when they are able. You will be moved into an Alumni status, and still be able to attend maintainer meetings, comment on issues, and review PRs. However, you will no longer be able to merge PRs and make direct changes to the lesson.

Re-Activation from Alumni to Active

This will be done on a case-by-case basis since maintainers are already "assigned" to a lesson. In general, if no replacement has been found, then they will be able to re-join the lesson as a maintainer and catch up on any lesson changes. If more than a year has passed, they may be asked to attend the next onboarding session.

Rationale: We want people to know they are able to step down from being a maintainer without any repercussions and they are always welcome back. This mainly helps The Carpentries plan resources.

Maintenance Resources

Help During Maintainer Meetings

There are typically 2 maintainer meetings each month. The main meeting is held on the 3rd Wednesday of the month, and there is a co-working meeting on the first Wednesday of the month. Maintainers are welcome to nominate their lesson for a mini sprint during the co-working corrals. If they are unable to make it to the actual meeting, they can message the meeting host with issues and PRs that need to be reviewed.

Rationale: We want to give maintainers as many options to deal with issues and PRs as well as participate with other maintainers. The co-working corral has been used to review PRs and has been an effective way of preventing PRs from lingering longer than they have to.

cc ping: @brownsarahm

[annajiat]

Nicely summarized, thanks @chendaniely .

To reiterate a concern shared in #13 about the ping, we might wish to ping via email, git mentions, and slack unless a maintainer doesn't want to be contacted over multiple mediums.

It might be helpful for the email reminder to be repeated once in email incase the first one went to spam.

For the DM in slack, 1st ping should be fine as slack highlights it and keeps it separate.

[brownsarahm]

Tremendous effort and sorry for being unresponsive to date.

For the annual update, I think using a less technical-jargon term than ping may be more inclusive, but maybe ping is now more broadly accepted. For reasons of keeping this checkin reasonable, I don't think making the community lead reach everyone individually in multiple ways is feasible. It should be an e-mail and announced that there was an e-mail sent in other place, a DM to each maintainer is a lot of work.

Minor:

This yearly ping will be required from all maintainers; if no response is given within the month,
the response will automatically be recorded as passing on continuing as a maintainer and will be automatically moved into alumni status.

would be more clear as

This yearly ping will be required from all maintainers; any maintainer who does not reply within one month will be automatically moved into alumni status.

Are there 2 or 4 maintainer meetings (two types, each held twice)?

There's a typo in the last sentence under Yearly checkins, it says gave where it should be have. Also, that overall process is a little unclear to me. The rationale makes sense, but I don't really know what would be expected of me as a maintainer. Also additional use of ping here is not clear.

A more general question: how are lessons prioritized for getting new maintainers? Especially if people could be automatically moved to alumni status? And could a maintainer be moved to alumni status so that the lesson gets recognized as lacking active maintainers for inactivity of some sort (eg some duration of responding to zero issues or PRs and missing maintainer meetings?)

Even more meta: I think that we would need different maintainer guidelines for the IT curriculum, since we have our own leadership panel and schedule our updates around when we can onboard new trainers, the yearly lesson update probably shouldn't apply. The takeaway from this is that this should probably state which lessons that this policy (or at least that section) applies to. Also incubator maintainers can be in the maintainer community to some extent but may or may not want to be auto enrolled into this. Does this apply to styles? that requires more technical knowledge than most lessons The "all repositories" needs a definition.

[annajiat]

I was hoping if (semi)automated emails were possible and slack DM, maybe:

https://awesomeopensource.com/project/dawidd6/action-send-mail?categoryPage=35 https://github.com/marketplace/actions/send-email

[LucaDiStasio]

Thank you @chendaniely for all the great work done. I understand the intention behind these maintainer guidelines and the need for active maintainers. However, I'm concerned by how it is implemented. It is a concern that I already shared in the context of the Trainers' agreement and I'm worrying it is becoming a standard in the Carpentries. I believe that the all process of "yearly check-ins", "active status", "stepping down and alumni status" will, first, create a high turnover of less-experienced maintainers and, what I'm more worried about, will demotivate and possibly penalize full volunteers with respect to volunteers belonging to a members organizations and other affiliates, and professionals and working parents with respect to students and non-parents. Volunteering on the side of a full-time job and, for those who have, a family is tough. Framing it in terms of "commitment required" risks, I strongly believe, demotivating many, especially when it is asked on yearly basis. Many may probably think to say "not available" to be on the safe side, even if they are willing to and maybe even able to commit to the task. And I say this because I strongly fell I belong to this category. I do see the issue of having active groups of maintainers (as well as trainers, instructors and so on...), but I believe this is not the way to address it. We need to incentivize participation (i.e. provide incentives), not require stricter (albeit to different degrees) time commitments.

[HaoZeke]

Great writeup @chendaniely, sorry I haven't been following along before.

Lead Maintainer Concerns

I realize my opposition should have been voiced in #11 or #14. Nevertheless.. Better late than never.

I'm actually strongly against the idea of a lead maintainer. Our lessons have issues for communicating with the maintainers and I see no reason to consider having a single point of contact.

In particular, I am against establishing a hierarchy where there need not be any. Contentious PRs need to be resolved with inputs from the instructors rather than consensus based on a lesson maintainer hierarchy.

As for being able to respond to rapid queries, this is again a difficult situation. Since maintainers are largely stewarding existing lessons, all decisions need to be based on multiple levels of consensus. What sort of queries would necessitate having this position?

The democratic system (of having all maintainers equal) to me seems like a more rational workflow. Indeed the text is a little unclear to me; it's mainly just a point person if a more rapid response to a question arises. violates There should not be any more additional lesson maintenance work for the lead maintainer.

Alumni and Reactivation

Do we really need to have such strict rules for re-activation? In particular, this process makes little sense to me. Surely maintainers (even alumni maintainers) will wait for consensus before merging problematic PRs and otherwise, for standard maintenance like fixing spellings etc. there should be no need for them to go through an onboarding process.

I was under the impression that the alumni are simply those who ought not to be pinged for maintenance work. With that in mind, this is a simpler alternative hierarchy:

1. Active maintainer
2. Absent maintainer
3. Alumni (removal of all access from the repo)

Where the absent maintainers are simply on a sort of DND (do not disturb) setup; unless they opt-out completely and become alumni. The distinction between active and absent maintainers is then far more flexible than the current setup. We can set a contribution / familiarization limit, say 3 years or on each breaking change (R version change for instance) to prevent absent maintainers from inadvertently making outdated changes.

The Alumni shall remain listed on the README, but are for all intents and purposes a regular member of the community; free to review, comment and open PRs, but not write to the repo or merge.

[sstevens2]

I agree we shouldn't have a hierarchy. However, I do think we should have a point of contact. In my experience with coordinating a community or group it is useful to have someone to point people to. Otherwise there is often an issue of diffusion of responsibility. People feel more welcome and interact more readily when there are clear paths for how to get involved, for example having an on-boarding processes and a single email address. I think having someone who is responsible for coordinating with the other maintainers and being the point of contact would be helpful.

Do folks have other suggestions for how we can support people (and subsequently lessons) who are inactive? I don't think the goals for having people check-in yearly is to get folks to commit more or make them feel guilty for not participating. The goal is to be able to support people when they can no longer be active. We want to make sure our community is robust to when people need to step back and are not able to do tasks. This requires communication about when folks are able to help and when they need to step back. We want new instructors and others to be able to contribute to our lessons and if we don't have a mechanism for maintainers to communicate when they can be active and can't, it is hard to coordinate as a community to address contributions.

I like @HaoZeke suggestion about having an absent maintainer status. It is a nice medium. Then folks who don't reply can stay in the loop a bit longer and it would be possible to make sure that we have at least X number of active maintainers on a lesson.

[sharilaster]

I agree with @sstevens2. For some groups of maintainers, having a person who is responsible for keeping things moving forward is more effective and makes for a better experience for contributors. And, I agree that it is important to have an inactive status that is intended as a friendly and non-punitive way to stay organized as to who is participating. It is a bit awkward to message a group of maintainers when I am fairly confident that certain folks are no longer active. It would be helpful to have a fair determination of what is meant by inactive, so that lessons that need more help can be easily surfaced when there is a call for new maintainers.

I understand wanting to allow people to step back gracefully, and I am sure in many cases opening the door will do just that. But I also think there should be a mechanism to transfer someone to an inactive status if they are not responding at all after a certain length of time. It would be great to have a checklist-type process, along with thoughtful and kind suggested language to let them know if their status has changed, and invite them to reach out when they are ready to return.

[HaoZeke]

Hi @sstevens2 and @sharilaster, I understand that in most cases it is a good idea to have a single point of contact; but specifically for the lesson maintainers I don't understand what kind of situations might arise where one would need to email a "lead maintainer".

Indeed, I would not be in favor of being able to contact any of the maintainers via email in the first place since I strongly favor all design decisions and discussions taking place in publicly accessible issues. We have issue templates and even PR guidelines; why or when would someone need to reach out to an individual?

Most of the PRs have to do with instructor training, and those are covered in training and should not need further consultation with anyone; though I have (and am always happy to) provide guidance on opening PRs when people open issues.

Understanding stagnant PRs and Issues

Part of this dovetails with what I have brought up in the past, with respect to issues and PRs which stagnate. These are typically ones which involve substantive changes to the lesson; which is not something a maintainer should approve of unilaterally (without input from either the curriculum developers or the wider instructor community). This causes some confusion for contributors, but it is still a situation fundamentally out of scope of lesson maintenance.

Note that this is only true of the older established lessons, where the maintainers may or may not be part of the original curriculum development team. For lessons in beta, the workflow is simpler, since the contents of the lesson are in flux.

Another thing to note is that a lot of workshops freely mix and match parts of lessons from various carpentry offerings (which I support) since that makes a lot more sense than trying to change the lesson upstream.

An example

For example, my lesson is a base-R lesson; with no mention of the tidyverse. When people suggest the tidyverse I consider that to be out of scope for my lesson even though many workshops I've taught will borrow from the DC lessons (which have the tidyverse) after the first few sections from my lesson.

In this case, our stance is clear, the SWC lesson at the moment is base-R, and will reject (until the community elects to change the lesson focus) anything which cannot be done in base-R. Many of the other contributions however, are less clear and more open to interpretation (typically best practice additions). These contributions stagnate not because maintainers willfully ignore them but because it is difficult to get the instructors and curriculum advisors' input and come to a decision.

[sharilaster]

@HaoZeke Speaking only from my experience here... When I agreed to be a lead maintainer, initially my understanding was that the purpose was simply to convene the maintainers as a group if/when needed. However, the role has expanded and now includes responding to PRs and issues if no one else steps in to address them. I am still not as timely as I would like to be, but as I am getting more comfortable working with github my response time has improved, so contributors will see a resolution more quickly.

[HaoZeke]

@sharilaster thank you for the clarification. I must admit I am not sure that the duties mentioned are different from those of a regular maintainer.

Conceptually then, to me the maintainer position involves addressing all new contributors ASAP, reviewing and merging what I think is not contentious, while sending review requests for the ones I think need more inputs. In rare cases I escalate things to the upper administration involving the curriculum development team and the wider instructor community. I was under the impression that each maintainer operated in the same manner.

I am generally wary of meetings since they don't really allow for a transparent record (unless minutes are kept publicly).

[LucaDiStasio]

I share the concerns raised by @HaoZeke . It looks like we're changing the structure of maintaining, which may be a possibility but it should be called so. I think we're misidentifying the source of the problem regarding stagnant issues. Maintainers are there to supervise changes and improvements in a framework that is actually agreed upon by the development committee and the instructor community. Thus, it is clear that small PRs (i.e. misspellings, improvements to existing graphics, correcting syntax...) will flow faster and will happen in the early life of a lesson. In the mature life of a lesson, such errors have been mostly caught and PRs will naturally move towards bigger, deeper, more transformative changes of the curriculum which in turn will move them further and further out of the scope of maintainers' responsibilities. And as more people need to be involved in the decision process, these PRs become stagnant. I believe it's actually a natural sign of the maturity of some lessons/curricula. Maybe we should simply update our guidelines to mirror this state of affairs. One last concern is, as I already said before, creating a "lead maintainer" goes in a direction of professionalization of "maintainership", where one person devotes time specifically on this issue managing a wider group of volunteers who can put in less effort. This is a structural change to the activity of maintaining, which is not a bad thing per se but should be called as such. Personally, I disagree with the approach because I believe it will demotivate many volunteers.

[zkamvar]

As we discussed in the last maintainer meeting, the term "Lead Maintainer" is a bit of a misnomer because as it is written, it serves more of a liaison/representative role to the broader community as opposed to leading the maintenance of the lesson. It's certainly not a permanent role and maintainers within a given lesson are encouraged to rotate the title among themselves. You can imagine a system where you have six maintainers on a lesson and they each take "lead maintainer" role for two months out of the year.

[HaoZeke]

@zkamvar that makes sense, however it is again a rather major restructuring. Now maintainers would need to commit to being able to take an involved role 2 months out of twelve and promise availability in advance which would cause anxiety and possibly alienate more experienced maintainers like @LucaDiStasio mentioned. I'm still simply unclear on what function is being fulfilled which is not ordinarily being performed at the moment.

As mentioned a few times above, the lead maintainer, would still be unable to deal with issues brought up in well established lessons.

[libcce]

If anyone is interested in the history of why Library Carpentry has lead maintainers, the background can be found here: https://github.com/LibraryCarpentry/governance/blob/master/curriculum/2019-01-20-summary-maintainer-discussions.md

Notes from our community maintainer meetings can be found here: https://pad.carpentries.org/lc-maintainers

@sharilaster I think you have gone above and beyond the original intent. Thanks for all that you have done!

I think the hope was that we would have another community call, bring onboard new maintainers, others could retire, or continue at a minimum and assist new maintainers.

[HaoZeke]

@libcce Thanks for providing the minutes! However, I can see that for the large number of maintainers most LC repositories have it might make sense to meet; this is not true of many of the other lessons (including my own).

I love our community very much and enjoy meeting all members, however, I don't think there is any need at all to enforce meetings (synchronous) as part of the maintainer workflow.

Additionally, I believe the link might be incorrect; this document discusses the repercussions of imposing the "Lead maintainer" concept, not the reasoning or discussion which led to consensus.

[libcce]

@HaoZeke The notes captured feedback from those that attended the Maintainer calls. The idea of having an initial meeting came up fairly often, because people had views about the lessons and wanted to discuss. So the lead maintainers were a response and many seemed to be receptive but not all the groups had initial meetings and were fine just as is. So there was no enforcement, and I think I would agree, that we wouldn't want to enforce. This was all voluntary.

I think my main concern with the maintainers in LC right now is that we need a way to bring on new maintainers and let some others retire, because you can really burn out.

[chendaniely]

The minutes from the last maintainer's meeting are posted here:

https://github.com/carpentries/maintainer-resources/blob/main/2021/2021-04-21.md

I'm still taking and accepting more ideas/comments while putting together all the responses from this issue and from the last maintainer's meeting.

[emcaulay]

I have just become a maintainer this month and am getting introduced to these guidelines and suggestions now. These are great -- glad we are having this discussion.

I find the lead mantainer designation confusing.

I recommend that we adopt a universal approach across all lesson programs (I think that's the right terminology for referring to three entities (Data Carpentry, Software Carpentry, Library Carpentry)). It looks like the Library Carpentry lesson have them on some but not all of their lessons. DC and SWC do not have that designation. Therefore, I recommend we solicit feedback from the current lead maintainers about their roles and their experiences. If they are favorable about the situation, then we should ask all the remaining maintainers if they feel they have need of this role.

In other words, I think the experience of the lead maintainer about the role should be given more weight than the hypothesis that the role is needed. @sharilaster commented above, and she is a maintainer on two LC lessons. @dakane and @partiecolored are the other two lead maintainers.

[emcaulay]

I very much like the annual maintainer commitment contact verification. I think that's responsible and practical. Ask for an annual commitment, give the opportunity to bow out or re-up each year.

I agree with @brownsarahm about using something more descriptive / formal than "ping" in the guidelines themselves. Hence my phrasing "annual maintainer commitment contact verification."

I would also request that we have a mechanism that is more frequent than annual for removing dormant or absent maintainers.

I'll be honest, there were so many maintainers listed for the Library Carpentry lessons it never occurred to me there would be room for me. Turns out what was listed wasn't up to date. So not only are we sending people in the wrong direction by listing inactive maintainers for as long as 12 months, but we are also preventing others from stepping forward.

[emcaulay]

@libcce, thanks for the links above to give some context to the Library Carpentry maintainers and the lead maintainer designation.

I was looking at the etherpad and it looked like it was a week of meetings in January 2019, but that's it. Was it like a deep dive or a sprint? I am asking a little in part because I was worried that there might be a library carpentry maintainers group that I didn't know about and hadn't yet synced up with.

[partiecolored]

Hi @emcaulay ! Thanks for starting this conversation. I will say that as lead maintainer, I feel an obligation to review/merge changes to the lesson, or weigh in on a discussion. Someone will tag me and I'll do whatever has been requested as soon as possible. I don't know what an alternative system would look like; as @sstevens2 mentioned, with no designated lead, there might be a problem with diffusion of responsibility. I would be very happy to rotate off as lead, though! I've been doing it for a couple of years with no indication of how long I am to serve.

[libcce]

@emcaulay there isn't a separate LC maintainer community. At least, if there is, it isn't active. @partiecolored highlights my main concern that I've brought up in LC Advisory Group, that I'm sure a number of Maintainers would like to rotate off (including me). Challenge with that is that some Maintainers use separate emails or have moved on, so we almost need to go in and see what their current email addresses are, then ask them whether they would like to rotate off or continue on. I know a number of people also don't really track/respond to The Carpentries messages. As you saw, the LC git lesson doesn't have active Maintainers (I mean, I'm still following but would like to unfollow very soon). Yet another challenge... there may be people that say yes to staying on but are still not active. There may be large turnover here, so in some ways, LC needs to be a bit more proactive in recruiting (the event above that you mention was actually helpful in recruiting Maintainers). But I think this is an important point for the LC Advisory Group to address, helping out our current Maintainers to rotate off (or removing ones that are unresponsive), recruit new Maintainers and then onboard them. You said @chendaniely was addressing this so maybe solved?

[emcaulay]

Thank you @partiecolored for sharing your experience and actions!

@libcce , very helpful background -- thank you!

I think creating an effective communication pipeline between Maintainers generally and whatever Advisory Groups exist in each lesson program will be useful.

@chendaniely has created a survey (which I think closed recently) that was distributed to try to assess named maintainers' current commitment to remaining active as maintainers. Through that survey, I believe he and @ErinBecker are reviewing maintainers across all lessons to see which lessons need maintainers.

I think another idea for recruiting maintainers could be through instructor training. Obviously, being an instructor and being a maintainer engage different parts of your personality, but both contribute to the overall mission of the Carpentries and knowing that there are openings in the maintainer arena is helpful.

I may sound like a broken record, but the impression I got was that the maintainers were the most accomplished / significant / oscar-winning carpentries community members and that there wasn't any need for newer people in that role.

[HaoZeke]

I may sound like a broken record, but the impression I got was that the maintainers were the most accomplished / significant / oscar-winning carpentries community members and that there wasn't any need for newer people in that role.

Sorry @emcaulay, but that most definitely is the wrong impression and we should work actively to remove materials which indicate that. In fact, maintenance of lesson materials does not even actually have much to do with instructing (actually there is no overlap). Lesson maintainers need not be instructors in the first place, they are a third pillar, a companion to admin and the instructors.

I should emphasize that the maintenance of a lesson is simply about being proficient in git, working with instructors / CAC members / admin / other maintainers, and not necessarily anything beyond that.

Not really the place but, another valid route towards being a maintainer (not that this has actually happened so there has never been any need) would be to simply contribute time reviewing issues and pull requests. I'm sure the existing maintainers would be grateful and gladly onboard repeat reviewers. This is in-fact the standard in most open source communities.

Indeed, even for fixing breaking changes or prepping for new releases we have dedicated admin members like @zkamvar (who's fantastic). Maintainers are meant to provide some elbow grease, and to make sure incoming instructors or contributors feel acknowledged.

Perhaps another question which hasn't really been covered. Are there any real reasons to "retire" maintainers in the first place other than them opting out voluntarily to prevent notifications? Burn out is one thing, but again, the expectation level seems to be rather high here. In most communities, all maintainers are on a best effort basis, and as long as someone is working on the backlog it shouldn't really be a problem. To me, the new guidelines feel strangely punitive, as if being away from the position would imply that the skillset is revoked.

As a concrete example, @chendaniely used to be a maintainer for my current lesson and I don't think he should have to have his status revoked, or be removed from the repository. So really if he ever wanted to help out with one of the PRs or even merge a few typo related PRs, why would I demand a new training process for him? Are we assuming malicious behavior if a maintainer wants to come back and help out?

[gcapes]

Inactive maintainers

Are there any real reasons to "retire" maintainers in the first place other than them opting out voluntarily to prevent notifications?

If a lesson has e.g. 4 maintainers it looks like there's enough people to share the workload. However if only 2 maintainers are actually contributing regularly it's harder work for those who are active. There's probably some status/prestige/CV fodder in being a maintainer, and I think this should be earned by actually being an active maintainer.

My experience is that it takes a long time to get an inactive maintainer removed and a new maintainer appointed. Indeed the reason I started maintaining one of the lessons I do is that I was constantly frustrated with slow response times to my PRs from existing maintainers and just asked if I could maintain the lesson too.

For clarity and to avoid the above situation, I think it's probably best to remove inactive maintainers. If someone changes their mind at a later point and is now able to give more time to the role, they can reapply.

Hitting pause

I think someone alluded to taking a short break: it would nice if there was a mechanism to do so, and communicate it to the other maintainers and I guess the Carpentries staff too. When I was on extended parental leave I asked if there was anything I should do, and the only suggestion was to set my GitHub status to 'busy'.

[HaoZeke]

Inactive maintainers

Are there any real reasons to "retire" maintainers in the first place other than them opting out voluntarily to prevent notifications?

If a lesson has e.g. 4 maintainers it looks like there's enough people to share the workload. However if only 2 maintainers are actually contributing regularly it's harder work for those who are active. There's probably some status/prestige/CV fodder in being a maintainer, and I think this should be earned by actually being an active maintainer.

My experience is that it takes a long time to get an inactive maintainer removed and a new maintainer appointed. Indeed the reason I started maintaining one of the lessons I do is that I was constantly frustrated with slow response times to my PRs from existing maintainers and just asked if I could maintain the lesson too.

For clarity and to avoid the above situation, I think it's probably best to remove inactive maintainers. If someone changes their mind at a later point and is now able to give more time to the role, they can reapply.

Hitting pause

I think someone alluded to taking a short break: it would nice if there was a mechanism to do so, and communicate it to the other maintainers and I guess the Carpentries staff too. When I was on extended parental leave I asked if there was anything I should do, and the only suggestion was to set my GitHub status to 'busy'.

I very highly doubt there is any CV clout in maintaining (not to disparage efforts) and I think your experience (asking to maintain) is the right attitude instead of having more rigid mechanisms in place to deactivate maintainers. There will always be cases which fall through the cracks.

Even under the proposed rules, there will be PRs which are not merged fast enough; especially if there are a lot of new maintainers. No matter how many meetings are held/attended; it doesn't really change that.

I don't think saying "we have a better process, please apply when we make a call for maintainers" is better than saying "OPEN AN ISSUE" if you want help.