This question is not easy to answer (for me at least) but I will try my best.
Most things that annoy me in my regular (day- and night-time work) that are low-effort are already fixed (by myself or somebody else) in nixpkgs/hydra or in nix via downstream patches. This is why to me personally, only medium- to large-effort tasks remain, although these can be broken down into smaller chunks.
While I’m happy to have the knowledge to fix these smaller issues myself, I am also aware that not everybody has this knowledge, especially newcomers which can be very frustrating. The onboarding of new users has gotten a lot better over the years, but a lot issues (especially when trying to understand the basics) remain (see also the next paragraph on that).
Two major points I’m going to mention but not discuss any further are a high dissatisfaction with the instability of cli-interfaces and the lack of documentation in general. I got around that issue by suffering through reading code and trial/error and I know this situation improved a lot and I love seeing that work is being done by you. Documentation is the most important thing (especially for new users) imo, but also for more advanced users. Just having complete lists of things like builtins and advanced derivation attributes would be a great help.
Last-minute addition (but potentially not relevant for this thread): I also think it’s weird to newcomers who want to learn about NixOS and go to https://nixos.org (which clearly indicates a operating system in its domain) to have no information on the distribution whatsoever. The only places the distro is mentioned is the announcements, the manual and the download area afaict. That seems like not too much effort to change while potentially being high-impact to new users. Also compare the website to Arch which clearly states what Arch is in the first paragraph and Debian which mentions the existence of an operating system prominently on the landing page.
But you pinged me because I am on the team list as the 22.05 RM so I’ll try to focus on topics that were hard to deal with when I did the release. It’s 3 points essentially, most of these are hard to estimate the effort of.
It’s not clear at all who is responsible for what. When I had a subsystem or something, I usually knew who to DM because I just learned these names over the years. To somebody who is more absent in the community, it’s hard to know who to ask and who can make authoritative decisions. As an example, I had to work a lot with the Staging team during the release. Most responses and decisions were made by @vcunat. There’s nothing wrong with that and I’m glad he helped me throughout the process, but there is technically no reason to trust him with these topics (other than that I know he does a lot of staging things) and there is also no reason to not make decisions myself when somebody asks something in the Staging Matrix room. If he and I got into a disagreement in the channel, who would be the one to make a final decision?
This is also an annoying point when leading a team yourself. I was the Release Manager and I had to make every decision that didn’t directly impact a subsystem myself. While I know this is one of the tasks of the job and I just decided a lot of things, sometimes it felt like somebody higher up should make a single decision. Only issue being that there is nobody higher up, there’s nobody I could ask. The only one was @jonringer who was able to answer me some questions but only because he did releases before. He didn’t have any official saying in anything. Again, I’m really glad he helped me (even in a phase where he had limited time), but it just seems like there should be a more formal structure.
This is something where I can see the new board bootstrapping a structure of responsibilities. I don’t expect them to choose responsible people for each and every area of the ecosystem, but forming a top-level structure where sub-structures can build themselves would be a great start. Just finding a small team who manage the subsystem teams on nixpkgs for example would be awesome. These responsibilities should however not come without anything in return. Financial compensation is probably not possible or fesible and the ability to have authority is not enough for some people so I really don’t know what to do with this.
Goes hand in hand with my previous issue. How do I communicate with teams? Do I just DM Graham because I know he has admin rights in the infrastructure or do I use the channel where responses may be slower? There is no clear way on how teams communicate (which is probably also caused by my next point) and since there is no feeling of responsibility, questions in Matrix rooms often stay unanswered.
While the communication in one direction (me having a question about a subsystem) does often not work, the other direction is difficult as well. There is no proper way to convey current information about changes to users of your subsystem, other than writing a full Discourse post which often feels too heavy as something the weight of a tweet would have been good enough.
Some very important areas of the ecosystem have a horrible bus factor (1 or 2 if we’re being lucky). This doesn’t help with the previous point as there may be nobody answering my $SUBSYSTEM question just because the only person who maintains it is on vacation. That is horrible to new users who may get the feeling that areas are unmaintained and left to rot. This also means that having a user drop out of the community may cause a subsystem rotting for a while. As there is no higher authority who oversees the teams, there is no pressure to re-form a team in that event as there is no leadership anymore.
This is probably not too much effort to fix, just reminding people that there are teams/subsystems/areas that are completely unmaintained and ungoverned often helps. Whether a area is actively maintained or just in maintenance mode is up to the respective team, then.
Now that I write down these points, only the first one seems relevant and the other ones are something that feels like it cannot be controlled without a lot of effort. I’m still going to post this because I think my experiences as RM in the context of this thread are worth writing down. Also, as most community members have never been RMs, these viewpoints may not be clear to everyone. If you want to chat about the topic of release management, feel free to reach out to me in the Release Management room.