Requests for Comment/Move GlobalUserPages To Meta
This Request for Comments is now closed. Please do not edit this page. New edits may be reverted. |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- Unsuccessful. Agent Isai Talk to me! 07:17, 16 December 2022 (UTC)
On Miraheze, loginwiki
serves two primary purposes:
- authenticating logins for users around Miraheze, and keeping record of all users registered on that wiki when CheckUser or other tools are necessary.
- Providing a hub wiki for the extension GlobalUserPage, which allows for a consistent cross-wiki userpage.
Given the heightened security around the first use case, Stewards are the only users empowered to moderate loginwiki at this time, as no other user group has been (or is likely to be) granted the necessary permissions to perform maintenance and counter-vandalism activities.
Reliance on our handful of active Stewards alongside a rapidly-growing userbase has resulted in delayed counter-vandalism/CoC/CP enforcement alongside longer lead times for basic administrative requests like deleting a userpage. An example instance of this issue would be this diff. In order to take burden off of the Steward team and empower those already charged with enforcing counter-vandalism, content policy and Meta administration, I outlined a few solutions below. Thanks - BrandonWM (talk • contributions • global • rights) 05:27, 30 November 2022 (UTC)
NOTE: As an external reference, Wikimedia also uses the GlobalUserPage extension -- their hub wiki for the extension is hosted on Wikimedia Meta (their equivalent of Meta) which is distinct from their login services.
NOTE: New information has become available that was not available prior to the opening of this RfC. Moving GUPs to Meta is not currently possible because of an overload of jobs, per SRE. Proposal 1 is now defunct. Proposal 2 simply remains as an advisory for future proposals, should there be any.
Please note that proposals 1 and 2 are mutually exclusive.
Proposal 1: Move The GlobalUserPage Extension To Meta[edit | edit source]
The hub wiki for GlobalUserPages will be transferred from loginwiki to Meta. Miraheze's loginwiki continues to exist and will be made read-only. Meta Administrators and CVT members can now assist stewards in the maintenance of userpages.
Support[edit | edit source]
Strongest support As proposer. Thanks - BrandonWM (talk • contributions • global • rights) 05:31, 30 November 2022 (UTC)
Support Given our small number of Stewards, separating the function of GlobalUserPages from LoginWiki removes the security challenges preventing our other volunteers already entrusted with enforcement/assistance on Meta from taking action and frees up Steward time for more critical matters. This seems like a straightforward win, though I'd love a technical perspective on how reasonable this is to do. --NotAracham (talk • contribs • global) 05:37, 30 November 2022 (UTC)
Abstain[edit | edit source]
Neutral Technical perspective has made it clear that this proposal isn't reasonable (or likely needed) at this time. As I helped provide verbiage suggestions on this request, I'll strike my support and switch to abstain instead. --NotAracham (talk • contribs • global) 14:46, 30 November 2022 (UTC)
Neutral Same as NotAracham, this proposal no longer really has any meaning as new information has popped up. Thanks - BrandonWM (talk • contributions • global • rights) 15:04, 30 November 2022 (UTC)
Oppose[edit | edit source]
Strongest oppose for technical reasons this should not happen. The way jobs work it is not feasible to do this, when I was a sysadmin, most of my time was spent unbacklogging jobs, while it has improved since I left the team, it is still a valid issue. Zppix (Meta | talk to me) 06:08, 30 November 2022 (UTC)
Strongest oppose Per some of what Zppix said above, there is technical reasons for keeping them on loginwiki. I strongly advise against this. Doing this would send a very high number of jobs on Meta, that could backlog things like wiki creations for an unreasonable amount of time. It could even potentially fall under a violation of the Terms of Use section 8 "Sending enough requests to Miraheze servers to degrade the service of others". I feel an unreasonably high amount of job backlogs here on Meta, could easily degrade the service and the global stability of Miraheze, while that would take investigation to actually determine, it is still something that is possible. Universal Omega (talk) 06:54, 30 November 2022 (UTC)
Strongest oppose not because I think it's a bad idea, however. As already mentioned, Wikimedia Foundation already does this. However, I agree with the above. --Blad (talk • contribs • global) 11:38, 30 November 2022 (UTC)
Strongest oppose No. That would screw up EVERYTHING in the long-run. I agree with the following opposes above (and future opposes below my oppose). --DarkMatterMan4500 (talk) (contribs) 15:02, 30 November 2022 (UTC)
Opposeing per the comments above and my concerns that it may clog up Meta. The user who loves human heads on alien/animal bodies in cartoons for no reason (talk to me uwu!) 15:42, 30 November 2022 (UTC)
Comments[edit | edit source]
- The extension was moved away from Meta as it caused a severe backlog of jobs everytime a user page was edited - each edit now would generate near to 5k jobs on Meta and across the farm temporarily shutting down the running of other more important jobs. SRE took the decision to move GUP away from any major wiki for farm stability purposes. As RfCs are advisory to SRE, we would not be looking to implement this proposal if it passed to ensure the stability of the farm can be maintained as much as possible. John (talk) 05:41, 30 November 2022 (UTC)
- @John: I can see how that would be an issue. However, our current format does not work because of the incapability of anyone but Stewards to moderate GUPs. Is there another solution that you, along with SRE, would be open to implementing? Thanks - BrandonWM (talk • contributions • global • rights) 05:44, 30 November 2022 (UTC)
- Global Sysops also have moderation abilities on loginwiki - though can you provide evidence for the claim of 'our current format does not work because of the incapability of anyone but Stewards to moderate GUP' as when I'm looking, moderation activity and need seems extremely low on loginwiki? I can't see a backlog of requests or blocks of actions. There's been 32 deletions this year (average of 3 a month), and looking at reverts, there's been 3 in the last 180 days where the reverter had not been the person making the edit. Based on this, I can't see any problem that requires solving where SRE needs to dedicate time to come to a solution. John (talk) 06:40, 30 November 2022 (UTC)
- As a former Global Sysop and Steward I can confirm that as far as I'm concerned I'm not aware of any moderation problems with loginwiki and definitely not to the scale that would require SRE to intervene as suggested. CVT members respond quickly to reports made on-wiki or on IRC or Discord, and there is little evidence that Meta sysops would respond faster given that many of them are part of CVT already. Reception123 (talk) (C) 07:45, 30 November 2022 (UTC)
- Dropping in to say this was never ever an issue in my time as steward and any login-level actions were very low priority. So the technical background and the nonexistent upkeep as claimed pretty much leave this proposal with nothing to do. --Raidarr (talk) 13:01, 30 November 2022 (UTC)
- @Reception123:, @Raidarr:: This proposal was initially created because users had voiced their concerns about global userpages being hosted on loginwiki, firstly because of the fact that loginwiki was not initially meant for GUPs. I know many users that weren't happy with the current running of things. Even one Steward had voiced support for a proposal like this not long ago. Secondly, Wikimedia has a functioning GUP system even though their GUPs are hosted on Meta. Perhaps we could see if we could replicate that in a fashion? I'm not keyed in from a technical standpoint, so I'm not sure if it's possible. Thirdly, it would also ease the burden on CVT to patrol the wiki, and would instead allow for a much more streamlined wiki feed instead of having to constantly check both. Thanks - BrandonWM (talk • contributions • global • rights) 14:56, 30 November 2022 (UTC)
- Dropping in to say this was never ever an issue in my time as steward and any login-level actions were very low priority. So the technical background and the nonexistent upkeep as claimed pretty much leave this proposal with nothing to do. --Raidarr (talk) 13:01, 30 November 2022 (UTC)
- As a former Global Sysop and Steward I can confirm that as far as I'm concerned I'm not aware of any moderation problems with loginwiki and definitely not to the scale that would require SRE to intervene as suggested. CVT members respond quickly to reports made on-wiki or on IRC or Discord, and there is little evidence that Meta sysops would respond faster given that many of them are part of CVT already. Reception123 (talk) (C) 07:45, 30 November 2022 (UTC)
- Global Sysops also have moderation abilities on loginwiki - though can you provide evidence for the claim of 'our current format does not work because of the incapability of anyone but Stewards to moderate GUP' as when I'm looking, moderation activity and need seems extremely low on loginwiki? I can't see a backlog of requests or blocks of actions. There's been 32 deletions this year (average of 3 a month), and looking at reverts, there's been 3 in the last 180 days where the reverter had not been the person making the edit. Based on this, I can't see any problem that requires solving where SRE needs to dedicate time to come to a solution. John (talk) 06:40, 30 November 2022 (UTC)
- @John: I can see how that would be an issue. However, our current format does not work because of the incapability of anyone but Stewards to moderate GUPs. Is there another solution that you, along with SRE, would be open to implementing? Thanks - BrandonWM (talk • contributions • global • rights) 05:44, 30 November 2022 (UTC)
- I think the RfC should be renamed. Whether or not the extension is moved to Meta is, I think, irrelevant to the point it's trying to make. The main point of this RfC should be to give other people the ability to edit and delete (basically, allowing loginwiki to have local admins) other people's userpages at loginwiki. Technically, there's no reason not to allow that wiki to have local admins, bureaucrats and oversighters, though there's a good reason to not allow local checkusers. However, the thing with the wiki is that userpages there show up everywhere unless the user has a local userpage. Thus, only very trusted people would get this ability, and it just so happens that Stewards fill that role perfectly, as they are already trusted people. Personally, kinda neutral on this, will think some more on this. Finally, I would like to point out that some non-Stewards have the ability to edit other people's userpages there, see Special:AbuseFilter/2. OrangeStar (talk) 12:58, 30 November 2022 (UTC)
- Please help with definitions. Thank you
- What is CVT? --Imamy (talk) 03:25, 5 December 2022 (UTC)
- What is GlobalUserPages? --Imamy (talk) 03:25, 5 December 2022 (UTC)
- What is loginwiki? --Imamy (talk) 03:25, 5 December 2022 (UTC)
- What is Meta? --Imamy (talk) 03:25, 5 December 2022 (UTC)
- CVT is short for Counter Vandalism Team. See CVT for more info.
- GlobalUserPages is an extension used to show a userpage on all wikis. See mw:Extension:GlobalUserPage for it's documentation.
- LoginWiki uses the aformentioned GUP to show a global user page.
- Meta is this wiki. --Blad (talk • contribs • global) 12:56, 5 December 2022 (UTC)
Proposal 2: Status Quo[edit | edit source]
GlobalUserPages remain on loginwiki, no changes will be made. Stewards remain the sole enforcement option for GlobalUserPage-related issues.
Support[edit | edit source]
Abstain[edit | edit source]
Oppose[edit | edit source]
Strongest oppose The current format is not working for many users, doing nothing would not be productive. Thanks - BrandonWM (talk • contributions • global • rights) 05:31, 30 November 2022 (UTC)
Comments[edit | edit source]
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.