Requests for Comment/Meta usergroups reform

Autopatrolled, patroller and rollback In 2020, the autopatrolled and patroller groups were split through community vote in an RfC, resulting in two distinct limited-permissions roles alongside the already-existing rollbacker. With 3 years of history to review, it's clear that the three limited-rights roles (autopatrolled, patroller and rollbacker) on Meta today are not meeting the project's needs.

These groups are frequently requested by inexperienced users (sometimes as a matter of hat collection) without adequate understanding or intention to use the permissions effectively and positively contribute to the Meta community. While these permissions *can* be useful, they should be awarded based on discretion and intent, not as titles that users are pursuing because they think they "deserve" it.

Determining who should have these rights without any established criteria can also be a challenge -- If one user requests rollbacker, why not give it to everyone else? This RfC will propose changes to the current system to help codify criteria and consolidate duplicative roles into ones more helpful to the community.

Thank you to NotAracham for his assistance with drafting.

Note: This request applies to Meta only.

Proposed by:

Proposal 1 (Elimination of rollbacker)

 * The rollbacker group is eliminated and  permissions are given to the Patroller group

Note: If Proposal 4 is successful, this proposal is superseded

Rationale: Rollbacker only contains one right ('rollback'). Vandalism is rare on Meta and there's few ways users can really prove that they need this role. There are few dangers to give rollback to Patrollers, as worst case rollback can easily be rolled back with a Javascript script. There's no need to have this extra role on Meta and have users constantly request it after helping once or twice to revert vandalism. All rollbackers are currently patrollers so in terms of a transition wouldn't make any difference currently and also serves as proof that it's not needed as a separate role.

Comments (1)

 * 1) Conditionally  this as Proposal 4 is currently written. If the   and autopatrolled groups are retained as separate user groups, with different purposes and "barriers to entry," as it were, then I would conditionally  combining   into , but we would also need to inform some guidelines for revocation, the guidelines for which I drafted and continue to be used by Meta administrators. Dmehus (talk) 16:09, 21 May 2023 (UTC)
 * 2)   Can the rights be tiered?  Continue to have 3 groups, Autopatrolled, Patroller, Rollbacker, such that Autopatrolled group has only the Autopatrolled right, the Patroller group has the Patroller and Autopatrolled rights, and the Rollbacker has all 3 rights? ---Imamy (talk) 16:33, 21 May 2023 (UTC)
 * Imamy, we could certainly do that, and that is sort of the idea already with the  group. We could expand the   group to include certain other permissions, perhaps the   and   permissions, for example. If   includes additional user rights like that, given that the   contains only user right, there would arguably be little need or purpose to retain that user group separately. But certainly, tiered user groups, as you seem to be asking about and potentially propose, would help to eliminate the eliminate the collection of multiple hats, which seems to be the main impetus behind this RfC. Dmehus (talk) 16:38, 21 May 2023 (UTC)
 * 1) . Why would we remove it when there are qualified users that could use the rights to help the wiki. No reason to remove the group. Globe - (Talk • Contributions • CA) 12:52, 24 May 2023 (UTC)

Proposal 2.1 (Appointment Criteria for autopatrolled)
1. OR 2.
 * Meta administrators will generally grant the autopatrolled right if a user:
 * has been a user on Meta for at least 30 days and
 * has made at least 50 edits (excluding edits to their own userpage or other minor edits)
 * has been a user on Meta for at least 15 days and
 * has made at least 150 edits (excluding edits to their own userpage or other minor edits)

Comments (2.1)

 * Similar to my comments elsewhere, firstly, I would not be favour of combining the  and   user groups because they serve different purposes and have different competency standards and requirements. Secondly, this seems too prescriptive and limiting, which combined with my concerns with respect to the revocation criteria, may end up making it much "easier" to obtain a group, with expanded permissions, and more difficult to revoke. In short, the opposite of what one intended. While systemic edits can help to serve as a baseline, they should never be a replacement for granting of the group. Similarly, there are also cases where users demonstrate competency with fewer numbers of prescribed edits, and I believe Spike has spoken to that in that the past (perhaps others have as well). In short, activity != competency and, so, while I wouldn't necessarily be opposed to having systemic edits inform the baseline of a proposed guideline, as written, this does not allow that, and it's also written as to codify something into policy, when I think the existing community-endorsed guideline has worked, and will continue to work, best. Dmehus (talk) 16:04, 21 May 2023 (UTC)
 * The reason why it says "will generally grant" is to allow for a discretion to exist. The main idea is to prevent users from constantly asking for autopatrolled and to be able to refer them to the more strict criteria in most cases. Exceptions could potentially made where necessary. Reception123 (talk) ( C ) 18:39, 21 May 2023 (UTC)

Proposal 2.2 (Revocation Criteria & Discretion for autopatrolled)

 * A Meta administrator may use their discretion and refuse to grant autopatrolled even if the criteria is met and may also use their discretion in deciding whether to revoke autopatrolled. Examples of reasons for this would be: violating Meta or global policies, their edits having to be frequently undone by other users, demonstrating a lack of understanding about how Meta functions.

Comments (2.2)

 * This is already the status quo. This looks a bit like creating a policy for the sake of policy. This guideline has already received the community's endorsement through at least one CN discussion and perhaps an RfC comment as well. As well, I'm a bit concerned by trying to codifying it in such as a way as to be more prescriptive, to having violated Meta's policies or Miraheze's global policies may unduly hamstring or handcuff some Meta administrators' ability to use that generally good judgment and common sense and not revoke the permission when it might be warranted (i.e., a user who has backtracked and again displayed CIR tendencies). It's deliberately kept vague, principally because we've elected Meta administrators to use that judgment, and I would rather continue to have this be a guideline, which we can evolve, as needed, by involving the community in subsequent discussions on the user group's companion talk page, but necessarily via an RfC for the sake of having an RfC. Dmehus (talk) 15:56, 21 May 2023 (UTC)

Proposal 3 (Transition)

 * All autopatrolled users who do not meet the requirements set out in Proposal 2.1 will be revoked.

Comments (3)

 * As with below, this is already the status quo, and when I was a administrator, I have already supported removing  from long inactive Meta users. As with most things on Meta and Miraheze, there should be necessity to the user group. A user who has not edited on Meta in over a year, for example, has little need to retain the user group. In short, the existing guideline, and the community's endorsement of that guideline, not to mention the community's trusting their judgment, already provide the support necessary to remove this group on a discretionary basis. Dmehus (talk) 16:12, 21 May 2023 (UTC)

Proposal 4 (Elimination of patroller)

 * The patroller group is eliminated and  permissions are given to the autopatrolled group

Support (as well as the inclusion of 'rollbacker' in the autopatrolled group)
(Note: The effect of this is that there will be a single group remaining - "autopatrolled")

Support (but not the inclusion of 'rollbacker' in the autopatrolled group)
(Note: The effect of this is that there will be two groups remaining - 'rollbacker' and 'autopatrolled')

Oppose
(Note: The effect of this will be that either all three groups remain or rollbacker is eliminated if you also supported Proposal 1)

Rationale: Some have argued for this and believe that the function of patrolling isn't really that "high risk" or important to deserve its own group.

Comments

 * 1)  It is interesting to me that the proposer themselves in 2020 suggested that "it doesn't really make sense for the "Autopatrollers" group to also be able to patrol others edits as that defeats the purpose of its name.". While I cannot say that I would be decidedly against this proposal and while I do not particularly appreciate lengthy debates regarding names rather than substance I must agree with the proposer's original assertion and say that it may be preferable to search for another name for this new user group that would combine two or three current existing groups. I would suggest that in case all three permissions are combined into one group the new group is simply named patroller as patroller can encompass autopatroller but autopatroller hardly can encompass patroller. --DeeM28 (talk) 14:30, 21 May 2023 (UTC)
 * 2)  I would not be in favour of this proposed combination, for several reasons. For one thing, the   is meant to be a low-barrier user group given to users who have demonstrated little need to have their edits patrolled and, so, to reduce the backlog of patrollers and administrators. Patrolling, on the other hand, requires knowledge and awareness of Meta's policies and conventions, which take some time to learn, as well good judgment and common sense. In short, one user right reduces the patrol backlog, while the other assists Meta administrators in patrolling the unpatrolled edits queue (and there are still a lot of those). Unless we're proposing to significantly lower the barrier for   to something like , where it's granted in an automatic and systemic way based on a certain number of edits, which I wouldn't be in favour of, or significantly increase the number of Meta administrators, which I also do not believe is necessarily the best idea, this will actually have the opposite effect of increasing the unpatrolled edits queue, to an even smaller number of volunteers, most of whom already wear multiple hats. As well, I would also just note the utility of the separate   group in several ways. Firstly, it's user group that can be revoked, as RhinosF1 did with me, but also one that can be re-added, or added, and help to promote additional volunteerism, such as my election as Meta administrator two months later and, as steward, roughly five months later. A similar story unfolded when I granted Agent Isai that user group a year later. He had been mainly lurking in our IRC channels only, not being involved on-wiki until that act. His edits on-wiki were few at the time, so it may not necessarily have been appropriate to give him   right away, though in his case, I'm fairly certain I recruited him for that role within a few weeks. We could potentially combine the   group into the   group; that is something I would be more warm to now, given my comments here. Dmehus (talk) 15:47, 21 May 2023 (UTC)

Translation The translation process on Meta, as implemented today, is truthfully less than ideal -- Important pages lack full translations in many languages, while trivial pages with low priority for translation have received translation attention in multiple languages. In addition, it must unfortunately be said that there are often translations being made with classic machine translators or due to lack of knowledge of the target language where a modern machine translation servuce such as DeepL or even ChatGPT could have provided a translation of better quality.

We must then ask ourselves whether we want to continue with the current translation process -- missing important page translations, partially-translated pages, and below-standard translations -- when users could simply use performant machine translation services instead and have better quality. Therefore, there are two main solutions to this issue: (if technically possible) integrate machine translation (preferably DeepL) on Meta and have translators simply review and correct output where needed, or keep the current model but only allow certain users to translate.

Because integration of translation services still has unsolved problems, I propose in the meantime we at least strive for better quality translations on Meta.

Proposal 5 (Translator group)

 * Only users in the 'translator' group are able to translate pages.

Rationale: As part of the following sub-proposals to establish rules for getting/keeping/removing translator rights, this consolidation of translation permissions allows those new criteria to be enforced.

Proposal 5.1 (Criteria for translator group)
In order to be appointed translator, a user must:
 * Translators are appointed at the discretion of Meta administrators. Translators will initially be appointed for a trial period of 15 days. If a Meta administrator is satisfied that they have performed well they will be appointed indefinitely.
 * confirm that they have read MediaWiki's documentation for using the Translate extension and understand how to prepare a page for translation
 * have at least level 3 (Babel) competencies in both the target language and in English
 * provide a few examples of pages that they intend to work on if approved

Rationale: These new criteria require that the user... The 15 day trial period allows the meta administrator to confirm all criteria are met and that a request isn't simply hat collection by the user.
 * 1) has the practical knowledge to use the translation tools
 * 2) has the language proficiency to create good-quality translations
 * 3) has a specific project that they plan to pursue

Proposal 5.2 (Removal)

 * If it is found that a translator has repeatedly translated pages poorly or otherwise misused their rights, their translator permissions may be revoked.

Rationale: This clause confirms right to removal of permissions as needed by Meta Administrators. As misuse and poor translation can take many forms, a full list is not enumerated.

Proposal 6 (Translation administrators)

 * The translation administrator group is eliminated and the 'translationadmin' right is given to translators.

Rationale: Similarly to rollback, this group has limited scope and it's unnecessary to assign 'translationadmin' permissions separately if stricter translator criteria are approved in proposal 5.1. If translators misuse 'translationadmin' permissions, their translation rights will be revoked for misuse of permissions as per proposal 5.2.

Comments (6)

 * If DeeM28's proposal does not pass, while I would not be opposed to giving translation administration permissions to translators, I would like to see the translation administrator group revamped to include the  user right, to assisting administrators in removing unmaintained pages. It would still be a discretionary user group, but would have a higher level of competency and would shift from marking updated translation pages to removing unmaintained translation subpages. Dmehus (talk) 16:28, 21 May 2023 (UTC)

Proposal 7 (Pages excluded from translation)
Examples are: pages in the Tech namespace, pages that contain lists of users, guides for certain advanced user groups
 * Pages which only present an interest to a limited/select group of users or which are very short should not be translated.

Comments (7)

 * This seems like the inverse of Proposal 8.1, which I would tend to prefer. Rather than have a list of excluded pages, we should maintain a list of included pages for translation. Requests to have pages added to that included list should be made at the applicable venue, Administrators' noticeboard or Stewards' noticeboard, as applicable, and must include a compelling rationale. So rather, perhaps we could revamp Proposal 7 with the aims of Proposal 8.1, rather than have risk having proposal and counter-proposal bloat? Note, most pages in the  namespace are already not translated, though there may be occasional non-technical guideline that could be useful and, in this way, such a page could be added to the list of included pages, if there's a compelling rationale. Dmehus (talk) 18:23, 21 May 2023 (UTC)

Proposal 8 (High traffic pages only) (added by DeeM28)
As a softer alternative to Proposal 8 I would propose the following:
 * In order to ensure professional translation on Meta, only high traffic pages may be translated. High traffic pages include: the Main Page, global policy pages and other high traffic pages. Translations in a specific language may only be undertaken if there are at least two users part of the translator group who are able to translate into that language.

Note: This request supersedes Proposal 7. This proposal is subject to the translator group proposals (Proposal 5, Proposal 5.1) passing.

Comments (8)

 * I personally would just like to see translation suspended and eliminated, per your well-articulated rationale in Proposal 8 and my comments on the outmoded Translate extension and its sub-optimal design as well as the evolution of AI and universal translation tools rendering the necessity for human translations by a very small, and infrequently active, core group of translating volunteers obsolete. For relatively stable and high-traffic global policy and the main page, I can see a weaker case to retaining them. I wouldn't be so keen on restricting approval to certain languages, though, if someone maintains them. Administrators can already delete unmaintained translation subpages, and this was something I tried to do regularly as a Meta administrator. It's just not being done regularly. Dmehus (talk) 16:25, 21 May 2023 (UTC)
 * My main issue with this is that I'm not sure what's seen as "all relevant pages". Personally I think under this proposal it would be okay to only have the Main Page translated for example. Though if there's a narrow definition of all relevant pages that could be interesting. Reception123 (talk) ( C ) 17:31, 21 May 2023 (UTC)
 * Thank you for your comments, Reception123. I wouldn't be opposed to keeping the Translate extension, and to repurposing the moribund  user group that includes the ability to mark pages for translation, but I'd still like to perhaps repurpose the   group to include additional janitorial/mopping permissions, so long as we have additional criteria for granting and clear but also flexible criteria for revoking (i.e., edit-warring, recidivism following administrator warnings or guidance, etc.), to include the ability to remove unmaintained or no longer maintained translations. If we do limit to specific pages, I would think Miraheze, Help center, and most of the key global policies would be good to have translated. I don't think we necessarily need to have translations of all the Meta user group pages, particularly as ChatGPT and future AI models (i.e., Google's Gemini) continue to evolve. Basically, any page that is not frequently edited. We may also want to consider having a new page protection level, associated to that revamped patroller group. Perhaps revamp Patrollers as  Janitors? Dmehus (talk) 17:45, 21 May 2023 (UTC)
 * Thank you for your comments. I have taken them into account and have a new proposal that allows translation for important pages but still contains the approval requirement. The reason is that without the approval requirement translations can not be fully professional because a real risk persists of users overestimating their translation capabilities and producing poorly translated pages without check as administrators evidently are not able to properly review translations into languages which are foreign to them. Requiring two translators for one language will mean that one will be able to review the other. In regard to your new Meta Janitors group proposal I believe that is an idea that ought to be considered but it might be best not to have too many things decided in a single RfC and to first decisively decide the issue of translation in a direction or another. I invite you to make changes to my proposal if you believe they are useful and also to propose a different one altogether if you are unsatisfied with my idea. --DeeM28 (talk) 14:42, 22 May 2023 (UTC)
 * I do not wish to presume that the lack of response signifies agreement but I have deleted my former proposal text and only kept the current one. I hope it is acceptable and only would require minor changes. I strongly encourage other users to also comment on this as I believe it would be a significant change that requires wide support. --DeeM28 (talk) 13:36, 25 May 2023 (UTC)
 * I hope you don't mind but I've made some changes in order for the proposal to be more interlinked with the original translator group idea and for an additional language approval to no longer be required as long as there's two confirmed translators. In addition, I've also separated out the removal part into a separate proposal to not make this one dependent on that as well. I hope that's acceptable. Reception123 (talk) ( C ) 15:13, 27 May 2023 (UTC)

Proposal 8.1 (Removal of current translations)

 * Any current translations that are incomplete or otherwise poorly done will be removed. This includes incomplete or poorly done translations of pages mentioned [in Proposal 8].

Proposal 9 (Elimination of translation) (added by DeeM28)
This proposal is bold and may even be considered by some as "radical" which is why I should explain in a more detailed fashion. I believe people generally on Meta are afraid of saying quiet things out loud, of attempting to change significantly a certain function that has been done for a long time or to take an important and decisive decision. The proposer above identifies the issues related to translation and proposes some methods in order to fix these issues. I can agree that the issues may be improved by those measures but I do not think that it will be significant. I would like to say that this proposal in no way has anything against multilingualism or the fact that Miraheze is clearly a global platform. I think it is necessary to eliminate translation is because it is very likely that it has a very minimal usefulness due to its incomplete and imperfect nature. With the rise of powerful translation websites and extensions/add-ons for browsers it cannot be said that users who do not speak English are not able to very easily have pages translated. If we were able to have all pages translated in a professional, coherent and full manner I would be glad to be able to continue but the issue on Meta is that pages are often only partially translated or not translated at all or translated poorly or some pages have translations and some do not. I do not believe it is possible at this time for Miraheze to properly fix this issue. Translation of all pages is a feature that is likely inspired from Wikimedia's Meta wiki but is unsuitable for Miraheze Meta in my view. I understand that this proposal is a long shot and is likely to be opposed by the translator aficionados here on Meta but I do not see a reason for why it should not be presented as an option in case someone finds favor with this idea. I of course propose to leave pages that are already translated up so that translators time has not been wasted out of respect for their work. I also take this opportunity - in case anyone has time to fully read my text - to enquire to system administrators whether they are able to provide statistics regarding how many people actually use the translated pages daily. --DeeM28 (talk) 14:46, 21 May 2023 (UTC)


 * Translation on Meta is generally suspended for an indefinite period of time.
 * Pages that are fully (100%) translated in a language and are done so in a professional/rigorous manner will remain and may be updated as needed. All other translations will be removed.

Comments (9)

 * I would like to give my vote before RfC starts. I am absolutely against this proposal; I am a person living in Turkey, I know English at en-3 level. For both other users and myself, it would be logical to continue reading and translating each page in the native language of the person. For your information Hey Türkiye  Message? 18:00, 21 May 2023 (UTC)
 * In addition; I can't let my translations go to waste. There is a labour; there is a work done. You have spent hours and minutes for this translation. Reading English does not always benefit people; there are people who do not speak English. That's why we do what we do; translation in accordance with that language. I do the same. I translate the text into my own language to understand it better, then I edit it if it contains a loss of meaning - otherwise the text cannot be read. One thing is that there are many users here (including me) whose first language is not English. So I wanted to use my strongest opposition to defend our rights, and I wanted to make it clear in this comment why I voted the way I did. As soon as the RfC starts, my vote stands - I will not edit the proposal even if there is no edit in it. I respectfully announce. Hey Türkiye  Message? 18:13, 21 May 2023 (UTC)
 * A bit bold indeed, but I was actually thinking the same thing here. For one thing, the Translate extension is showing its age. Moreover, rapidly evolving AI models and deep integration within search look set to render English Wikipedia and even the multilingual Wikipedias redundant. In short, Wikimedia Foundation looks set to be facing an existential crisis in the next several years, as it would not surprise me to see English Wikipedia's traffic plummet, as Google gradually begins replacing English Wikipedia infoboxes in search results pages with continuously improving AI-generally supported search results. Nearly all users on Meta Wiki have some degree of English language knowledge, and AI, as the proposer notes, continues to evolve and get better and better, rendering the need for translations obsolete. It also artificially increases edit counts and page counts, on pages which are edited too frequently to be translated by a very few number of volunteers. Dmehus (talk) 16:19, 21 May 2023 (UTC)