I would be curious to hear more about your estimates @jonringer from an hourly contribution (weekly or total) you suspect you put into release management.
I was considering it, however you are very very active and it was not always easy to tell if that was just typical contributions or release managerial duties.
I was going to re-vamp the release docs, and it should give a pretty detailed schedule of the events. And you can read the tasks ahead-of-time. Usually the biggest “time-sinkers” are just trying to communicate with other NixOS members or teams.
That’s fair. I did 105 commits and 400+ reviews in November. But recently, I feel like @Sandro has taken the “most active” crown. We went from ~2700 open PRs to <2500 open PRs in the week or so that he got commit access xD
There is a reason their github handle is Super Sandro, and now everyone knows why 
The story behind the name is really boring. My old nick was already taken when I registered an account on YouTube and back then they suggested nicknames and Super Sandro2000 was on off them.
I do not plan to be as active as I am right now all the time. Everyone needs breaks and when the global pandemic is over I plan to start again with other hobbies which are very important to me.
To get back to topic: I thought about applying here but I am not sure if I am a good fit. I am not that long with the project, I don’t know much about nixos modules and regularly skip PRs about them and I am not even running NixOS anywhere. On the other hand I run Nix on Debian, WSL and Darwin where I got pretty knowledgeable in the last months, I review a lot of PRs and try to stabilize things as much as possible while still merging quite fast.
I qualify for all the requirements and I think I would be a half decent fit for this so I would like to apply for it if everyone is okay with it.
@worldofpeace and I would like to see some sort of “release team” which could help with the burden of trying to stabilize. Whether or how this would be implemented is still up to debate, but it would be nice to have someone focused on GNOME, one on Plasma, just reviewing PRs, or help with a few other ecosystems. The NixOS community is pretty active, so people will help in various ways, but generally the efforts are disorganized. I like to refer to the NixOS community as a “herd of technical cats”.
Anyway, I hope that my RFCs (second one I’m still preparing) will help with making the releases a lot less stressful for everyone. I think everyone who has contributed to NixOS is invested in some way, and we all want to see it succeed.
[RFC 0080] Change NixOS releases to YY.05,YY.11 by jonringer · Pull Request #80 · NixOS/rfcs · GitHub has been accepted. New timeline is 21.05 and 21.11 for the next release manager.
Initial post has been altered to reflect those changes.
I’m also realizing there’s no “What to do if no one volunteers”. A deadline would probably be useful so everyone can see “this is a pressing matter”.
I’m fine with being a solo release manager for a release, but I think it would be helpful for the “health” of NixOS if more people were familiar and involved with the process. I would prefer for someone to volunteer, but don’t consider it critical either.
It would be actually dangerous if no one volunteered because the process we have currently works via the exchange of knowledge between two release managers and their collaboration.
That would essentially break what’s in the RFC, and actually considering how easily this could happen I would say it’s a fatal flaw.
The following I could see somehow happening:
the aforementioned break in the change of reappointment
reappoint each other continuously
we could have a monopoly over the position and be terrible to behold (not that anyone would complain 
)
There’s no protections against it. Like idk maybe not appoint two people from the same company.
RM B wants person C, but RM A thinks that’s a bad choice. Now we could handle
that like cordially or RM B could just go ahead and announce their appointment and ignore RM A.
RM A could either be quiet about it or have to make a big fuss with no clear way on how to remove both of these people now. (worst case) There’s probably some obvious ways to resolve that effectively.
A good thing currently about the two person team is, one gets incapacitated in some manner everything could possibly still be fine. But beyond that it’s like a novel with a bunch of plot holes. We’d probably have to make it up as we go if conflicts arise. I think the worst process crisis is when there is none, or there’s one but you can’t change it and it sucks. Currently we haven’t had a crisis with this, but we have other process crises like appointing nixpkgs committers and that one’s like having a leaky IV.
With all that in mind, I don’t think in all the releases something terrible like any of those things I mentioned has happened . But as time goes by and we’re building momentum towards making this position better and more people being interested, I think it’s important to analyze these possibilities and consider how this process feels and treats others. The role of an RM after all is to manage risks.
Is the 2 RM system set in stone anywhere? I was under the assumption it was, so that there was always one “newbie” per release (as a new set of eyes, as well as to prevent RM burnout by constant rotation).
Relatedly: I’d definitely volunteer as part of the “release team” (considering my discussed-elsewhere “releng” team idea), but I personally don’t think I could take on the mantle of RM.
(EDIT: worldofpeace posted just before I finished drafting my thoughts…)
An RFC even isn’t stone. It could be amended or replaced. But I evaluate the status quo as is it beneficial or detrimental, and in what ways? I’m thinking that this RFC as it works currently with two people is just fine, but it’s lacking details in many ways like I mentioned and it’s being a bit optimistic of people.
I haven’t really felt this way about any active member in the community. Maybe I am just naive. Really, anyone who is already active in the community, and willing to “put up” with doing a release will likely be a good candidate IMO.
EDIT: You mentioned later this hasn’t really happened yet, but just being forward about a possible situation.
From a process standpoint, this and process sustainability are the big reasons why I would prefer for someone to stand up. Just because I can do a solo release, doesn’t mean I should do a solo release.
Absolutely agree, it’s why the current and my future RFC’s (I’ll be making two more, one for doing a “mini-ZHF” on master between release to remove stale/obsolete/unmaintained packages; and another re-defining how we do stabilization with a more concrete schedule) will be about mitigating the risk going into stabilization.
I’d suggest that those that are actively merging nixpkgs pick their favorite candidate and ask them to help out 
@worldofpeace @domenkozar and I had a meeting earlier today. We would like to announce the creation of the “Release Engineering Team”.
A release member will coordinate with the release managers and other release members to help aid with the release work. Release members will be able to come and go as they please, so they can participate for just part of the release. This position is really targeted at individuals who may want to play a more active roll in NixOS and aid in a release, but not want to dawn responsibilities of a “Release Manager”. Also, since there’s plenty of work which can be done through PRs and PR reviews, these positions are also open to individuals who don’t have commit access.
Release members can be responsible for:
Unfortunately, I’m unable to edit the original post, as too much time has gone by. Please refer to the post above for information regarding information about release member responsibilities.
If someone would still like to be the next Release Manager, the position is still vacant.
With [RFC 0085] NixOS Release Stabilization: ZHF on master, new timeline by jonringer · Pull Request #85 · NixOS/rfcs · GitHub and [RFC 0080] Change NixOS releases to YY.05,YY.11 by jonringer · Pull Request #80 · NixOS/rfcs · GitHub the amount of potential headache for a Release Manager should be greatly mitigated. Please re-evaluate if you would like to apply for the position
If this is worth an item on its own, I can take on responsibility for machine learning packages.
I love this idea! As a non-committer and relative newbie I’m not trusted or qualified to be a full release manager, but I would really like to help out how I can on the release team. I got started making active contributions to Nixpkgs during 20.09 ZHF and I want to learn more about the release process.
Is there a list of things that are up for ownership? Packages or entire families of packages that need attention? Basically asking about a few concrete tasks for the release member role so I can better assess if it’s something I have the time and skills for.
I’d like to add that this role is an excellent opportunity to get familiar with the Nix ecosystem and community.
@jonringer is now working at IOHK, after being quite active in Nix community and doing the release management.
It’s important to have good communication skills, as one of the main tasks is to decide how to handle breakages with limited resources and potentially angry users