The issue of infrastructure access was raised to me, and I subsequently found out the issue has come up in a number of past meetings.
Infrastructure access has been discussed before, (by me and others) and changes were made and implemented. There was a lot of communication then, and not all of it was pleasant, but the community worked through it. So we can do it again. It was ultimately productive: This discourse instance and the server it runs on were direct consequences.
My experience is that the most constructive conversations state what the issue is and possible solutions. It’s easier to focus on the facts like “I couldn’t do X” and say “Y” is a solution rather that state “I ought to have Y”
I’m going to add a default solution based on this issue existing at least a month and I haven’t heard about it:
“Person X could have posted on Discuss[ on behalf of Person Y].”
I’m definitely curious about problems that couldn’t have been solved in a timely manner had that occurred, so I would like to prioritize those.
There’s also the issue of what is considered “infrastructure” and who has domain over what. “Infrastructure” typically refers to critical infrastructure like access control (earl), the wiki, the mailing lists, and perhaps a few other things. As mentioned in the rack guild category, you can read the repo to see who that is. But to be clear, anyone can work on it and commit to it, and anyone can make a PR to become a maintainer.
What is not infrastructure are things like slack, this board, unicorn (this server), pegasus (where mary among other things reside), flashentashen, etc. Basically anything “fun”. Some people may work on both which leads to confusion.
So, to fix THAT, I propose adding a blurb to be read during the meeting about how to help with infrastructure. Something like this:
and also something about how to get help with infrastructure:
Raise an issue on the infrastructure repo is the best way, even if it’s something like their fob doesn’t work or they cannot get their discuss account working.
One positive is all the new people that will join as maintainers on the architecture. As we get to know each other and build trust, we will have a very robust team, and the community will gain better communication about infrastructure.