Community amendment 1#29
Conversation
gdude2002
added
draft
Laarryy
left a comment
Laarryy
left a comment
There was a problem hiding this comment.
!! Thanks for the work in writing this up!
| discussion. This may be a result of observations made by the Community Team, suggestions from community members, | ||
| or otherwise - but the Community Team should always discuss before putting forward a candidate, and they should | ||
| ensure that the candidate is actually interested in the position they're being put forward for. | ||
| 1. Candidates must be interviewed by a Community Manager before the election process can continue. All voting members |
There was a problem hiding this comment.
Is making it a requirement that a CM begins the interview necessary? I don't see how it would be a problem since that's what's been happening, but I'm not sure strictly enforcing it is necessary either.
There was a problem hiding this comment.
I don't think it's necessarily a hard requirement, but it's something that should be a Manager responsibility rather than a Moderator one - if anyone's gonna accidentally put their foot in their mouth, it should probably be a manager haha
| Community managers must be appointed democratically, following the process outlined later in this document. If | ||
| required, the keyholders will handle handing out the permissions required for community managers to work in Quilt | ||
| community spaces. | ||
|
|
There was a problem hiding this comment.
Perhaps adding a section for what tools/abilities Community Manager, Moderator, Trainee Moderator, and Admin are given is something that should be done? I'll give an example suggestion under Moderators, since that's the only one I'm completely sure I know what tools I have access to (things like banning, modmail, etc)
There was a problem hiding this comment.
I think this is something that's likely to change over time, as we open up new spaces and existing spaces change and get updated - maybe we should list it somewhere, but I want to avoid having to create a new RFC amendment every time those requirements change
| * To engage with the community authentically, being present and visible in the community when able and appropriate | ||
| * To be supportive of other Community Team members, providing insight, advice and support when able and appropriate | ||
| * To help with the planning and running of community events and projects, when able and appropriate | ||
|
|
There was a problem hiding this comment.
Suggestion to include here what tools/powers are available to the 'basic' Team. I propose only what is strictly essential for the position. For example, moderation powers will not be required, but in order to participate in electing new team members, ModMail viewing permission at least will be necessary.
There was a problem hiding this comment.
The way it currently works is that moving a modmail thread out of the "Backlog" category and into one of the others will prompt you to sync perms. If you decline this, only mods and managers can see it - if you accept, admins can also see it.
Of course, once this RFC is in, we'll need to reorg the community team role structure a bit - but it's the same kind of idea.
mrmangohands
left a comment
mrmangohands
left a comment
There was a problem hiding this comment.
Generally this is looking good to me aside from the question about Admin votes.
Co-authored-by: MrMangoHands <mrmangohands@protonmail.com>
Co-authored-by: MrMangoHands <mrmangohands@protonmail.com>
|
I'm removing the WIP status from this PR, and I'll post it in the meta channel for those that may want to comment. |
A summary of the changes made within this amendment follows: * Keyholders are explicitly no longer members of the Community Team, but they're still welcome to oversee the community team's decisions and processes and provide feedback and insight if they wish. This also means they're no longer considered to be voting members. * It's no longer required that all Community Team members are moderators. While the majority of the Community Team should be moderation and management staff, there's also room for event managers, organisational supports, and so on. * Trainee Community Moderators have been defined, and new Community Moderators must go through a training period before they can graduate and become Community Moderators. Trainee Community Moderators do not vote on internal polls, and are not expected to handle difficult situations. * The process for handling internal votes has been separated out from the rest of the processes, and standardized. This allows for a consistent voting process regardless of what's being voted on, while still allowing for extra closing, failing and passing conditions as required. Failing conditions also override passing conditions, instead of the other way around. * The voting process now takes abstentions into account, both explicitly (where the voting member states they're abstaining) and implicitly (where the voting member simply doesn't vote). * Admins are no longer considered to be voting members unless they're part of the Community Team, or consensus for a vote cannot be reached. * For Community Team elections, the interview now comes before the vote, rather than the other way around. * A new process to be followed when existing Community Team members wish to switch their role or take on new roles has been written.
8 participants
Rendered View
PR to address a bunch of changes that need to be made to the community team's governance and structure.
A summary of the changes made within this amendment follows:
team's decisions and processes and provide feedback and insight if they wish. This also means they're no longer
considered to be voting members.
should be moderation and management staff, there's also room for event managers, organisational supports, and so on.
they can graduate and become Community Moderators. Trainee Community Moderators do not vote on internal polls, and
are not expected to handle difficult situations.
allows for a consistent voting process regardless of what's being voted on, while still allowing for extra closing,
failing and passing conditions as required. Failing conditions also override passing conditions, instead of the other
way around.
abstaining) and implicitly (where the voting member simply doesn't vote).
vote cannot be reached.
been written.