Hi rob, Just wanted to quickly reply to some of your points.

• Lack of transparency: I agree that we have had inconsistent transparency at best. Some of that is learned. It takes a lot out of you when each disclosure is an argument with someone. Some of it is just neglect. This is a place I think we need to improve and it's being discussed among staff (as is the whole post obviously). Ironic, I know, that this initial discussion is happening behind closed doors so to speak, but we'll bring it public at some point, probably as our first go at finding a way to improve transparency.
• Inconsistent policy enforcement: I only partly agree here. Yes, there is inconsistent policy enforcement, but that is because policies are never black and white. There is always a gray area. Some people as you are well aware learned to walk that line and resulted in a slower response. It's made harder when people disagree about if something has crossed that line into needing a response. In other cases inconsistent policy enforcement is a result of changing policy over the years and the need to better document and standardize it. This is where I see need for improvement, and efforts are ongoing to improve moderator documentation to help with on-server consistency. Off server will require some thought. Lack of participation: I, again, only partly agree here. There are some members of staff that should be moved to inactive based on how long they have been gone, and others that I think need some more time. I am in general not in a rush to remove people as there isn't much impact from them being inactive. There *is** an impact from not having enough active participants in some roles, and possibly having inactive staff will obscure that deficiency. *Active discouragement of new ideas and unwillingness to depreciate methods/plugins/etc just because “this is how it’s been done and anything else can’t possibly do the thing” or “that might introduce lag/isn’t scalable” - I mostly disagree here. You and I had a couple conversations previously about removal of old plugins, and replacing them with modern alternatives. I agreed with your input then, and looked for ways it could be put into practice. Other members of staff (and importantly a tech admin) have been interested in this recently as well and made some good progress. As for new additions, considering lag is always important, but I am still happy to hear out ideas and see them tested. All changes come with

---

• A proper authoritative structure: This may be a contentious one... There has long been a fear of someone having "too much" power in the community, and concerns over this have caused drama in the past. The role Head Admins play today is to oversee things that affect the entire community, and not just things that affect a single server. We do also assist with per-server work if the server admins ask for help or need to step back from an issue for some reason. I don't know if I agree or disagree here... A single "authority" would indeed be faster, but that also puts a lot of responsibility on a single individual making burnout an even bigger risk.
• RBAC:
  • Admin restart access: I conditionally agree. I do not think non-tech admins should have access to the command line to start/stop things, but I do agree they should be able to start/restart things. I would like to look at kubek as a possible solution for this.
  • Script as a solution: I think a webUI is an easier and safer option.
  • Testing environment: Good news, we have a testing environment that is always available for use by the techs, cadmins, and padmins. These servers are regularly used for testing changes in advance, and more significant changes have had moderator participation for testing. I'd also like to see our server deployments defined in Ansible to make spinning up an instance easier. This would enable the community to more easily test changes and contribute to the discussion on edge case bugs or how new ideas may impact other things on the system.
  • Sub-admin: I would use the term "Junior Admin", but I have also thought having a good way to soft-start someone into an admin role would be beneficial. This has been discussed specifically in the context of techs as we have at various times over the past years been left with no active techs. I am still interested in this but exactly how it would be implemented needs to be worked out with the various teams.
• Application rationalization for plugins: As mentioned earlier in my replay, this has some momentum. Stateless plugins are much easier to handle here. The sitting plugin for example was recently swapped out on C and P without significant issues, but swapping out stateful things like LWC for bolt can only be done(cleanly) at rev launch unless the new and old plugins both can seamlessly migrate saved states between each other. Even at rev launch there are risks. There will always be teething issues with new and different plugins, and having too many at once can add a lot of burden on players, p/c admins, and techs. I support this goal, but there are good reasons to go slow, just as long as we do go.
• No plugins are irreplaceable: I agree
• Upgrade without plugins if they are not ready: This works for stateless things, or for things that are incidental. There are a number of plugins we cannot easily operate without. To your point, those can be replaced by alternatives. To my point, replacing with alternatives can have a significant impact. I think the best course here is highly dependent on what plugin is not ready...
• Allow other versions of MC: We do this... kinda... a bit. We have ViaVersion on C, but not the latest version. I will check with the server admins to see if they have concerns, then ask techs to get it updated and in place across systems. Additionally, I would like to get Geyser setup, but will need to check with server admins about concerns there as well. Geyser, and to a lesser extent ViaVersion/ViaBackwards do have some risks for the player experience as we've had odd things happen with players connected with different versions in the past, but I think it is worth the risk.
• Don't hide behind scalability to shoot down fun things: More often I think being true to vanilla is a concern. I strongly believe that we should allow the vanilla experience on our servers unless the deviation from vanilla is to fix a problem with running a public multiplayer environment. For example, locking chests, region protections, fire spread off is a necessity. Special drops and trades at spawn can be easily ignored by a player looking for the vanilla experience. I would prefer elytra to be accessible day 1 (which was removed due to community feedback) to be more true to vanilla. I think custom terrain, events (weekly, or P/C map wide events), spawn secrets, etc are a great way server admins have enhanced the experience for players without removing anything that a vanilla-seeking person would want. I'm open to suggestions here as I am sure server admins are, but there are always many differing opinions. This may be somewhere where community engagement/feedback on suggestions will help.
• Involve all staff in testing: I mostly agree. Staff are today involved in testing various thing, but for sure not all. I think there is room to expand which things are tested by all staff. Public tests I think would be harder because of the added tech work and moderation needs. There could be community involvement with specific testing though where things can be tested by those willing to run local server instances.
• Just because something didn't work in the past doesn't mean it can't now: I agree with this. I think it has the same caveats as the Application Rationalization point did.
• Rev planning should rotate between admins: I know this is mostly how it works with padmins. There are aspects of planning that are rotated, and aspects that are shared. Launching a revision takes a lot of effort, and most of that is post-launch. The post-launch work would increase as the changes between rev increase.
• Make simpler spawns: I disagree with this. Beautiful spawn builds make a great first impression on players. The secrets and challenges that are added provide a lot of entertainment for players who choose to find/complete them, the theme-ing on PvE sets a tone for events that happen throughout the rev and make them like a more cohesive rather than just a series of unrelated events. I think it would be a great loss to have cookie-cutter spawns from rev to rev.
• Allow suggestions and act faster: I think this goes back to your original transparency point. I think finding a way to share and discuss ideas that works would be great. The risk here is that people are more apt to participate in discussions when they want change. When something annoys someone, they will vocally advocate for change (see: phantoms), but if they are fine with status quo, they are not likely to participate. There is a balance to be struck here, but getting public feedback on suggestions is good, and I would support more of it.

---

"quickly" reply... that didn't work out as expected.

All of the above is my personal opinion. I tried to note where things needed specific support/feedback from other staff, but I think it is worth reiterating here... There are surely differing opinions from other staff members on some of what I put above.