Discord/RfC 2
Add topic- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- Per the well argued points in the initial RfC and the almost unanimous agreement of a good number of users, this RfC is closed as follows (likely caveat at the end):
- Proposal 1 passes: Roles will be updated eventually(tm) (All users in confidential channels should be pinged, via @ everyone, informing them of the outcome of this RfC. The channels should not be deleted and this RfC should not be implemented in full until this is acknowledged.
- Proposal 1, amendment 1 passes: Only verified Discord accounts may vote for Discord Moderators and Administrators.
- Proposal 1, amendment 1, addendum A passes: A verified Discord account must be present in the server 24 hours before the start of the vote to have their vote counted.
- Proposal 1, amendment 2 passes: Voting shall take place on Discord.
- Proposal 1, amendment 3 passes: Inactivity period is reduced to 3 months.
- Proposal 1, amendment 4 does not pass: Users with current moderation permissions will be required to opt in to a confirmation vote, and succeed in that vote, in order to retain moderator permissions.
- Proposal 1, amendment 5 passes: The proposed administrators will require a confirmation vote.
- Proposal 1, amendment 6: Community will be defined as the Discord servers / members of it.
- Proposal 1, amendment 7 does not pass: SRE and Stewards will not retain any of the mentioned elevated permissions.
- Proposal 2 does not pass: Although it was a viable alternative to proposal 1, it seems moot since proposal 1 will take over all moderation not just moderation of 'public channels'.
- As above, this RfC should not be implemented until confidential channels have histories preserved as needed, and the channels are deleted.
- Additionally, I can't actually enact this RfC in it's entirety on Discord, so. We'll see about that eventually(tm).
- -- Cheers, NDKilla ( Talk • Contribs ) 16:39, 19 April 2021 (UTC)Reply[reply]
- Per the well argued points in the initial RfC and the almost unanimous agreement of a good number of users, this RfC is closed as follows (likely caveat at the end):
This RfC is built using information from User:Void/Discord (permanent link). Any user can add their own proposal, or propose additional amendments to an existing proposal. This RfC opened on 22:31, 21 February 2021 (UTC) and will remain open for at least a week, or at least a week from the date of the last added proposal/amendment. The latest proposal/amendment was added on 18:12, 24 February 2021 (UTC).
Proposal 1[edit | edit source]
- All private spaces (particularly those requiring an NDA to access, or otherwise considered confidential) except those required for server moderation, and non-confidential conversation between special groups will be removed from the server. Any confidential discussion spaces should be created by these groups. Current confidential spaces will be deleted following the implementation of this RfC. If you have access to a confidential space on the Discord server, please copy out all information you will need. You will be given a minimum of 24 hours notice prior to the deletion of the channel.
- Discord moderation abilities will not be delegated based on on-wiki permissions, but will require specific elections. Roles will still exist for on-wiki groups and other delegations, but themselves will not have any special permissions. Instead they will be purely cosmetic and for organizational purposes. Some roles may provide access to private, but not confidential chat venues. Any role requiring a confidential discussion space should instead create one for themselves.
Definitions[edit | edit source]
- flavor group
- A role on discord that provides a unique color, and possible sorting on the user list. It is used to differentiate between members of groups, but does not provide any moderation access. There may be private channels tied to a flavor group, but they are not confidential, and platform moderators will still have access.
- private channel
- A private channel contains information that is not public, but has no confidentiality requirement. Information from these channels should still not be disclosed without a valid reason.
- confidential channel
- A private channel that contains information that cannot be made public, and additionally requires that only specifically vetted persons have access or can access at all.
Roles[edit | edit source]
- Administrator - Discord administrator, has all permissions.
- Moderator - Discord moderator, has access only to required moderation tools.
- Board Member - "Flavor Group" - provides no additional permissions.
- Stewards - "Flavor Group"
- Site Reliability Engineers - "Flavor Group"
- System Administrators - "Flavor Group"
- CVT - "Flavor Group"
- Code of Conduct Commissioner - "Flavor Group"
- Interwiki Administrator - "Flavor Group"
- Former System Administrator - "Flavor Group"
- CSS/JS Support Volunteer - "Flavor Group"
- Nitro Booster - "Flavor Group"
- Bots - "Flavor"/organizational role
- Verified Wiki Users - "Flavor Group"
- *Assorted bot roles*
- Muted - Prevented from chatting
- @everyone
Moderator permissions[edit | edit source]
View Channels, Manage Channels, Manage Roles, View Audit Log, View Server Insights, Create Invite, Change Nickname, Manage Nicknames, Kick Members, Ban Members, Send Messages, Embed Links, Attach Files, Add Reactions, Use External Emoji, Mention all roles, Manage Messages, Read Message History, Send TTS, Connect, Speak, Video, Voice Activity, Priority Speaker, Mute Members, Deafen Members, Move Members.
Moderator membership[edit | edit source]
All current members of discord that have access to moderation powers as a result of their current role will be able to gain access to the proposed Moderator role. However, they will need to pass a confirmation vote with the same level of requirement as being appointed (see below).
- n.b. Confirmation is an opt-in process. Current moderators who do not put forward a confirmation vote within a week of the closure of this RfC will be removed (unless superseded by #Amendment #4).
Appointment[edit | edit source]
Users may be nominated or nominate themselves by placing a request on the Community noticeboard. Whenever the nomination is accepted (if nominated by someone else, otherwise submitting the request is immediate acceptation), a request must stay open for at least seven (7) days. During this period anyone from the Community may comment on a candidate's request. This request will be listed in a dedicated channel on Discord for awareness.
A request will be deemed successful when closed by a Discord Administrator after having achieved a 70% support ratio.
Revocation[edit | edit source]
A moderator may lose their permissions if:
- a request of no confidence in opened against the user and has a more than 50% support ratio, or
- the user is inactive from the community for a period of 6 months.
Administrator membership[edit | edit source]
The initial Discord Administrators will consist of Void, SPF, and NDKilla. Any other Administrator must be appointed following the criteria below.
Appointment[edit | edit source]
Users may be nominated or nominate themselves by placing a request on the Community noticeboard. Whenever the nomination is accepted (if nominated by someone else, otherwise submitting the request is immediate acceptation), a request must stay open for at least seven (7) days. During this period anyone from the Community may comment on a candidate's request. This request will be listed in a dedicated channel on Discord for awareness.
A request will be deemed successful when closed by the server owner after having achieved a 70% support ratio.
Revocation[edit | edit source]
An administrator may lose their permissions if:
- a request of no confidence in opened against the user and has a more than 50% support ratio, or
- the user is inactive from the community for a period of 6 months.
Server Owner[edit | edit source]
The server owner may be selected at any time by the current owner from any of the current Discord Administrators. The community may retroactively overturn this, or elect a new server owner at any time, through a vote requiring the same appointment criteria as the Administrator position. A user must be an Administrator in order to become the server owner. If their Administrator role is revoked for any reason, then they must delegate server owner to one of the current Administrators.
The current server owner is SPF.
Proposal 1 Discussion[edit | edit source]
Support[edit | edit source]
- As proposer. We need a different system for Discord moderation, and I think this is how we get that started. -- Void Whispers 22:31, 21 February 2021 (UTC)Reply[reply]
- Support, but only with amendments. This RfC overall remains too vaguely defined verbatim. Celeste (talk) 01:38, 23 February 2021 (UTC)Reply[reply]
Support The general idea with the amendments below. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
- Conditional support subject to all amendments passing below, per my rationale and comments I articulated earlier on Discord and in #miraheze connect on IRC. Dmehus (talk) 17:48, 24 February 2021 (UTC)Reply[reply]
- Support this proposal but with some of these amendments. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Support Seems reasonable. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
- See [1]. Give 'em a year. Firestar464 (talk) 07:16, 22 February 2021 (UTC)Reply[reply]
- Umm... do you even know why this proposal was created in the first place? Redmin Contributions CentralAuth (talk) 09:16, 22 February 2021 (UTC)Reply[reply]
Strongest oppose This does not make any sense! We let System Administrators be Gods in terms of moderation and SRE became grumpy. We made Stewards Gods and the entire Technical Team started to protest! What is the outcome?: Stewards are the only group of people who are regularly helping users on Discord, which is the platform with the most members (and also the active ones); the entire Technical Team is only available on IRC now. We need to make a new group for moderation. Redmin Contributions CentralAuth (talk) 09:23, 22 February 2021 (UTC)Reply[reply]
- I for myself don't want more community roles. The technical team need to refocus on Technical things. The suggestion is to hand the server to community control rather than Stewards. That's what this does. ~ RhinosF1 - (chat)· acc· c - (on) 11:36, 22 February 2021 (UTC)Reply[reply]
- I do not see where this specific proposal states that. I am thinking of adding a new proposal. Redmin Contributions CentralAuth (talk) 16:29, 22 February 2021 (UTC)Reply[reply]
- Hmm? The entire point of this proposal is that moderation on the server will not be dependent on a user's status as a steward or system administrator. Instead, in order to be a moderator, you will need to be elected by the community. Is that not clear from the text, or are you objecting to something else? -- Void Whispers 19:26, 22 February 2021 (UTC)Reply[reply]
- @Void: Sorry, I had not noticed your message till today. My concern is that if this proposal passes, all current "moderators" will be able to get their rights back with a mere confirmation process. I would like to see them go through a community vote instead. Is my understanding wrong? Redmin Contributions CentralAuth (talk) 07:40, 3 March 2021 (UTC)Reply[reply]
- R4356th See Amendment #4, which covers your proposal 2 if it does not pass, I think. I think there might be a bit of a misunderstanding. A confirmation vote is the same is as a normal vote under which moderators, or administrators for that matter, may be appointed. The same criteria stipulated in "Appointment" and any applicable amendments would apply to both an initial confirmation vote as well as to any votes for new platform moderators. Dmehus (talk) 12:20, 3 March 2021 (UTC)Reply[reply]
- @Void: Sorry, I had not noticed your message till today. My concern is that if this proposal passes, all current "moderators" will be able to get their rights back with a mere confirmation process. I would like to see them go through a community vote instead. Is my understanding wrong? Redmin Contributions CentralAuth (talk) 07:40, 3 March 2021 (UTC)Reply[reply]
- Hmm? The entire point of this proposal is that moderation on the server will not be dependent on a user's status as a steward or system administrator. Instead, in order to be a moderator, you will need to be elected by the community. Is that not clear from the text, or are you objecting to something else? -- Void Whispers 19:26, 22 February 2021 (UTC)Reply[reply]
- I do not see where this specific proposal states that. I am thinking of adding a new proposal. Redmin Contributions CentralAuth (talk) 16:29, 22 February 2021 (UTC)Reply[reply]
- I for myself don't want more community roles. The technical team need to refocus on Technical things. The suggestion is to hand the server to community control rather than Stewards. That's what this does. ~ RhinosF1 - (chat)· acc· c - (on) 11:36, 22 February 2021 (UTC)Reply[reply]
Comment[edit | edit source]
- R4356th's argument has prompted me to have discussions with another member of the SRE team, so I'm going to pause my support at the moment. While I can see R4356th's point about having community-elected global Stewards moderate and/or administer the server, as it is a global community server, I also still prefer a Moderator group to which any Discord server member, regardless of their wiki roles, could run for election, as the Discord server is essentially a separate, local community, albeit one with a global pan Miraheze scope. For another matter, I don't think we've sufficiently articulated the Discord Administrators and Server Owner roles, in terms of whether SRE/Board should have some sort of veto in the selection of a Discord Administrator, given that the Server Owner has access to confidential channels. Server Owner should be NDA bound; that much is a given, but I would think we'd probably want to codify that the Board, or SRE as their delegated party, should be given an absolute veto over the selection of a Server Owner. Finally, will the flavour groups still have access to manage specific channels, upon request, from a Discord Administrator or Server Owner? For example, Code of Conduct Commissioner requires certain read only access to certain channels (namely the
#audit-log
channel); SRE will want to be able to manage their private channel(s) (if any), stewards and/or CVT the same for their channels, and Interwiki Administrators for#interwiki-requests
. Dmehus (talk) 16:22, 22 February 2021 (UTC)Reply[reply]- See the first line of this proposal. There will be no space on the server for confidential information, because of the reasons you state. Therefore, the server owner will not need to be bound by NDA, and no group will have any sort of special interest regarding administrator/owner roles. Access to particular permissions in certain spaces can be worked out later, in collaboration with the new administration setup, once we can put together what we need. -- Void Whispers 19:30, 22 February 2021 (UTC)Reply[reply]
- Void What about the historical private channels, though? Are you proposing to delete the historical channels? I wouldn't be opposed to that, but wouldn't be my preferred outcome. As to channel specific permissions settings, yeah, that seems reasonable, and something that the Discord server administration can handle with respect to certain private, but not NDA bound, channels for certain wiki groups. Dmehus (talk) 19:56, 22 February 2021 (UTC)Reply[reply]
- "Current confidential spaces will be deleted following the implementation of this RfC. If you have access to a confidential space on the Discord server, please copy out all information you will need. You will be given a minimum of 24 hours notice prior to the deletion of the channel."
- Unfortunately, there is no way to have an administrator group with full access to the server without them having access to all channels. I'd consider this to be an unacceptable risk for NDA covered materials, as is the current server setup to be honest. There's also no apparent way to archive these types of channels in a way that would protect the information that may be contained within. -- Void Whispers 20:04, 22 February 2021 (UTC)Reply[reply]
- Would you be able to see if it's possible to dump archives of them on staff wiki or something in case anything came up in future? Not sure if Discord has a backup function. ~ RhinosF1 - (chat)· acc· c - (on) 22:09, 22 February 2021 (UTC)Reply[reply]
- RhinosF1 It doesn't have any easy backup function, but was talking to Reception123 about this. There are, however, some third-party Discord plugins or tools that allow for exports. This might require temporarily disabling two-factor authentication on one's Discord account, though. Dmehus (talk) 22:11, 22 February 2021 (UTC)Reply[reply]
- Would you be able to see if it's possible to dump archives of them on staff wiki or something in case anything came up in future? Not sure if Discord has a backup function. ~ RhinosF1 - (chat)· acc· c - (on) 22:09, 22 February 2021 (UTC)Reply[reply]
- Void What about the historical private channels, though? Are you proposing to delete the historical channels? I wouldn't be opposed to that, but wouldn't be my preferred outcome. As to channel specific permissions settings, yeah, that seems reasonable, and something that the Discord server administration can handle with respect to certain private, but not NDA bound, channels for certain wiki groups. Dmehus (talk) 19:56, 22 February 2021 (UTC)Reply[reply]
- See the first line of this proposal. There will be no space on the server for confidential information, because of the reasons you state. Therefore, the server owner will not need to be bound by NDA, and no group will have any sort of special interest regarding administrator/owner roles. Access to particular permissions in certain spaces can be worked out later, in collaboration with the new administration setup, once we can put together what we need. -- Void Whispers 19:30, 22 February 2021 (UTC)Reply[reply]
Question: "Current confidential spaces will be deleted following the implementation of this RfC." Why is this being proposed? Even if there is a valid argument for deleting them, why not archive them instead? Redmin Contributions CentralAuth (talk) 07:44, 3 March 2021 (UTC)Reply[reply]
Question: How will administrators get their permissions? Using the built-in Discord flag or a role? Redmin Contributions CentralAuth (talk) 12:38, 16 March 2021 (UTC)Reply[reply]
Amendments to Proposal 1[edit | edit source]
These amendments are independent of the proposal, but if they pass, they will alter the scope of the original proposal. Feel free to add any additional amendments, but be sure to point to what part of the proposal they alter.
Amendment #1[edit | edit source]
A user is only eligible to vote upon new Discord Moderators/Administrators if they have a verified Discord account. (Alters #Appointment and #Appointment 2)
Support[edit | edit source]
- Strongly support per the nomination. Dmehus (talk) 22:35, 21 February 2021 (UTC)Reply[reply]
- Firestar464 (talk) 06:43, 22 February 2021 (UTC)Reply[reply]
- Support, as a safety measure to prevent sockpuppetry. Celeste (talk) 17:11, 22 February 2021 (UTC)Reply[reply]
Support Makes sense as a security measure. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
Strongest support This should've been implemented a long time ago, even if I joined Miraheze a year ago. DarkMatterMan4500 (talk) (contribs) 18:01, 24 February 2021 (UTC)Reply[reply]
- Yes--MrJaroslavik (talk) 21:03, 24 February 2021 (UTC)Reply[reply]
- Logic. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Support Sure. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
- It would not make sense if this is not implemented. We obviously do not want impersonation. Redmin Contributions CentralAuth (talk) 07:46, 3 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Comments[edit | edit source]
Makes sense, but we don't necessarily have a good way to verify wiki accounts to Discord accounts, but the reverse exists. (Correct me if I'm wrong). -- Void Whispers 22:31, 21 February 2021 (UTC)Reply[reply]
- Void We have WikiAuthBot which verifies the wiki account to the Discord account. That satisfies me in terms of verifying whether the user is an active user of the Discord server. Dmehus (talk) 22:35, 21 February 2021 (UTC)Reply[reply]
- I would personally support a harsher amendment, such as one requiring having been on the server at least 24 hrs before the vote started. This would aid conserving vote integrity. Celeste (talk) 17:11, 22 February 2021 (UTC)Reply[reply]
- That's a good proposal, Celeste. Did you want to add that as Amendment #1-A? Dmehus (talk) 17:13, 22 February 2021 (UTC)Reply[reply]
- I wouldn't mind. Celeste (talk) 17:18, 22 February 2021 (UTC)Reply[reply]
- Celeste, sure. Feel free to add it below this section, and I'd support that. 24 hours seems reasonable without being unduly restrictive. Dmehus (talk) 17:19, 22 February 2021 (UTC)Reply[reply]
- Dmehus To be completely honest, this should've been made when the server has existed to begin with. DarkMatterMan4500 (talk) (contribs) 18:06, 24 February 2021 (UTC)Reply[reply]
- DarkMatterMan4500, I agree, though in fairness, as I'm sure Reception123 and NDKilla will agree, the Discord server was much smaller then and primarily used for technical reports requiring system administrators' action rather than stewards. Dmehus (talk) 18:09, 24 February 2021 (UTC)Reply[reply]
- Dmehus To be completely honest, this should've been made when the server has existed to begin with. DarkMatterMan4500 (talk) (contribs) 18:06, 24 February 2021 (UTC)Reply[reply]
- Celeste, sure. Feel free to add it below this section, and I'd support that. 24 hours seems reasonable without being unduly restrictive. Dmehus (talk) 17:19, 22 February 2021 (UTC)Reply[reply]
- I wouldn't mind. Celeste (talk) 17:18, 22 February 2021 (UTC)Reply[reply]
- That's a good proposal, Celeste. Did you want to add that as Amendment #1-A? Dmehus (talk) 17:13, 22 February 2021 (UTC)Reply[reply]
Amendment #1, Addendum A[edit | edit source]
For the purposes of voting, it is highly possible that a user may attempt to vote using a second (or further) Discord account - an act of sockpuppetry. As such, votes on Discord require the user to be present at least 24 hours, on the server, prior to the start or announcement time of a vote. (Alters Amendment 1)
Support[edit | edit source]
- Per the above. Celeste (talk) 17:24, 22 February 2021 (UTC)Reply[reply]
- Supporting per the amendment addendum's rationale and comment rationale above that. It's both minimally restrictive and reasonable in terms of attempting to prevent votestacking and Discord sockpuppetry. Dmehus (talk) 17:26, 22 February 2021 (UTC)Reply[reply]
Support Per above, makes sense as a security measure. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
- I think, if user have more accounts that are linked to one wiki account, it can be checked after vote.--MrJaroslavik (talk) 21:06, 24 February 2021 (UTC)Reply[reply]
- Logic too. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Support Sure. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Comments[edit | edit source]
Not sure if this would help. One could simply have both sockpuppets present within said time range. Firestar464 (talk) 02:59, 23 February 2021 (UTC)Reply[reply]
- Firestar464 How do you mean? Can you clarify that a bit? Dmehus (talk) 03:17, 23 February 2021 (UTC)Reply[reply]
- One could log both accounts in, start up a bogus convo, and then vote. Firestar464 (talk) 03:20, 23 February 2021 (UTC)Reply[reply]
Amendment #2[edit | edit source]
Voting shall take place on Discord through a dedicated channel. (Alters #Appointment and #Appointment 2)
Support[edit | edit source]
- Strongly support, as we want to ensure that those active on the Discord server are the ones voting for platform moderators. In keeping with local consensus-based decision-making on local wikis or other platforms, each official chat platform should elect their own platform moderators. Any users, can, of course, join the respective chat platform(s) and participate in the voting, but it wouldn't make a lot of sense to use another venue with no way of verifying whether the user is active in the Discord server. Dmehus (talk) 22:40, 21 February 2021 (UTC)Reply[reply]
- Support. Celeste (talk) 17:12, 22 February 2021 (UTC)Reply[reply]
- Firestar464 (talk) 03:00, 23 February 2021 (UTC)Reply[reply]
Support Based on the setup proposed by Dmehus below, I think this would be a good way for voting to proceed and therefore only have Discord users vote. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
- I prefer this, as these new roles only concerns the Discord server. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Support Sure, that can work. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Comments[edit | edit source]
Not quite sure how this would be setup, if anyone has any ideas, let me know. This will need to be sorted prior to implementation. -- Void Whispers 22:31, 21 February 2021 (UTC)Reply[reply]
- Void Discord offers voting icons, which could be reacted to. So, my understanding is we'd just setup a channel on the Discord server, state the nomination, have users react by voting, and then reply with their comments. Dmehus (talk) 22:40, 21 February 2021 (UTC)Reply[reply]
Amendment #3[edit | edit source]
For the purposes of revocation, the inactivity period is reduced to 3 months instead of 6. (Alters #Revocation and #Revocation 2)
Support[edit | edit source]
- Strongly support. Makes sense to me. Elected platform moderators should be active on the server they've been elected to moderate. Dmehus (talk) 22:42, 21 February 2021 (UTC)Reply[reply]
Support I think it's reasonable to expect a moderator to participate on the Discord server regularly. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
- I can imagine 1 month.--MrJaroslavik (talk) 18:40, 24 February 2021 (UTC)Reply[reply]
- I could support 1 month as well. If someone is completely inactive from the server for 1 month, then no need for them to have a moderator role. Feel free to propose an Amendment #3, Addendum #1 if you want, or we can just propose to change this at some later time maybe? Dmehus (talk) 18:52, 24 February 2021 (UTC)Reply[reply]
- A moderator or a administrator should be active, so I prefer three months. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Support Sure, that's fine. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
Weak support Three months is too much whereas one month is too less. I would prefer one and half a month. Redmin Contributions CentralAuth (talk) 07:50, 3 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Comments[edit | edit source]
Amendment #4[edit | edit source]
All current members of discord that have access to moderation powers as a result of their current role will be able to gain access to the proposed Moderator role through an opt in process. This process closes a week after the closure of this RfC, and any further moderators must be appointed. No confirmation vote will be required. (Alters #Moderator membership)
Support[edit | edit source]
Strongest support I most definitely support this proposal. DarkMatterMan4500 (talk) (contribs) 22:50, 21 February 2021 (UTC)Reply[reply]
- Support. For greater clarity, the current lineup of existing platform moderators,
notwithstanding myself who will resign as a platform moderator upon this RfC's closing,includes Void, NDKilla, Reception123, Southparkfan, Paladox, MrJaroslavik, and myself. I'm happy with that lineup, and additional platform moderators can always be elected as needed. Dmehus (talk) 22:54, 21 February 2021 (UTC)Reply[reply] Support Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
I know about the arguments who was said below, but we need anyways a stable base for start with these new roles. We will probably have new persons later. :p HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Oppose This is probably a useless attempt, but now I think I'd prefer there be a confirmation vote. K599 (talk) 02:03, 3 March 2021 (UTC)Reply[reply]
- To be a bit more clear, from what I know, these people were given access to moderation powers because they were part of on-wiki groups, not based on how they would handle moderating the Discord server, so I think it would be better to have a confirmation vote so that the community can decide if each of them would be suitable as a moderator. K599 (talk) 17:30, 3 March 2021 (UTC)Reply[reply]
Strongest oppose This is totally stupid. Redmin Contributions CentralAuth (talk) 07:31, 3 March 2021 (UTC)Reply[reply]
- I prefer to do a confirmation vote so we can expose problems to users if there are any. HeartsDo (Talk / Global / Wiki Creator) 17:54, 3 March 2021 (UTC)Reply[reply]
- Confirmation needed for everyone!--MrJaroslavik (talk) 22:35, 16 March 2021 (UTC)Reply[reply]
Comments[edit | edit source]
Procedural Comment: Amendment #4 was proposed prior to making my decision to resign from platform moderation responsibilities. So, for greater clarity, Amendment #4 should be read as, "All current members of discord, notwithstanding Dmehus, who has subsequently announced his intention to resign as a Discord platform moderator upon this RfC's closing, that have access to moderation powers as a result of their current role will be able to gain access to the proposed Moderator role. No confirmation vote will be required." Dmehus (talk) 22:44, 21 February 2021 (UTC)Reply[reply]
- To clarify the current language does not require that the current moderation-capable users migrate to the new group, but instead can opt in, or opt out. (This should perhaps be clarified better). -- Void Whispers 22:54, 21 February 2021 (UTC)Reply[reply]
- Agreed that this should absolutely be clarified better. If it's opt-in, what's the timeframe for them opting in? If it's opt-out, that's fine, as they can always opt-out. For reasons of logistical simplicity, I think we should use an opt-out approach, with a timeline to advise a current platform administrator of whether they will be continuing after this RfC closes. Dmehus (talk) 22:57, 21 February 2021 (UTC)Reply[reply]
Amendment #5[edit | edit source]
The proposed Discord Administrators list will require a confirmation vote following the RFC. (Alters #Administrator membership)
Support[edit | edit source]
- Strongly support. This makes sense as well. Discord server administrators have access to an additional toolkit, and we're proposing to revamp the current Discord administrators, so it makes sense that this initial crop of server administrators should require a reconfirmation vote on the platform following this RfC's closing. Dmehus (talk) 22:51, 21 February 2021 (UTC)Reply[reply]
Support If we're making these changes, it makes sense to me to have a confirmation vote. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
- Seems logic for see which persons we will keep as an administrator. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Support Sure. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Comments[edit | edit source]
Amendment #6[edit | edit source]
For the purposes of the Revocation clause, community is defined as the Discord server. (Alters #Revocation and #Revocation 2)
Support[edit | edit source]
- Makes sense as a way to further separate the Discord server from the rest of the community, and so as to not have there be any confusion. -- Void Whispers 22:31, 21 February 2021 (UTC)Reply[reply]
- Strongly support per above, and because this is in keeping with local consensus-based decision-making. Local wiki communities, or other platforms, elect their teams, and established policies. As such, it's only fitting that members of the Discord server should elect their platform moderators and administrators. Dmehus (talk) 22:48, 21 February 2021 (UTC)Reply[reply]
- Support, since site activity doesn't necessarily translate into Discord activity. Celeste (talk) 17:14, 22 February 2021 (UTC)Reply[reply]
Support per above, the Discord community should be separated from the Miraheze community. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
- Logic. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Support Sure. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Comments[edit | edit source]
Amendment #7[edit | edit source]
Instead of purely being flavor groups, the Site Reliability Engineering and Steward groups will retain the following permissions: Manage Roles, Manages Channels, View Audit Log, View Server Insights, Manage Server, Mention All Roles (Alters Proposal 1). It is emphasized that moderation permissions are not included and adding themselves to the moderator group without election would of course be strictly prohibited.
Support[edit | edit source]
Support I think it makes sense to allow these two groups to retain these permissions, as the main contention which lead to this RfC was moderation practices. Reception123 (talk) (C) 17:44, 24 February 2021 (UTC)Reply[reply]
- Reception123 I can support this, but for greater clarity, for "Manage Roles," would the "flavour groups" be sorted below the Moderators and Administrators groups, so they can't modify those roles? If so, then I can support. Dmehus (talk) 17:55, 24 February 2021 (UTC)Reply[reply]
- Yes, they would be below the roles. Reception123 (talk) (C) 18:03, 24 February 2021 (UTC)Reply[reply]
- Reception123 I can support this, but for greater clarity, for "Manage Roles," would the "flavour groups" be sorted below the Moderators and Administrators groups, so they can't modify those roles? If so, then I can support. Dmehus (talk) 17:55, 24 February 2021 (UTC)Reply[reply]
Support per Reception123's reasonable rationale and clarification above. Dmehus (talk) 18:11, 24 February 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
- We want to remove abilities from SREs and Stewards, but giving them part of permissions? If Moderator or Administrator is reqularly active, why not request them to changes? Permissions for announcements channel can be adjusted, so both groups can post and mention everyone, it is not problem. Why roles management? It can wait few hours until administrator/moderator will be avavaible, in emergenciens as mute role in case of spam is possible to enable !mute command for privilegied groups. Why management of channels? I do not understand... (Not to mention that some SREs and Stewards will be moderators/administrators)--MrJaroslavik (talk) 21:22, 24 February 2021 (UTC)Reply[reply]
- Well, role management would just to be able to add users to their own flavour group or other flavour groups, upon closing of, say, a request for interwiki administrator or Global Sysop. Manage channel permissions isn't really a moderation aspect; it's more administrative, and so it holds that stewards or SRE should be able to self-manage their own channels. Dmehus (talk) 21:36, 24 February 2021 (UTC)Reply[reply]
- How many rights changes, include GS, Steward, IA, Board, CoCC, sysadmin and everything per year? It can be done by administrators. Delay few hours really is not problem. Their own channels - It can be adjusted per-channel as i mentioned about annoucements channel. I thought we want to change the management (include moderation, but not limited to) of the whole discord, but probably everyone has different ideas/opinions to everything...--MrJaroslavik (talk) 21:53, 24 February 2021 (UTC)Reply[reply]
- Well, role management would just to be able to add users to their own flavour group or other flavour groups, upon closing of, say, a request for interwiki administrator or Global Sysop. Manage channel permissions isn't really a moderation aspect; it's more administrative, and so it holds that stewards or SRE should be able to self-manage their own channels. Dmehus (talk) 21:36, 24 February 2021 (UTC)Reply[reply]
- I'm not convinced there is a demonstrable need for these groups to retain these permissions. Group management on Discord shouldn't need to be immediate, and if the delay becomes problematic, we can consider adjusting this in the future. Channel management can be toggled to apply for a particular role in a particular channel (eg currently CVT have Manage Channel inside the #cvt channel, despite not having it assigned to the role). -- Void Whispers 04:15, 25 February 2021 (UTC)Reply[reply]
- Will these particular per-channel roles be able to be applied at administrator discretion? For example, SRE having certain roles in #miraheze-sre-relay and #announceemnts. Reception123 (talk) (C) 11:00, 25 February 2021 (UTC)Reply[reply]
- As necessary, yes. I'm actually thinking of changing up the announcements so that we would have a "miraheze-announcements" channel dedicated for Miraheze stuff that SRE/Stewards would have full access to, and also a "server-announcements" channel that is just for whatever server related announcements we will have (such as announcing a new moderator/admin election). -- Void Whispers 22:02, 25 February 2021 (UTC)Reply[reply]
- Will these particular per-channel roles be able to be applied at administrator discretion? For example, SRE having certain roles in #miraheze-sre-relay and #announceemnts. Reception123 (talk) (C) 11:00, 25 February 2021 (UTC)Reply[reply]
- No, No, and No. If SRE or Stewards need something, they can always ask to a moderator and/or a administrator. HeartsDo (Talk / Global / Wiki Creator) 15:49, 2 March 2021 (UTC)Reply[reply]
Oppose I don't think there's any convincing reason for these groups to have these permissions. As others have stated, they can just ask moderators or administrators. K599 (talk) 01:39, 3 March 2021 (UTC)Reply[reply]
Comments[edit | edit source]
Question: How is this different from what is being proposed in Proposal 1? Redmin Contributions CentralAuth (talk) 18:15, 24 February 2021 (UTC)Reply[reply]
- R4356th Proposal 1 would see the flavour groups retain no additional permissions, so Stewards or Site Reliability Engineers would have to request a Discord Administrator add specific channel access permissions or settings changes (i.e., to be able to post to the
#announcements
channel. I personally don't have a problem with giving certain administrative permissions to certain groups, such as SRE and Stewards). Moderator permissions would still only be held by the Moderators group under Void's proposal and including all these amendments. Dmehus (talk) 19:17, 24 February 2021 (UTC)Reply[reply] - Under proposal one, all groups except for the new proposed Discord Moderator and Discord Administrator group will be stripped of all permissions not granted by the @everyone role. -- Void Whispers 19:17, 24 February 2021 (UTC)Reply[reply]
- R4356th Proposal 1 would see the flavour groups retain no additional permissions, so Stewards or Site Reliability Engineers would have to request a Discord Administrator add specific channel access permissions or settings changes (i.e., to be able to post to the
Proposal 2[edit | edit source]
Moderation[edit | edit source]
Proposal 1[edit | edit source]
A new group of users (or a role) will be created who will be responsible for moderating the server. All current moderators (Stewards, the Site Reliability Engineering team, CVT and Interwiki Administrators) will lose their moderation access immediately after that. The members of this group will moderate the public channels only and will only have access to private moderation logs among private channels.
Proposal 1.1[edit | edit source]
Moderators will be selected by an Interwiki Administrator-like community vote (except for the requirement of 1000 global edit count) which will be held in a dedicated Discord channel.
Support[edit | edit source]
Strongest support as proposer. Steward moderation has been questionable enough lately. They have shown that they are not interested in behaving well with or listening to the voices of the community members. Somebody behaves well on-wiki does not mean they have behave well everywhere. The community members need more freedom. Redmin Contributions CentralAuth (talk) 18:24, 24 February 2021 (UTC)Reply[reply]
Oppose[edit | edit source]
Strong oppose This doesn't really make any sense. The voting on Discord I support, but this? Wouldn't it actually mess up the roles bit by bit? You should consider this more carefully. DarkMatterMan4500 (talk) (contribs) 18:17, 24 February 2021 (UTC)Reply[reply]
- @DarkMatterMan4500: Could you please clarify what you mean by "Wouldn't it actually mess up the roles bit by bit?"? Thank you. Redmin Contributions CentralAuth (talk) 18:25, 24 February 2021 (UTC)Reply[reply]
- R4356th What I mean by that is this: The roles would be all over the place, plus making it even more messy that would make it completely ineffective for Stewards and Global sysops to clean up. DarkMatterMan4500 (talk) (contribs) 21:36, 24 February 2021 (UTC)Reply[reply]
- @DarkMatterMan4500: Could you please clarify what you mean by "Wouldn't it actually mess up the roles bit by bit?"? Thank you. Redmin Contributions CentralAuth (talk) 18:25, 24 February 2021 (UTC)Reply[reply]
Comment[edit | edit source]
- I have updated the proposal to include Interwiki Administrators in the list of groups which will lose their permissions as they have the same moderation access as CVT. Redmin Contributions CentralAuth (talk) 18:50, 24 February 2021 (UTC)Reply[reply]
- I'm not opposed to this Proposal 2 in theory, but doesn't essentially propose the same thing as the above proposal? I thought the only difference is that this would limit server moderation to existing wiki group roles. Not opposed to that, per my discussions with you on Discord and because, this would've limited moderator roles to existing wiki groups. On rereading this proposal, I'm not sure how this is different from Void's proposal? Dmehus (talk) 18:57, 24 February 2021 (UTC)Reply[reply]
- Void wants to allow existing moderators to continue to have access after going through a confirmation process. This is not something I agree with. Redmin Contributions CentralAuth (talk) 19:03, 24 February 2021 (UTC)Reply[reply]
- Well, okay fair enough, but per the support votes above, all except for Void's support vote are conditional on all amendments passing. Any existing moderator who does not pass a confirmation vote within one week of this RfC closing would lose their platform moderation role, and only retain their flavour group. Dmehus (talk) 19:14, 24 February 2021 (UTC)Reply[reply]
- Void wants to allow existing moderators to continue to have access after going through a confirmation process. This is not something I agree with. Redmin Contributions CentralAuth (talk) 19:03, 24 February 2021 (UTC)Reply[reply]
- I'm not opposed to this Proposal 2 in theory, but doesn't essentially propose the same thing as the above proposal? I thought the only difference is that this would limit server moderation to existing wiki group roles. Not opposed to that, per my discussions with you on Discord and because, this would've limited moderator roles to existing wiki groups. On rereading this proposal, I'm not sure how this is different from Void's proposal? Dmehus (talk) 18:57, 24 February 2021 (UTC)Reply[reply]
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section