Requests for Comment/Changes to wiki creators

This requests for comment is based on the current issue surrounding wiki creators, how they may be used, and how to hold wiki requests.

Proposal 1 : Community may vote to revoke wiki creator
This is because the community may add wiki creator but not remove it. In addition, stewards may create wikis, and can be revoked by community, but not wiki creator. This effectively gives wiki creators a "safety net" stewards don't have. This was previously discussed in the Examknow RfC and decided against it, however, consensus can change, and it did with the global rollback group which failed to gain consensus in 2020 but passed in 2022 Naleksuh (talk) 06:15, 13 April 2023 (UTC)

Support, instead of current removal system (stewards may still remove in emergencies or inactivity)

 * 1) I honestly thought that it worked like this either way. This sounds like a good plan, in addition to the emergency/inactivity proposal. --Charlie Fiddlesticks (talk) 17:13, 19 April 2023 (UTC)
 * 2)  per proposal. Redmin Contributions CentralAuth (talk) 05:10, 22 April 2023 (UTC)

Support, in addition to current system (stewards may remove in emergencies, inactivity, and self-perceived VCP violation)

 * 1) I believe that wiki creators are both accountable to the community and to the Volunteer Conduct Policy. We have revocation policies for a lot of other roles, and it's time that the wiki creator policy comes up-to-speed on that as well. BrandonWM (talk • contributions • global • rights) 12:12, 13 April 2023 (UTC)
 * 2) there is clarification on what removal standards would be used in a community vote, otherwise . Happy to revisit this when clarification is provided. --NotAracham (talk • contribs • global) 18:56, 16 April 2023 (UTC)
 * 3) I think that if some Wiki Creator is constantly breaking the rules, and not being helpful, they should have a request for removal of rights. But, on that point, there is really no need for this, because Tali takes care of 95% of the Wiki Requests; like said on my request to become a Wiki Creator. I would support if there is any need to remove the rights of WCs. Commetia/Kazakhar (talk/Contact) 23:27, 18 April 2023 (UTC)
 * 4) there is clarification on what removal standards would be used in a community vote, otherwise . Happy to revisit this when clarification is provided. (copied from NotAracham) Globe (talk) 18:15, 19 April 2023 (UTC)
 * 5)  if the other proposal does not pass. Redmin Contributions CentralAuth (talk) 05:13, 22 April 2023 (UTC)
 * 6)  I support because I agree with NotAracham.  Hey Türkiye  Message? 19:47, 5 May 2023 (UTC)
 * 7) there is clarification on what removal standards would be used in a community vote, otherwise . Happy to revisit this when clarification is provided. (copied from NotAracham), even though I fully agreed with BrandonWM. Soukupmi  (talk) (✔) 05:55, 8 May 2023 (UTC)

Oppose

 * 1)  The question that is posted in this RfC is an interesting question and it is my opinion that it is a good thing that the community will be able to have its opinion heard. I believe that it is important to differentiate Stewards and wiki creators. Stewards have broad discretion and a wide range of responsibilities and it is clear that there is no other group that could possibly decide their removal without a vote. Wiki creators have one specific task - to create wikis. In some countries recall petitions do exist for elected officials where voters can vote to recall an elected politician. It must be said that only high ranking politicians are usually concerned by such votes as the electorate usually does not interfere with more minor roles. Because wiki creators have such a clear purpose and one single job it is difficult to see what causes for removal could exist beyond the ones set out in the policy which was also recently amended. It is my opinion that it is preferable to have a Steward make the determination based on this objective criteria in order to avoid cases where a majority wishes to remove a wiki creator either because it does not agree with that particular creator's ideology or because they dislike them and as a consequence want to strip them of their roles. Having Stewards handles this provides an element of neutrality and focus on policy instead of a simple majority. It is clear that if there is an overwhelming majority backed by arguments explaining why the requirements have been breached it will be near to impossible for a Steward to ignore. It must also be said that there are no minimum voting requirements for wiki creators so allowing for direct removals would also risk a back-and-forth situation where wiki creators are revoked and re-added based on the current communities disposition rather than objective factors related to their performance. --DeeM28 (talk) 12:53, 13 April 2023 (UTC)
 * 2)  In the RfC 5 years ago I voted against direct community revocation. Since then I can't say I've seen any major flaws with the current revocation system that would make me think that it needs fixing. Unlike other groups, wiki creators have a single task to do and the main reason for removing them is if they're doing that wrong or if they're violating another global policy which in turns damages Miraheze's reputation (which are the current reasons for why wiki creators can be removed by a Steward). I don't really see any major benefit in changing the system to allow for direct community revocations but I can see some downsides. Reception123 (talk) ( C ) 17:29, 19 April 2023 (UTC)

Comments

 * If this is successful: (1) Would Stewards still have the ability to remove wiki creators if they violate the 4 points mentioned in the current policy? (2) Would a community revocation have to take into account the 4 points and be subject to that or would it just be a simple vote? (To note that in the case of Global bans as well, a community vote is also pre-conditioned by some additional requirements). Reception123 (talk) ( C ) 06:38, 13 April 2023 (UTC)
 * 1) That depends on the result of the RfC. That's what it's here to decide. Stewards would still be able to remove in emergency or inactivity, however it's up to the community to decide if community revocation replaces or supplements steward revocation. 2) What is the difference? Naleksuh (talk) 06:41, 13 April 2023 (UTC)
 * I think for 1 it might be best to clarify that in a proposal as otherwise it wouldn't be clear whether people supporting direct revocation implies that Steward revocation without a vote is no longer possible. Regarding 2, the difference is that with the 4 points, a revocation could potentially be declined by a Steward if none of the 4 points are met, even if there's a vote. --Reception123 (talk) ( C ) 06:58, 13 April 2023 (UTC)
 * I'm potentially amenable to this, but what standard is needed for a successful revocation vote if implemented? Simple majority, 60%, 75%, at least 10 votes in total? --NotAracham (talk • contribs • global) 18:53, 16 April 2023 (UTC)
 * If there's a standard for revocation there would also have to be one for appointment of course. I'd also insist on having it at 80% 50% to be consistent with other groups as we recently had an RfC that ended the awkward situation where different groups had different removal ratio requirements. Reception123 (talk) ( C ) 17:32, 19 April 2023 (UTC)
 * But it's currently 50% and not 80% to remove. So 80% would make it inconsistent. Unless you mean 80% to add, 50% to remove? Naleksuh (talk) 18:05, 19 April 2023 (UTC)
 * My mistake, what I meant is to have it at 50% to remove like the other groups, and not 60%/70% as to not create inconsistencies between the groups that are difficult to justify. Reception123 (talk) ( C ) 07:57, 8 May 2023 (UTC)

Proposal 1 Amendment A: Adding removal standards
If approved, the following removal standard is added to proposal 1: A community vote for removal is successful if: *At least 10 users support removal *There is a support ratio of 50% or greater *At least seven days have passed since the petition for removal was initiated

Rationale: This is aligned with standards for removal of Global Sysop and other roles and strikes an appropriate balance in my view given the front-line nature of the role NotAracham (talk • contribs • global) 15:28, 28 April 2023 (UTC)

Support

 * 1)  as proposer --NotAracham (talk • contribs • global) 15:36, 28 April 2023 (UTC)
 * 2)  BrandonWM (talk • contributions • global • rights) 15:55, 28 April 2023 (UTC)
 * 3)  The offer is feasible, reasonable. I can't see any bugs either.  Hey Türkiye  Message? 19:47, 5 May 2023 (UTC)

Oppose

 * 1)  Regardless of my views as expressed above I must oppose this amendment. I find it very peculiar and not right that the appointment process not only does not have a required minimum of users but also has a 3 day minimum instead of 7 day for revocation thus revocation is much more stringent than appointment. Is a very large difference between appointment and revocation really required where such a difference is not to be found in any other global or local groups where appointment and revocation match in terms of participation and minimum days open requirements? I also do not think a 10 user requirement is necessary as this appears to make the suggestion that revoking a wiki creator is not dissimilar in importance to revoking a Global Sysop where 10 users are also required.
 * I must once again also re-iterate my opposition to the entire concept of the community revoking wiki creators directly as I explained above. I do not believe it is necessary for the community to have to directly participate in quasi-micro management of wiki creator activity which is very specific to its task and which can easily be overseen by Stewards. --DeeM28 (talk) 18:27, 28 April 2023 (UTC)
 * 1) . I feel that the 50% is far to low. I would support a 60% or 75% though. Globe - (Talk • Contributions • CA) 12:19, 8 May 2023 (UTC)

Proposal 2: Revoking (and adding) is done at Requests for global permissions
This is because, while on a software level, the group only exists on Meta, for all intents and purposes it's treated as a global group (managed by stewards and not Meta bureaucrats, bound by VCP, and other stuff that applies). Naleksuh (talk) 06:16, 13 April 2023 (UTC)

Oppose

 * 1) Only because historically we've had RfPs for this permission out of RfP, and all archives are stored there, as well as boilerplates and the like. We could change it, but it's a hassle to change it. BrandonWM (talk • contributions • global • rights) 12:16, 13 April 2023 (UTC)
 * 2)  Even if wiki creators do have global reach because they create other wikis all of their activity takes place on Meta and there are not strong enough reasons in my opinion to make this change. --DeeM28 (talk) 12:58, 13 April 2023 (UTC)
 * My reasoning for this is that it makes using the pages more simple: RfGR is managed by stewards, M:RfP is managed by Meta bureaucrats. I also think Requests for Stewardship should be merged into RfGR but that's a discussion for another day. In the past even as a user who has been here for a long time I have found using these pages confusing, and since wiki creator is supposed to be an entry level group it should make sense, and be consistent Naleksuh (talk) 15:15, 13 April 2023 (UTC)
 * It might be that due to the high demand for wiki creators it might even make sense to have a separate Requests for wiki creators. However since you believe RfS should be merged into RfGR I do not think you would agree with this proposition. --DeeM28 (talk) 12:19, 14 April 2023 (UTC)
 * 1) I see the logic (and the logic is sound), but procedurally doing revocation requests at the same place a request was originally filed makes more sense to me... --NotAracham (talk • contribs • global) 18:55, 16 April 2023 (UTC)
 * User:NotAracham, If this proposal passes, adding would be moved, so it would be at the same place as adding. Naleksuh (talk) 19:07, 16 April 2023 (UTC)
 * Thanks for the clarification. One alternative might be a standalone request page for Request for Revocation that could cover all roles?  I'm iffy on that one, it seems excessive given how infrequently revocation requests come up most of the time... --NotAracham (talk • contribs • global) 19:32, 16 April 2023 (UTC)
 * Not sure about that because I think there are already too many pages and venues and it's confusing. Also I don't like the idea of mixing global and local stuff. Naleksuh (talk) 19:41, 16 April 2023 (UTC)
 * 1) . I see nothing wrong with the current system and location and I don't see enough of a reason to make a change. Globe (talk) 18:17, 19 April 2023 (UTC)
 * 2)  I don't really see the issue here. --DarkMatterMan4500 (talk) (contribs) 12:22, 24 April 2023 (UTC)
 * 3)  Implementing this proposal would be absurd and I don't see anything important. I also join the community.  Hey Türkiye  Message? 19:47, 5 May 2023 (UTC)
 * 4)  pet NotAracham]]. --1108-Kiju /Talk  03:18, 6 May 2023 (UTC)

Proposal 3: Who may ask wiki creators to hold wiki request?
Today, user NotAracham stated that wiki requests were on hold, but when I PRed Miraheze to implement this, SRE member MacFan4000 said they were not on hold. This raises the question, who can decide that they are on hold, or not? I believe SRE should, as they're the ones response for the software, and the ones with the ability to turn it off. Therefore, SRE may request holding them, and do this via the disabling of the ability Naleksuh (talk) 06:16, 13 April 2023 (UTC)

Support

 * 1)  as this should help avoid confusion. Wiki Creators can request SRE if there is a clear need to hold requests. Redmin Contributions CentralAuth (talk) 17:15, 22 April 2023 (UTC)

Oppose

 * 1)  This proposal conflates the 'who' with the 'how' of calling holds, I'm not opposed to clarification and as discussed in the comments it was in fact a steward/SRE member who called for the hold, but it would be better to handle procedurally via team discussion vs prescribing by RfC in my view.  (I  the proposed how, for the record.) --NotAracham (talk • contribs • global) 19:05, 16 April 2023 (UTC)
 * 2)  per NotAracham  Hey Türkiye  Message? 19:47, 5 May 2023 (UTC)

Abstain

 * 1) Don't mind this either way but a question for . Shouldn't Stewards also be able to do this? And would it require disabling CreateWiki every time, or do we simply just inform all wiki creators to not approve any? BrandonWM (talk • contributions • global • rights) 12:14, 13 April 2023 (UTC)
 * I don't see a reason for stewards to be able to do this. They are not responsible for maintaining software, so there's no case in which Stewards would need to do this. SRE may have to due to technical issues creating wikis might cause, but that's not Stewards problem. I wouldn't necessarily be opposed to stewards being able, I just don't see a reason that they would need to. As for how it's being disabled, I believe it should be done via disabling the createwiki permission. This is better than telling wiki creators not to, because even if you tell them onwiki, they have to constantly check a noticeboard and deal with confusion on users contradicting each other. And worse, most of the time when it is told it's only told on Discord or IRC. WIki creators are not required to use that so they could miss it. That's why I think it's both the simplest rule and the fairest that if wiki creations are enabled they are fair game, and SRE can disable them for technical issues. Naleksuh (talk) 15:10, 13 April 2023 (UTC)
 * 1)  I do not think that it is necessary to have a vote or a hard rule on an issue which I believe should be quite obvious simply because of one instance that happened. It is my assumption that when NotAracham made that statement it would have been because it was his/her opinion that it was necessary. If wiki creation should be paused it should be disabled however it is gratuitous to have to have a hard rule about something like this. --DeeM28 (talk) 12:58, 13 April 2023 (UTC)
 * User:DeeM28 This has happened multiple times. Also, my reasonining for this being a problem is that people claim that I created wikis after I was told not to, when I wasn't. That message wasn't delivered due to a technical issue with Discord/IRC bridge. Plus, it's not a requirement for wiki creators to use Discord or IRC anyway so they might miss it. Naleksuh (talk) 15:10, 13 April 2023 (UTC)
 * In this case I do not have anything against this proposal but I still believe that it should be clear already that regular wiki creators should not be directing others to not create wikis without the approval of the SRE. --DeeM28 (talk) 12:21, 14 April 2023 (UTC)

Comments
The characterization here suggests that I paused wiki requests, which is not the case. A pause was initiated by a member of the SRE team, which I reiterated the following day for the courtesy of our IRC colleagues who are not always connected to the role-specific Wiki Creator discord channel. We were then notified by other members of SRE that there was a script solution for this problem and creations could resume. A discussion (which Naleksuh had access to and participated in) followed to determine best way to solve for notification when folks aren't online or on the same platform, which came to a few possible solutions like this one, though it seems that we didn't have the same understanding on what that conversation was about. I agree that a more robust solution is needed, but dictating it through RfC strikes me as odd. --NotAracham (talk • contribs • global) 14:56, 13 April 2023 (UTC)
 * Well, from what I saw at the time, you were the one who paused it. Because you just said they were on hold, not that someone else had put them on hold. You weren't the one who paused it, but I didn't know that at the time. I believe that a solution to this is necessary because users are accusing me of creating wikis after being told not to, when I wasn't actually told not to. Therefore, a clear system for how to put wiki creations on hold will solve this problem Naleksuh (talk) 15:18, 13 April 2023 (UTC)
 * For reasons of simplicity I believe it would be better for the SRE team to disable creations altogether when there is a need to do so rather than only notify creators via Discord or IRC - which may or may not be consulted by all of wiki creators - and hope that everyone will see. --DeeM28 (talk) 12:23, 14 April 2023 (UTC)