Requests for Comment/interwiki-admin changes

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Proposal 5 is successful. John (talk) 13:17, 28 June 2019 (UTC)

---

I propose a reconsideration of the current policy around the interwiki right and the interwiki-admin group. Bonnedav (talk) 08:00, 13 May 2019 (UTC)

Proposal 1

Leave everything as it is.

Support

1.  Support I see no need for change. MacFan4000 ^{(Talk Contribs)} 18:13, 13 May 2019 (UTC)

Oppose

1.  Strong oppose I of course oppose this as it would defeat the purpose of this entire thing. Bonnedav (talk) 08:00, 13 May 2019 (UTC)
2.  Weak oppose We do need a way to allow more users to manage interwiki links. Which is why I proposed proposal 5 below.--開拓者 (The Pioneer) (^talk/_contribs | global🌎) 14:39, 14 May 2019 (UTC)
3.  Strongest oppose We have a lack of interwiki links and we currently have less than 5 interwiki admins. I support @Bonnedav:. Fungster ^{(contribs - email - CA)} 05:35, 28 June 2019 (UTC)

Proposal 2

Remove the "Have at least 1000 total global edits on Miraheze" requirement for getting interwiki-admin.

Support

1.  Strong support Not even stewardship has such a requirement, and they can do this anyway. I believe this is unnecessary and intrusive. Bonnedav (talk) 08:00, 13 May 2019 (UTC)

   I also agree with Spike's reasoning for why edit counts should not be part of eligibility requirements. Bonnedav (talk) 22:27, 31 May 2019 (UTC)

Oppose

1.  Oppose Stewardship does not have this requirement as the vote is more demanding in itself and users vote based on the users activity. In the case of interwiki-admin, there is not really any specific criteria, so 1000 global edits can prove that a user has been around for a while and is active. Reception123 (talk) (C) 17:29, 13 May 2019 (UTC)
2.  Oppose per above. MacFan4000 ^{(Talk Contribs)} 18:13, 13 May 2019 (UTC)
3.  Oppose Not for global interwiki-admin. However, for locally limited permissions, this regulation may be weakened (see proposal 5).--開拓者 (The Pioneer) (^talk/_contribs | global🌎) 15:39, 14 May 2019 (UTC)
4.  Weakly oppose -  Abstain My opposal is so weak... and I do not think that the clause will be removed... Fungster ^{(contribs - email - CA)} 05:44, 28 June 2019 (UTC)

Comments

1.  Comment: See my problem is that some people are active but don't make a ton of edits. They are active in other ways like rollbacking, blocking, chat, GitHub, Phabricator, IRC, or whatever. They make a small number of high-quality edits rather than a high number of lesser-quality edits. What I am saying is that I don't that number of edits alone accurately shows a users activity. Bonnedav (talk) 16:59, 14 May 2019 (UTC)

   How about "logged actions" instead of "edits"? Bonnedav (talk) 19:52, 14 May 2019 (UTC)

Proposal 3

Allow local bureaucrats to manage the local interwiki table. Keep interwiki-admin to monitor interwiki edits and remove bad/malicious links.

Support

1.  Support I believe that local wiki admins and bureaucrats should have as much power over there wikis as posable. Keeping interwiki-admin around to monitor the tables should help to alleviate some of the security concerns right? I don't wish to start an argument, I have already read the concerns brought up in the original proposal. Bonnedav (talk) 08:00, 13 May 2019 (UTC)
2.  Support As the Admin of a knock-off of Uncyclopedia, with frequent links to Uncyclopedia, I would like the ability to react to Uncyclopedia's search for a new home without filing requests, as this move affects only my wiki. With apologies to @Reception123: The local interwiki table does not "create" a security risk. As I understand it, it merely defines link prefixes on that wiki; if you type [[Uncyc:Pez]], it defines what "Uncyc:" means, determines what wiki the link points to. The security risk is that a user can unwillingly be sent to a malicious external website, but that is a trick that any wiki editor can pull by inserting a single-bracket external link that is not what it says it is. A malicious Admin has many other ways to do the same thing, such as with Common.js. But the interwiki-admin governs all wikis that do not make such decisions for themselves, and should remain a function of Miraheze management. Spıke (talk)21:05 13-May-2019

   In your dismissal of Reception’s comment you have described and acknowledged the security concern raised. There is a difference between Main Page and Main Page and that difference is what makes it more secure. John (talk) 21:37, 13 May 2019 (UTC)

   Then there is something I'm missing, as your example doesn't have a prefix at all. Does the local interwiki table also define where to go for links that don't have a prefix? That would make it too easy to screw up everyone on a wiki, though again, not giving the Admin any power he doesn't have in other ways. Spıke (talk)22:54 13-May-2019

   Main Page and Main Page. There, is there a difference? Still no difference - the exact same outcome and the exact same point being made. John (talk) 00:10, 14 May 2019 (UTC)

   External links can be easily faked as if it's an interwiki link by using <span class="plainlinks"> anyway. Main Page, Main Page. Can you tell me which is which (without looking diffs and sources)?--開拓者 (The Pioneer) (^talk/_contribs | global🌎) 14:21, 14 May 2019 (UTC)

   Indeed, but is that a reason to make it easier, make it less obvious in source code? On the same basis, people can get users edit tokens through methods, should that mean we should publish everyone's edit tokens to make it easier? John (talk) 14:25, 14 May 2019 (UTC)

   OK, I'm actually against this proposal, but at the same time think that local crats should have a chance to gain interwiki-admin permissions for their own wiki if trusted (see below). Apart from it, I just wanted to be fair about facts on this discussion here.--開拓者 (The Pioneer) (^talk/_contribs | global🌎) 15:19, 14 May 2019 (UTC)

3.  Strong support I strongly believe that increasingly the global community/global staff should be slowly delegating more of their toolset to local communities, especially as Miraheze continues to grow in size. The chances of malicious links (i.e. spam, malware, illegal stuff) being added by a bureaucrat or admin on a local wiki are relatively low - 99% of the time, if a privileged user does something like that, they've either been compromised and/or have gone rouge, and therefore the solution is removing their permissions individually - not removing the entire ability to take said actions. For this reason I also strongly support keeping global interwiki-admin with the same policy/criteria so that there is at least a basic level of oversight to check for shenanigans like this (kind of like conducting a random audit at routine intervals to make sure that everything is still working as intended). If a malicious link somehow gets added to a local interwiki table, it should be the responsibility of the local bureaucrat/admin/groups with Interwiki access to remove it. If for some reason that doesn't happen, a global interwiki-admin can intervene. This is what I view as the ideal situation for Miraheze as a whole over the course of time: have most everything in the hands of the local community (except for things that could either have legal problems and/or break something across the entire farm) but then have a global group with the same permissions to ensure that nothing is happening that shouldn't be happening. Amanda Catherine (talk) 20:21, 18 May 2019 (UTC)
4.  Strongest support Interwiki admins are getting too involved in managing interwiki links. That's why I support this. Fungster ^{(contribs - email - CA)} 05:44, 28 June 2019 (UTC)

Oppose

1.  Oppose It is impossible to monitor links, and this creates a security risk for users. Reception123 (talk) (C) 17:34, 13 May 2019 (UTC)
2.  Oppose per above. MacFan4000 ^{(Talk Contribs)} 18:13, 13 May 2019 (UTC)
3.  Oppose per above.--開拓者 (The Pioneer) (^talk/_contribs | global🌎) 14:40, 14 May 2019 (UTC)
4.  Oppose Still getting a hang of how things work around here but it seems reasonable to not allow any bureaucrat to edit that link as it could be a security problem for the users on that wiki. --DeeM28 (talk) 18:33, 11 June 2019 (UTC)

Proposal 4

Allow local bureaucrats to manage the local interwiki table. Remove interwiki-admin altogether.

Support

1.  Weak support I believe that local wiki admins and bureaucrats should have as much power over there wikis as posable. I don't wish to start an argument, I have already read the concerns brought up in the original proposal. Bonnedav (talk) 08:00, 13 May 2019 (UTC)

Oppose

1.  Oppose Per my comment above; oppose removal of interwiki-admin altogether. Reception123 (talk) (C) 17:34, 13 May 2019 (UTC)
2.  Oppose per above. MacFan4000 ^{(Talk Contribs)} 18:13, 13 May 2019 (UTC)
3.  Strong oppose Removing interwiki-admin is just nonsense. Who will fix the interwikis if they go wrong (under this rule)?--開拓者 (The Pioneer) (^talk/_contribs | global🌎) 14:42, 14 May 2019 (UTC)
4.  Oppose Same as what I say above. --DeeM28 (talk) 18:34, 11 June 2019 (UTC)
5.  Oppose Fungster ^{(contribs - email - CA)} 06:00, 27 June 2019 (UTC)

Proposal 5

Create a "local" interwiki-admin role which can be given to certain bureaucrats which satisfy the conditions below.

1. Have at least 500 edits on their own wiki (which they want to request the permission for).
2. Have been registered on Miraheze for at least 2 weeks.

This "local" interwiki-admin request will be handled by Stewards (with the same voting criteria with the "global" interwiki-admin), and "local" interwiki-admins can edit interwiki links only on their local wiki(s) (which they asked for).

Current interwiki-admin criteria will remain the same, but to make it clear, it will be renamed as "global" interwiki-admin.

Support

1.  Support As being part of an interwiki-admin myself, I feel the need for more interwiki-admins. However, I do understand concerns raised by other volunteers/staffs at the same time; that local admins may add malicious interwiki prefixes. Thus, this is IMO a rational solution. Local crats can get their local interwiki-admin permission easier than having global interwiki-admin permission, but first of all, they must show activities on their own wiki to gain trust in the community.--開拓者 (The Pioneer) (^talk/_contribs | global🌎) 14:37, 14 May 2019 (UTC)
2.  Support After having a discussion and listening to the view point, on large wikis or ones where a lot of requests come in, I can see and understand this. If the regulating of local interwikis falls back upon interwiki-admins, I don't have any major qualms with this. John (talk) 16:09, 14 May 2019 (UTC)
3.  Weak support This might be ok, however, I don't think that edit count alone will tell you who deserves it. I also don't like the idea of local communities being forced to get consensus on something. Some wikis want to be a dictatorship and one of the things I like about Miraheze is that you can do that if you want. Unlike Wikimedia and Wikia witch enforce that everything on every wiki is decided by consensus. Also, if this passes I would recommend doing something similar for rights like bigdelete and maybe even CU(but I don't want to open that can of worms right now). Bonnedav (talk) 18:35, 14 May 2019 (UTC)

   Miraheze is actually like Wikimedia. Stewards do not respect dictatorships and if consensus develops for something a bureaucrat doesn't want, Stewards will ensure the consensus is applied. John (talk) 19:00, 14 May 2019 (UTC)

   Fair enough, but there is still a difference between local consensus that occurs on it's own and a policy mandating the collection of local consensus on a particular issue. Bonnedav (talk) 19:45, 14 May 2019 (UTC)

4.  Strongly support Fungster ^{(contribs - email - CA)} 05:44, 28 June 2019 (UTC)

Proposal 6

Implement proposal 5 but change "edits" to "logged actions" for both local and global requirements.

Support

1.  Support Sense people seem to want the edits requirement to stay, how about this: instead of strictly saying edits we say logged actions? This would include edits but also rollbacks, blocks, wiki creations, and anything else that leaves a public log entry. I feel that this would give a better representation of a user's activity then just edits alone. Bonnedav (talk) 22:48, 14 May 2019 (UTC)
2.  Weak support Only if the proposal above does not pass. Fungster ^{(contribs - email - CA)} 05:44, 28 June 2019 (UTC)

Comments

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section