Talk:Global sysops/2008 proposal

Talk:Global sysops

Name

The following discussion is closed: Name is 'global sysop'.

---

Just to say that I didn't find a better name than a descriptive one. So, if anyone has a better name, let they say it here :) --Millosh 07:22, 31 May 2008 (UTC)

Double negative may be different in English than in Norwegian, but to me an "Anti-vandal fighter" sounds like someone fighting anti-vandals. And that's not good, is it? Jon Harald Søby 11:39, 31 May 2008 (UTC)

Actually, I think that we should find one word for this role. Something like keeper or watcher or whatever. I don't prefer aggressive or military terminology, but I am not a native English speaker and it is not so easy to me to find a better word. --Millosh 12:10, 31 May 2008 (UTC)

And, as you may see in this article, double negative is usual in Slavic languages :) --Millosh 12:10, 31 May 2008 (UTC)

Certainly not a fan of "Anti-vandal" as a name. As with the word "spam" is leads to pointless arguments & misconceptions. For some time now I have considered I am involved with dealing with disruptive editing. I stress I'm not looking for "group of people who deal with disruptive editing across more than x wikis" as a title :) However it should be something that encompasses the various forms of disruptive editing - I agree with Millosh - hard to find a good word --Herby ^{talk thyme} 12:40, 31 May 2008 (UTC)

We should find the right name for this role. As I said above, I don't like this name. Please, add your suggestions here in alphabetic order. Suggestions will be gathered for ~ one week (until June, 7th) and we will vote from June 8th, 2008 to June 14th, 2008. Name with the most supporting votes will be the name for the role. So, vote from June 8th only if you are in favor of one or more names (so, no opposing votes). without sense now --Millosh 12:29, 31 May 2008 (UTC)

I'm not a fan of "anti-vandal fighter" either. "Global maintenance" or "Cross-wiki maintenance" perhaps?  – Mike.lifeguard | ^@en.wb 12:48, 31 May 2008 (UTC)

Definitely a step in the right direction. "Global rollback" are the rights (?) so something "Global ***" seems good --Herby ^{talk thyme} 12:52, 31 May 2008 (UTC)

I would like to have one word name for them :) As other roles have that. --Millosh 12:56, 31 May 2008 (UTC)

We call this role "janitor" on Wikia. It fits well with the idea that adminship is no big deal and that these people are here to help clean up, not to rule the wiki or make policy decisions. Angela

OK. One word, so I agree :) --Millosh 13:48, 31 May 2008 (UTC)

"Global janitor"? It emphasizes that this is a global role, which is new for WMF projects.  – Mike.lifeguard | ^@en.wb 16:26, 31 May 2008 (UTC)

"globetrotter"? :) I really prefer one word. --Millosh 22:35, 31 May 2008 (UTC)

Or even just "traveler" or something similar? --Millosh 22:50, 31 May 2008 (UTC)

 Oppose "janitor" is aready in use in the Wikiversity. Its a bad idea to label two different jobs with one common name. --Purodha Blissenbach 13:09, 4 June 2008 (UTC)

I'm not too sussed about the name, although I agree it probably should be addressed before the permission itself goes live. "vandalism cleaner" ?? ++Lar: t/c 18:46, 31 May 2008 (UTC)

Janitor seems fine to me. Majorly ^talk 22:39, 31 May 2008 (UTC)

• global helper; global assistant; because I prefer something positive, a fighter is something aggressive, but users in this group should just help out, also vandal is sometimes not the right word, not everything is vandalism, even if it looks like it sometimes. (global dirt sweepers ;) ) --birdy geimfyglið _(:> )=| ∇ 22:54, 31 May 2008 (UTC)
  • I am asking for one word because it would be much more easy to refer to those contributors much more easily by saying "we need help from janitors|globetrotters|travelers|custodians|keepers..." than "we need help from someone from the group of global dirt sweepers" :) Also, if we don't give to them a short name, they will be called colloquially different; something like "globallers" or so. Some abbreviation or something similar may be good, too. --Millosh 23:09, 31 May 2008 (UTC)

• Janitor and Helper is already taken by wikia sadly, and they do exactly the same thing but I think we need a unique name for the WMF wikis and right now, I have only 1 idea:

• Nomads - "nomads, are communities of people that move from one place to another, rather than settling down in one location." which is what these group of people will be doing (can be used as Global nomads to)..--Cometstyles 23:02, 31 May 2008 (UTC)

Actually, I really like "nomads" :D  – Mike.lifeguard | ^@en.wb 23:10, 31 May 2008 (UTC)

Nomads is meaningless to me (and possibly most people). The name should at least be obvious as to what the job entails. Majorly ^talk 23:13, 31 May 2008 (UTC)

I like nomads, too :) --Millosh 23:32, 31 May 2008 (UTC)

"Taken by Wikia"? There is no ownership of a single name. And, that Wikia uses that name for the same purpose, that is to me a very good argument that we should do it too. Why purposefully add another name to the same function when we can keep things consistent over the wikiworld? Jon Harald Søby 11:18, 1 June 2008 (UTC)

How about monitor? Since the members of this group will be "monitoring" small wikis, it makes sense. Majorly ^talk 23:16, 31 May 2008 (UTC)

Sounds good to me. --Millosh 23:29, 31 May 2008 (UTC)

I like it. Cbrown1023 talk 00:47, 1 June 2008 (UTC)

Not bad, just add a Global in front and it won't sound cabalish ;) ...--Cometstyles 00:55, 1 June 2008 (UTC)

I love nomad or traveller & the fact that no one understand it would be a big plus - they won't come trying to get the rights themselves.

More seriously "global monitor" sounds pretty good (I see no harm in two words one of which is global) --Herby ^{talk thyme} 12:55, 1 June 2008 (UTC)

These are users with global sysop access, so why not call them "global sysop" or "backup sysop"? This is unambiguous and draws a parallel to the local group (so users don't need to read technical pages to know what sort of access they have), and removes the artificial limits imposed by names like "anti-vandal" (are they prohibited from dealing with other tasks, like updating the interface on a wiki with no administrators?). —{admin} Pathoschild 19:36:34, 01 June 2008 (UTC)

I like "backup sysop" and "global janitor" - how about "auxilliary sysop"? To me, "monitor" has a slight big brother is watching you feel to it... WjBscribe 09:44, 2 June 2008 (UTC)

Not sounding to "Militarish", but "Reserves" also sounds like a good name, reserves are backups and are called in when the the main team can't handle the pressure, probably sounds funny, but its quite possibly a better name to choose and probably less intrusive..--Cometstyles 10:04, 2 June 2008 (UTC)

how about wiki Knights ? joking aside i think global janitor is good enough --Mardetanha ^talk 10:07, 2 June 2008 (UTC)

I don't think we should use obscure names. The proposal is for global sysops, so we should call them 'global sysops' or 'backup sysops'— not knights, reserves, monitors, nomads, janitors, or apples. The name should reflect their purpose, be as intuitive as possible, and be easily translated. It's not a noble military title, they're not intended to back up Wikimedia's standing army, they're not tasked with passively watching, they're not simply travelers, we're not looking to hire cleaners and repairmen, and they're not fruit of the Malus sylvestris tree. —{admin} Pathoschild 21:20:47, 02 June 2008 (UTC)

To be precise, they are not sysops. While they have similar permissions to sysops, they don't have similar rights. For example, they wouldn't be allowed to block anyone for, for example, trolling. If such [controversial] action is needed on a wiki without admins, it's a stewards' job, not their. The most precise description is the current name: they are anti-vandal fighters (yes, they will fight against vandals and this will be their first and last job; while it is not good to have an aggressive terminology, this will be the fact). However, we need some other name... --Millosh 22:34, 2 June 2008 (UTC)

I don't think that the name is a big deal. So, I think that we should vote soon and that the name with the most of votes in the first round should win (everyone should be able to vote for as many options as they like). Whatever proposal wins, I would be happy :) --Millosh 22:34, 2 June 2008 (UTC)

this name is misleading. Sysop is a term generally applied to administrators. Anti-vandal fighter is not a sysop (administrator) but has a subset of sysop powers. To call them global sysops would be deceptive and a gross missuse of the term. Dbiel 02:25, 4 June 2008 (UTC)

Sysop does not equal administrator. example ([move=sysop]) vadlal fighter would be able to move these pages as can serveral other classes of users Dbiel 20:57, 6 June 2008 (UTC)

oppose, they should not act as sysop, how to call stewards for their technical access then --birdy geimfyglið _(:> )=| ∇ 13:17, 4 June 2008 (UTC)

vandal fighters** Cbrown1023 talk 23:40, 2 June 2008 (UTC)

• Janitor fits the role well enough, it is not a battle (fight) between the vandal and the janitor, it is a cleansing operation. JMHO.--Alnokta 13:37, 3 June 2008 (UTC)

As I think that there are not a lot more to be said about names, I think that it is a time to make a poll. I'll announce it foundation-l, too. If I missed some proposal, pleas add it in alphabetical order. --Millosh 18:32, 3 June 2008 (UTC)

Janitor  Oppose People may get confused by the "Janitor" right on Wikiversity--penubag 15:53, 5 June 2008 (UTC)

Note: Wikiversity uses the term "custodian", which is sometimes synonymous to "janitor".Hillgentleman 01:27, 7 June 2008 (UTC)

the preceding two entries (starting with Janitor  Oppose were move out of the poll list which is not to include any negative votes Dbiel 20:05, 9 June 2008 (UTC)

Poll

Poll is closed. The name of the proposed role is global sysop.

Please, vote for one or more proposals. Negative votes won't be counted. Voting begins at the time of announcing this page (around 18:30 UTC at June 3rd) and lasts 7 days, up to June 10th, 2008 at 18:30 UTC.

Proposal with the most of votes will win in the first round.

Anti-vandal fighter

1. Up to discussion seems to be ok by me--Mardetanha ^talk 18:35, 3 June 2008 (UTC)
2.  – Mike.lifeguard | ^@en.wb
3. I think this one should be used one step lower, e.g. people who do a lot of cross-wiki cleanup, but do not need access to e.g. deletion (but with e.g. rollback etc.). --Dirk Beetstra ^{T C} (en: U, T) 09:11, 4 June 2008 (UTC)
4. --penubag 15:49, 5 June 2008 (UTC)

Apple

1. ...

Backup sysop

1.  – Mike.lifeguard | ^@en.wb
2. WjBscribe 08:10, 4 June 2008 (UTC)
3. --Dirk Beetstra ^{T C} (en: U, T) 11:32, 10 June 2008 (UTC)

Cross-wiki maintenance

1.  – Mike.lifeguard | ^@en.wb
2. WjBscribe 08:10, 4 June 2008 (UTC)
3. Seems OK .. though calling deletion of rubbish 'maintenance' does not give a true reflection. --Dirk Beetstra ^{T C} (en: U, T) 09:12, 4 June 2008 (UTC)
4. --birdy geimfyglið _(:> )=| ∇ 14:57, 4 June 2008 (UTC)

Global assistant

1. ...

Global dirt sweeper

1. ...

Global helper

1. ...

Global janitor

1. And this sounds good for me also --Mardetanha ^talk 18:43, 3 June 2008 (UTC)
2. Either this or simply "janitor" as below. Adambro 19:14, 3 June 2008 (UTC)
3. WjBscribe 08:10, 4 June 2008 (UTC)

Global maintenance

1.  – Mike.lifeguard | ^@en.wb
2. WjBscribe 08:10, 4 June 2008 (UTC)
3. Dbiel 23:16, 4 June 2008 (UTC)

Global monitor

1. --Yaroslav Blanter 13:23, 4 June 2008 (UTC)

Global rollback

1. Different function. Not real sysops. --Dirk Beetstra ^{T C} (en: U, T) 09:13, 4 June 2008 (UTC)

Global sysop

1. The proposal is for users with global sysop access, so they should be called "global sysop" or "backup sysop". The name should reflect their technical access and not their community role (while their role can change, their name is permanent). This is unambiguous and draws a parallel to the local group (so users don't need to read technical pages to know what sort of access they have), and removes the artificial limits imposed by some of the other proposals (which don't reflect the actual proposal or allow future change). —{admin} Pathoschild 20:37:01, 03 June 2008 (UTC)
2. Second choice. Nakon 20:38, 3 June 2008 (UTC)
3. --Nemo 21:15, 3 June 2008 (UTC)
4. I will agree with anything but Janitor as this will cause more tension between ppl who believe wikia is wikimedia..--Cometstyles 22:53, 3 June 2008 (UTC)
5. Per Pathoschild. — H92 (t · c · no) 00:52, 4 June 2008 (UTC)
6.  – Mike.lifeguard | ^@en.wb
7. Per Pathos. --Rory096 01:24, 4 June 2008 (UTC)
8. Janitor is too ambiguous. giggy _(:O) 01:38, 4 June 2008 (UTC)
9. Janitor is too much like wikia Legoktm 03:38, 4 June 2008 (UTC)
10. Mr.Z-man 04:00, 4 June 2008 (UTC)
11. per Pathoschild. Werdna 05:32, 4 June 2008 (UTC)
12. --.snoopy.  05:36, 4 June 2008 (UTC)
13. WjBscribe 08:10, 4 June 2008 (UTC)
14. --Nick1915 - ^{all you want} 09:00, 4 June 2008 (UTC)
15. Sounds good to me. (or 'Global Administrator'?)--Dirk Beetstra ^{T C} (en: U, T) 09:09, 4 June 2008 (UTC)
16. Sounds informative — VasilievV ² 09:15, 4 June 2008 (UTC)
17. Per VasilievVV --Erwin(85) 14:55, 4 June 2008 (UTC)
18. per vasilievVV. --Ahonc 20:45, 4 June 2008 (UTC)
19. —DerHexer (Talk) 20:58, 4 June 2008 (UTC)
20. Both informative and pleasant. Global administrator too. Cenarium (talk) 02:43, 5 June 2008 (UTC)
21. Is good. --Anonymous Dissident^Talk 06:11, 5 June 2008 (UTC)
22. --MF-W 14:45, 5 June 2008 (UTC)
23. --penubag 15:49, 5 June 2008 (UTC)
24.  Support sysop does not = administrator - example ([move=sysop]) vadlal fighter would be above to move these pages Dbiel 20:52, 6 June 2008 (UTC)
25. AVF is a misnomer, since they would be involved in far more than vandalism fighting – this name more accurately reflects this. haz (talk) 10:27, 9 June 2008 (UTC)
26. Second choice. - Mailer Diablo 14:25, 9 June 2008 (UTC)
27. SPQRobin 15:42, 9 June 2008 (UTC)
28. Platonides 21:16, 10 June 2008 (UTC)

Common Sysop

1. …

Cross-wiki Sysop

1. --Purodha Blissenbach 23:29, 4 June 2008 (UTC)

Cross-wiki Admin

1. --Purodha Blissenbach 23:30, 4 June 2008 (UTC)

Globetrotter

1. --Millosh 09:15, 4 June 2008 (UTC)

Helper

1. pro, --birdy geimfyglið _(:> )=| ∇ 00:46, 4 June 2008 (UTC)
2. WjBscribe 08:10, 4 June 2008 (UTC)

Janitor

1.  Support no need for redundancy of adding "Global", this role isn't available locally so Janitor alone would suffice.--Alnokta 19:08, 3 June 2008 (UTC)
2.  Support I like this term, I think it describes the role pretty well. Not too fussed whether we prefix it with "Global", this might be appropriate. Adambro 19:14, 3 June 2008 (UTC)
3.  Support The name corresponds well with the name steward and it seems to describe the role well. I think we should try to avoid the words "vandalism" and "fighter" (and also "spam") here, those words can be counter productive. --Jorunn 20:12, 3 June 2008 (UTC)
4. Majorly ^talk 20:17, 3 June 2008 (UTC)
5. Nice one. Also used at Wikia — VasilievV ² 20:18, 3 June 2008 (UTC)
6. Seems OK. Nakon 20:29, 3 June 2008 (UTC)
7. Thunderhead 20:41, 3 June 2008 (UTC)
8.  Support Cbrown1023 talk 21:02, 3 June 2008 (UTC)
9. This name is already in use on other sites and working well. Angela 22:09, 3 June 2008 (UTC)
10.  Support --Kiensvay 00:35, 4 June 2008 (UTC)
11.  – Mike.lifeguard | ^@en.wb
12.  Support Jkasd 04:05, 4 June 2008 (UTC)
13. WjBscribe 08:10, 4 June 2008 (UTC)
14.  Support "Global Sysop" implies too much power.--Werdan7^{T @} 16:05, 4 June 2008 (UTC)
15. While this it is unfortunate this is the same name than Wikia, this is the one that describes the position the best (global sysop implies that they have more power than local sysops). -- lucasbfr ^talk 12:24, 5 June 2008 (UTC)
16. Very fortunate that this is the same name as on Wikia. It is a very big plus to keep consistency around the wiki-world. It's pointless to create another (new) name for the exact same position, and create ambiguity. Jon Harald Søby 01:08, 7 June 2008 (UTC)
17. Mailer Diablo 14:25, 9 June 2008 (UTC)

Knight

1. ...

Keeper

1. ...

Monitor

1. --Purodha Blissenbach 23:31, 4 June 2008 (UTC)

Nomad

1.  – Mike.lifeguard | ^@en.wb
2. ..--Cometstyles 04:13, 4 June 2008 (UTC)
3. --.snoopy.  05:37, 4 June 2008 (UTC)
4. --Millosh 09:14, 4 June 2008 (UTC)
5. --Cradel 21:17, 5 June 2008 (UTC)

Reserve

1. my second choice, Probably a less intrusive name :) ..--Cometstyles 23:00, 3 June 2008 (UTC)
2.  – Mike.lifeguard | ^@en.wb

Traveler

1. ...

Vandal fighter

1.  – Mike.lifeguard | ^@en.wb
2. Zouavman Le Zouave

Vandalism cleaner

1.  – Mike.lifeguard | ^@en.wb

Cross-Wiki Vandal Fighter

1.  – Mike.lifeguard | ^@en.wb

Watcher

1. ...

SWMT

1. --Purodha Blissenbach 23:30, 4 June 2008 (UTC)
2.  – Mike.lifeguard | ^@en.wb
3. Daniel (talk) 00:13, 7 June 2008 (UTC)

No no no

The following discussion is closed: Avoid battleground mentality

---

WikiMedia is about providing useful free of cost copy-left educational information to all mankind. Our openness to vandals is a problem, not a reason to transform us into a battleground. No no no. Better to stop allowing random edits than to go this route. (WAS 4.250) 4.251.121.134 08:17, 31 May 2008 (UTC)

After some point it is useless to find a constructive way for dealing with vandals. Battleground exists for a long time and stewards are fighting there. BTW, how to "stop allowing random edits"? --Millosh 08:29, 31 May 2008 (UTC)

This is a needful task that occupies a goodly fraction of steward and small wiki task force volunteer time. Providing better tools to address the issue (I avoid "fight" or "combat" because I take your point) seems a good idea to me. ++Lar: t/c 18:47, 31 May 2008 (UTC)

Anti-vandal fighter#Policy for requesting anti-vandal fighter status

The following discussion is closed: Tweaked requirements

---

This section seems rather unclear to me. That sounds like exactly the same criteria as Meta:Requests_for_adminship#Regular_adminship. "The candidate will be named sysop here only if..." -- but we are not talking about sysop here, we are talking about this global antivandal role. I'm not sure whether the requirements should be changed, but perhaps clarifying would be a good idea.  – Mike.lifeguard | ^@en.wb 11:14, 31 May 2008 (UTC)

Yes, I copied conditions from that page :) I didn't change that a lot, so, yes, if it is needed, this part should be adapted. I am sure that you understand the sense (anti-vandal fighters should be elected and there are some requirements for them), so, please, rephrase (or whatever) that as you think that it is the best. --Millosh 11:21, 31 May 2008 (UTC)

OK, I updated the language. I think that the requirements need tweaking though. I don't think the first point ("Having been a participant for at least 2 months on at least two projects other than Meta" is what we really want - we want people to be active on many projects and fighting spam/vandalism on them. If they have made small numbers of edits but spread out over 700 wikis that is still fine. I'd change it to something like "Having been a noted cross-wiki anti-spam/vandal fighter for a period of at least 2 months." That of course raises the question of the meaning of "cross-wiki" (how many?) and of "anti-spam/vandal fighter" (how active?). These are topics for discussion.  – Mike.lifeguard | ^@en.wb 12:11, 31 May 2008 (UTC)

I think there is a sense in which if you are active cross wiki it will be on quite a few projects. I think it is unlikely that someone will show up asking for the rights unless they already have cross wiki interests (we are quite a rare breed!). However I guess it would be an idea to make it quite a high bar to prevent the "ooo nice shiny new tool & I want it" approach from anyone. --Herby ^{talk thyme} 12:17, 31 May 2008 (UTC)

Or, maybe, being a member of SWMT for at least two months and actively participate in its work or so? This means that we will have the exact date of becoming a member of SWMT (the date when they added themselves at the SWMT members list) and we would be able to see user's actions from that time. Also, it should be noted that a candidate should give relevant links (contributions on various projects) for their involvement into SWMT housekeeping. --Millosh 12:20, 31 May 2008 (UTC)

Yes, but the problem is that SWMT is mostly-self managed. You put yourself on the list and nobody checks if you're actually doing it. On the other hand, those who are active do know each other, so when you ask for the bit, we will say "but you don't do anything".  – Mike.lifeguard | ^@en.wb 12:47, 31 May 2008 (UTC)

Maybe to give a better introduction at the SWMT page? Something like: If you want to start immediately, go to #wikimedia-stewards channel and ask how can you help. Also, some more documentation at SWMT page would be good, too. Etc. etc. Also, note that this role is discussed at the stewards' list exactly because of the members of SWMT (there are some users who are not stewards and who are willing to help, so, we are able now to give them the right tools). Also, as a lot of SWMT members are stewards, too -- stewards would be able to monitor actions of other members of SWMT. --Millosh 12:53, 31 May 2008 (UTC)

Agree with Mike and Herby above, most ppl are driven by "ooh shiny new tools. me can have it?" rule, and believe me most don't even contribute, its just a trophy, Global rollback was a start, and you have managed to take it 4 steps forward, great, but this will be problematic in years to come, I have a good name for this, "Stewards'..better let the professionals handle it for now :P ..--Cometstyles 13:09, 31 May 2008 (UTC)

Maybe this looks like without a context, but, again, we were discussing at stewards' list about what is needed for housekeeping for a week or so. Giving to a SWMT member just a right to revert change is similarly to asking someone to clean some dirt with towel, but without water and without detergent. Yes, it is possible, but it is a harder way for doing so. Also, it is not so hard to become a "professional". I know a number of contributors who have a lot of knowledge and who are helping a lot, but who didn't pass voting for stewardship. --Millosh 13:57, 31 May 2008 (UTC)

I'm with Comets here. It is sad that "rights" are seen as something get rather than something that is for using. It would be a pity if this merely attracted people who thought it would be another badge for them - there are enough of those around as it is. I am not sure I would warrant such rights for example even though I do deal with excessive linkage anywhere I have the time to do so. People should be really active to warrant this not simply to want it --Herby ^{talk thyme} 11:23, 1 June 2008 (UTC)

It may be solved partially by confirmation of the rights; with participation of global maintainers in voting (stewards, meta bureaucrats and anti-vandal fighters themselves). (BTW, I would like to see the same for stewards and Meta bureaucrats: not to be confirmed only by themselves.) --Millosh 11:57, 1 June 2008 (UTC)

"Confirmation" I would certainly be in favour of. I know I keep saying it but tools are for using, if people don't use them any more the are removed & handed back if needed again --Herby ^{talk thyme} 12:53, 1 June 2008 (UTC)

BTW, it is really good to build a policy together :) I missed this part, even it exists for stewards, too. --Millosh 18:48, 1 June 2008 (UTC)

I added "Policy for removing rights" from Meta:Administrators. --Millosh 12:04, 1 June 2008 (UTC)

Mark as patrolled

Mark as Patrolled is not necessarily used for quality control, at least on nl.wp it's used for first vetting of contributions for vandalism, makes-sense, ... Be carefull when assuming global permissions :) Henna 11:31, 31 May 2008 (UTC)

Considering that these users may well be working on projects in languages they do not understand, I'd be wary about allowing patrolling. OTOH, much/most vandalism is easy to spot regardless of the language. Still, I think patrolling is not required for this set of tasks.  – Mike.lifeguard | ^@en.wb 12:01, 31 May 2008 (UTC)

it's a fairly usefull way to revert something and mark it as patrolled so that it doesn't show up in recent changes anymore :) Henna 12:39, 1 June 2008 (UTC)

unnecessary

The following discussion is closed: Global sysops would have the similar permissions like admin, while not the same rights. Unlike admins, global sysops have the permissions at all projects.

---

there's no need for two different names for the same job. to me it seems, we're trying to solve a social problem in a technical way: technically, cleanup-admins, anti-vandal-fighters or whatever you call them need to have nearly the same permissions as regular admins: deleting pages, reverting edits, maybe blocking a vandal. the important difference is a social one: a cleanup-admin should deal with vandals only and not meddle in the affairs of the community. this cannot be controlled by software. -- ∂ 21:41, 31 May 2008 (UTC)

This is different from regular admins. Regular admins have rights locally, on one wiki. This proposed "Anti-vandal fighter" would have admin rights glboally, on every Wikimedia wiki. That is why there are two different names. Cbrown1023 talk 22:25, 31 May 2008 (UTC)

Exempting projects

The following discussion is closed: Opting-out technically adopted in the second proposal

---

Perhaps it wouldn’t be such a bad idea to integrate a section permitting individual communities to opt-out from being subject to actions by this user class. This would also be handy in avoiding any misunderstandings as to whether an individual project is in sufficient `stock` with admins or not - each community can decide if they feel up to the task of keeping their project tidy on their own, and would help avoid global sysops earning some sort of a vigilante rep (which I’m not saying they would, but it doesn’t hurt to be on the safe side of things when it comes to such a potentially intrusive tool). Don’t get me wrong, I think it’s a great idea to supply volunteers of the SWMT with an efficient tool for the work they do, but it would be nice to assure that the integrity of individual projects remains intact not just through expecting AVfs to be responsible. --Кале 20:15, 1 June 2008 (UTC)

Permissions are global, so it is not possible to make opt-out. If an anti-vandal fighter makes an action on some project with active admins, they will lose permissions immediately. I think this is a very good protection for abusing the rights. --Millosh 21:09, 1 June 2008 (UTC)

The opt-out doesn't necessarily have to yield a change in actual permissions (although, this would be the ideal scenario), but rather an implicit one. My issue (perhaps I'm alone on this one) is with the ambiguity of the `project with active admins` definition. I am thus suggesting to allow the communities themselves to appraise their situation and decide whether they need the help or not, and then notify Meta of such a decision. Should they decide they're fine on their own, their project would become a no-go for global admins. Otherwise, unsolicited actions could result in less than desirable outcomes, staining what is generally a very good concept for keeping small projects junk-free, allowing them the time needed to build an able community. --Кале 21:37, 1 June 2008 (UTC)

Kale, this is about projects with at most 5-10 admins or so. Such communities are not able to take care about themselves 24 hours. Sr.wp is definitely not one of such projects and SWMT doesn't care about sr.wp; which means that if help is needed for sr.wp, someone needs to explicitly ask (now) stewards to help to the project (like, for example, we had similar situation with it.wp, where admin who was awake was not sure how to make a range block). Also, when you need help, you will not take care if someone is steward or anti-vandal fighter, you will come to ask someone to help, no matter who is that person. And if you really don't want any help, just don't go to #wikimedia-stewards channel. So, for a small project it is very stupid not to be there (if they have a relevant community at all), and for a bigger (like sr.wp is), just don't ask for help and by default nobody of anti-vandal fighters will go there. --Millosh 22:21, 1 June 2008 (UTC)

My comments relate in no way to sr.wp (otherwise I'd be hunting you down at gtalk, not spellchecking my entries at Meta :)), but rather me, expressing concern over what I believe is a far-reaching policy in need of refinement to assure no community feels threatened by the implications it has, which in turn would secure its successful implementation. If your mentioning of sr.wp is fueled by inability to otherwise explain my spurt of commenting here, I stumbled upon the local RC and this caught my eye. I am sorry if I am in violation of some unwritten rules on degrees and dynamics of Meta involvement :) So, if the issue is not whether communities should be allowed to opt-out or not, but merely how, I suggest notice of such an option should be an integral part of the policy. --Кале 22:45, 1 June 2008 (UTC)

Things are very simple: If a community is able to take care about their project, nobody will go there. If a community is not able to take care about itself, then AVfs and stewards will take care about that project. If a community flipped out (like ru.wb was because of one bureaucrat), AVfs definitely will not make any controversial action; it is stewards' job. This group is designed as a group which should support stewards' actions. And, now, stewards are doing exactly the same job with help of other volunteers who are not able to react independently. So, nothing special would be changed. --Millosh 23:06, 1 June 2008 (UTC)

If you are asking if a community which is not able to take care about itself would be able to opt-out: the answer is no; as they are not able to opt-out from stewards' actions. Keeping spam, nonsenses and vandalisms at Wikimedia projects is not acceptable; as well as obstruction of maintaining work by demanding that only stewards may do maintaining on a specific project is not acceptable. --Millosh 23:06, 1 June 2008 (UTC)

And, again, for any project which community is able to take care about it -- the rule is simple: AVfs wouldn't be able to use even a "rollback" permission without explicitly asking the community. --Millosh 23:06, 1 June 2008 (UTC)

Also, keep in mind that the goal is to have mature communities which don't need stewards' or AVfs' help. So, everybody will be happy to see the community mature enough to go out of the SWMT's patronizing. --Millosh 23:06, 1 June 2008 (UTC)

Righty, since opting-out doesn't seem to be an option, shouldn't the policy then at least define:

• a loose number of sysops deemed sufficient;
• that global sysop tools must not be used in an arbitrary fashion, not in content disputes, and not for overriding local communities' or admins' decisions;
• that blocking actions, with the exemption of cross-wiki vandalism, must conform to local blocking policy, if there is any;
• that these tools must not be used on one's home project, unless one has locally been granted sysop status.

I don't think it is appropriate to leave such things to interpretation of vague sentences or perusing of talk pages. The goal is definitely not creating a bureaucratic policy, but one that will unambiguously postulate the essence of this user group through listing what it is, and what it is not intended for. Cheers --Кале 12:22, 2 June 2008 (UTC)

But, your additions are mostly bureaucratic: --Millosh 14:30, 2 June 2008 (UTC)

This is your opinion, which I respect, but disagree with. The fact is that while you may have a clear idea in your head of what the policy should be, that has not been articulated into a clear, non vague set of rules and rationales. IMHO, anyway --Кале 15:44, 2 June 2008 (UTC)

• Number of admins is a very problematic issue. There are well organized projects with 10 admins, while there are not so good organized projects with 15 admins. So, something like "between 0 and 30 active administrators" may pass, but it is a really bureaucratic addition. The other thing is that it is definitely up to a team which deals with vandalisms to realize when some project becomes a mature one. --Millosh 14:30, 2 June 2008 (UTC)

And this can remain the team's prerogative, bearing in mind that no one finds particular pleasure in monitoring more projects than absolutely needed and that the merit of a community's capability to deal with day-to-day vandalism is certainly measured by more than just their admin count, but a ball-park figure in this aspect or, even better, some form of guidelines (this would only help the team optimize its scope of activity thus procuring the greatest degree of efficiency) on the extent of the team's involvement would do miracles in showing this policy as more than just a heap of text serving to introduce a new global user class with little regard to the implications it bears. --Кале 15:44, 2 June 2008 (UTC)

• "... not to work on home projects..." -- Preferably not, in the sense of the rules for stewards (I'll add it). --Millosh 14:30, 2 June 2008 (UTC)

  It is good to known we can agree on something in the very least. --Кале 15:44, 2 June 2008 (UTC)

  Added. --Millosh 15:19, 3 June 2008 (UTC)

• Other of your asks are related to the mature projects: --Millosh 14:30, 2 June 2008 (UTC)
  • A couple of times inside of the text is clearly stated that this group deals just with vandalisms, not with any other kind of issues. If any administrator is present at some project in some time frame, AVf mustn't act if not called explicitely. It may be added somewhere that they shouldn't use their permissions in other ways than to fight against vandalism, but I don't see that as necessary because it is very clearly stated that they will get permissions only for anti-vandalism purpose. Also, all of them need to pass confirmation process every year. --Millosh 14:30, 2 June 2008 (UTC)

  Could you please quote one of such instances where this policy clearly states ”that this group deals just with vandalisms”. I believe not. Hence my suggestion to introduce all that I've stated in the second bullet above. You have chosen not to add any of the items there presented, which frankly I don't understand, seeing as how not even you are claiming they would be allowed to participate in content disputes or take arbitrary actions. Or are you? --Кале 15:44, 2 June 2008 (UTC)

  Something like "Anti-vandal fighters" or, more explitcly: --Millosh 16:20, 2 June 2008 (UTC)

  While anti-vandal fighters should have similar permissions to administrators, their role is not to maintain wikis at the regular basis, like wiki administrators are doing. Their role is to fight against vandals and to allow to the community at a particular project to take care about their own wiki. Because of that, while anti-vandal fighters need and have permissions like deleting pages and blocking users, they don't need and don't have permissions like "Mark others' edits as patrolled", which is generally a feature which every administrator should have.

--Millosh 16:20, 2 June 2008 (UTC)

• I really don't see what is not clear there. --Millosh 16:20, 2 June 2008 (UTC)

  • "... must conform to local blocking policy..." -- no way! Because of:

    You are completely correct when you say it is utterly unreasonable to expect potential AVfs to be acquainted with all blocking policies in existence. No one expects them to, if they deal with cross-wiki vandals or clear issues of vandalism that bear roughly the same sanctions on any project. This is merely another point which would assure no arbitrary actions are taken. --Кале 15:44, 2 June 2008 (UTC)

    Again, they are defined as volunteers which are dealing with vandals; as well as it is explicitly said that they are not regular administrators. --Millosh 16:29, 2 June 2008 (UTC)

    • It is totally unreasonable to demand from one person to be introduced in ~500 policies (do they exist? if exist, what may they do? what number of languages should know one AVf? (policies are not transcribed into English) etc.). If communities around smaller projects are willing to have visible policies, they should write it in English and unify them. --Millosh 14:30, 2 June 2008 (UTC)
    • Again, projects with developed policies possibly have enough of admins. No one of those AVfs will go to en.wp or de.wp or even to much smaller projects like sr.wp is -- if not explicitly asked. (And in the cases like en.wp and de.wp are, they will not go there even explicitly asked.) --Millosh 14:30, 2 June 2008 (UTC)
    • And, the most important, which this your addition makes as a clear example of unnecessary bureaucratization, is that any local admin may revert that block (made during, let's say, night hours) into one according to the local rules. --Millosh 14:30, 2 June 2008 (UTC)

      To care so seemingly little for the potentially harmful consequences unsolicited actions might provoke doesn't appear to be very prudent. --Кале 15:44, 2 June 2008 (UTC)

    • This seems like an important issue. The proposed global sysops should operate under a separate "global" set of policies that define what they can do and when. The global blocking policy, for example, need not be identical to the local policy on any given Wiki. The policy should be conservatively designed, so as to limit offense to local communities.--Srleffler 06:32, 16 June 2008 (UTC)

Finally, since it is becoming painfully obvious this policy is not destined to change, not even in the miniscule of ways, I'm afraid further attempts to do so would be less than fruitful. The best of luck with it --Кале 15:44, 2 June 2008 (UTC)

Of course it may be changed during the discussion, as it was already changed signficantly. However, it can't address paranoia. Also, this is the policy, not the full set of documents around the policy. Nothing was created at once. Even the documents around the Board are far from fairly complete. --Millosh 16:10, 2 June 2008 (UTC)

Alternative idea

Instead of the above, which contemplates projects wishing to actively refuse the services of people with this right, I wonder if there are projects which (though they technically have enough sysops) would be willing for such people to do routine cleanup/anti-vandal work. It might be worth considering having a list of projects that are willing to trust users with this global right regardless of their local supply of sysops - though this may lead to extra confusion for those with this right as to where they are allowed to use it. WjBscribe 09:57, 2 June 2008 (UTC)

Hana mentioned that in relation to the "mark as patrolled" permission, but this means adding a new permission to this group of users (which is not big deal, so it may be added, too). I agree with that possibility. And I think that it is up to a particular community to decide. We should make a separate page (after the policy adoption) with a list of projects which decided so. I expect that we will have more of AVfs than stewards and that they will be able to have in depth communication with all communities. So, this should be one of the first tasks for this group to do. --Millosh 10:36, 2 June 2008 (UTC)

Requirements

The following discussion is closed: Proposal adopted; then changed at #Number of edits and #propose slightly stricter criteria

---

I did not quite get from the text of the proposal: does a candidate need to have more than 100 edits in each of at least two projects, or 100 combined? I mean, does the candidate have to be seriously involved in both? --Yaroslav Blanter 07:52, 2 June 2008 (UTC)

Combined, of course :) --Millosh 09:37, 2 June 2008 (UTC)

I would hope that in practice substantially more experience would been seen as necessary --Herby ^{talk thyme} 14:32, 2 June 2008 (UTC)

Yes, I was thinking about that, too. Maybe, something like 6 months, 1000 edits at all and 100 edits during the last month? --Millosh 14:33, 2 June 2008 (UTC)

Maybe something about "over x wikis" too? There are times I would love these rights (have been playing with an Xrumer bot earlier) however I'm not sure I warrant them & I do wonder about "local" reaction to such people unless it is quite tightly controlled.

In the case of this one I probably would have used the rights but within about an hour all but one of the pages were deleted. However only one block has been placed as a result of my "bot on OP" message so others may see things differently I guess. --Herby ^{talk thyme} 14:42, 2 June 2008 (UTC)

Hm. This is the first global role thanks to global permissions (of course, stewards are the first at all) and this shouldn't be the last. During the next couple of months we may build some other roles, like "bot owner" may be. I asked developers for roles like "user is a bot" (different than a "bot flag") and "bot owner", as well as "delete if I am the only contributor". In coordination of those permissions, bot owner would be able to delete pages created by their bot. So, I hope that it would solve your need. Getting AVf permissions for working with a bot is not a good path. --Millosh 14:52, 2 June 2008 (UTC)

Nope I was tracking a vandal bot not me as the bot - apologies for the lack of clarity. On teh speedy del requests I put the narrative "cross wiki spam bot on OP" hope folk would block the IP as well as delete the page - mostly I was wrong :( --Herby ^{talk thyme} 14:54, 2 June 2008 (UTC)

Oh, OK :) "Over x wikis"... Let's try to analyze: (1) We need an active contributor. (2) We need an active Meta participant. (3) We need a person who is working on at least 2 content projects. So, I'll try to formulate the rule: "... at least 1000 edits at all of which at least 100 edits at all on Meta and 100 edits at all on at least two content projects (per project); as well as at least 50 edits during the last month (if you are applying at August 12th, this means that the last month is July, not the period July 12th - August 11th) at Meta and the same amount of edits at at least 2 content projects (per project)." --Millosh 15:06, 2 June 2008 (UTC)

I added requirements. --Millosh 14:36, 3 June 2008 (UTC)

Knowing if one has global or local rights

The following discussion is closed: JavaScript/skin hacks should be used for the distinction. Global sysops shouldn't be listed at the local Special:Listusers/sysop page

---

Is there anything to indicate to the person with this permission whether their rights on a given project are global or local? I presume they just get the delete and protect tabs as if they were local sysops... Those with rights on multiple projects who are given this permission may need to take care to remember where they actually have local rights and to double check what wiki they are on before they delete/protect/block if the consequences of use on the wrong project will be fairly automatic removal... WjBscribe 09:53, 2 June 2008 (UTC)

Hehe... I woke up one day, went to the English Wikipedia Main Page to see what's new and realized that I have "edit" and "delete" options there. I really don't think that it would be a big deal if someone misused some of those buttons by mistake. Maybe different skins may help: Only projects on which admin rights may be used should have some other-than-default skin or so. I don't know for any other possibility. --Millosh 10:41, 2 June 2008 (UTC)

Sure. They should have a JavaScript hack — VasilievV ² 14:45, 2 June 2008 (UTC)

To answer WjBscribe's question : yes, there is a way; for example, stewards currently have "global sysop" permissions; they do have sysop tools e.g. on en.wikipedia, but they don't appear as local sysops in en:special:listusers/sysop. guillom 13:20, 3 June 2008 (UTC)

Rights removal

The following discussion is closed: Stewards do remove rights immediatelly

---

It says the rights would be removed immediately..stewards don't remove rights immediately. may be admins should be able to remove the rights of them?--Alnokta 13:39, 3 June 2008 (UTC)

Stewards do remove them immediately in case of vandalism. And in case of abuse for AVfs — VasilievV ² 13:42, 3 June 2008 (UTC)

Policy on who can request this rights

Number of edits

The following discussion is closed: Proposal adopted; then changed at #propose slightly stricter criteria

---

Looking through the request policy, it seems that its a bit to easy to get this right..such as

• Sum of edits

  "* at least 1000 edits total (all over the Wikimedia projects)
   * at least 100 edits total at Meta
   * at least 100 edits total on at least two projects (per project)"

that in my point is really really low to request a right which allows you to delete/undelete pages and also Block users. Sometimes private information are deleted instead of and it can be seen by people with this global right. I agree with the 100 edits to Meta but that 100 edits should mainly include mainspace and not userspace but the last one ("at least 100 edits total on at least two projects (per project)") really doesn't make any sense to me, so my proposed change to that will be:

• Sum of edits

  "* at least 5000 edits total (all over the Wikimedia projects)
   * at least 100 edits total at Meta (which doesn't include userspace)
   

and regarding other changes:

1. Having unified account.
2. Being a Administrator, Bureaucrat or CheckUser on a content project"

1. Having a fully merged unified account.
2. Being an active Administrator, Bureaucrat or CheckUser on a content project"

These are just some of the minor changes I will propose for now :) ..--Cometstyles 00:52, 4 June 2008 (UTC)

OK. I think that 5000 edits are not too much for experienced Wikimedians. However, the sense of 2x100 edits (note, not 100 edits at one project) at content projects is to confirm that user is fairly active in cross-wiki matters. --Millosh 01:02, 4 June 2008 (UTC)

Why not 5000 edits at their home wiki(s), 100 at Meta, another 100 across the rest of the projects (ie projects where they do only anti-vandal/spam) and have some additional access somewhere? Here, define a home wiki as anywhere they contribute content and/or have additional access - by this definition I (for example) would have 4 home wikis which don't count towards the "100 across the rest of the projects" count. This ensures that they are active somewhere (their home wikis), active at meta, and active cross-wiki (that "everywhere else" count). Perhaps increase the home wiki edit count and the other-projects edit count. On the other hand, we will be doing RF?s for them, so it's not the end of the world if the number isn't perfect - people will (I hope) be judged more on their merits than their edit counts (though particularly for this edit counts will be an important metric).  – Mike.lifeguard | ^@en.wb 01:21, 4 June 2008 (UTC)

Users with this right need to be supremely trustworthy, given they could go and block an established user on enwp, something which always results in drama and lost contributors. Unless this right is in some way technically limited to exclude certain wikis, I would support a required edit count in the thousands, experience on meta, as well as require that no objections be raised in X days if they aren't a sysop on a major project (eg any of the >300,000 article ones [More than 300,000 articles: Deutsch · English · Español · Français · Italiano · Nederlands · 日本語 · Polski · Português], or Meta). They should also be made known that they sacrifice their local sysop access if they abuse their global access, as both will be removed with prejudice. Daniel (talk) 01:23, 4 June 2008 (UTC)

It wouldn't be fair to demand from a user be an admin of a specific project. But, I support the most of other requirements. --Millosh 09:26, 4 June 2008 (UTC)

Well if they don't have adminship anywhere, then they don't really know how to use the tools, do they?..nah it should be a strict requirement to avoid it being abused even by mistake..--Cometstyles 09:35, 4 June 2008 (UTC)

You didn't understand me... I said that it wouldn't be fair to demand from a contributor to be an admin of German, English..., or Portuguese Wikipedias. --Millosh 09:52, 4 June 2008 (UTC)

sorry but 1000 is really tooooo low, anyone can accumulate that much edits with the right tool, Huggles comes to mind..and as Daniel mentioned, they need to be supremely trustworthy and someone with 1000 edits is either inactive, new or a sock account..neither worthy enough to demand the tool, Millosh there are people with over 40,000 edits on enwiki who are not admins and but whose accounts are very much less than 9 months old ;)...btw, this is a global right and only those involved cross-wiki really have the need for it and basically more than 90% of wikimedians don't even know how many wikis there are and mainly emphasise on their homewiki, voting is probably not the right way to go either with all the canvassing that might happen but its a start, I'll agree with Mike here, 5000 on home wiki is a better idea and atleast 1000 edits wikimedia wide sounds way reasonable compared to the original one...--Cometstyles 03:58, 4 June 2008 (UTC)

5000 + 1000 sounds a good start to me. I'd throw in a preference (did I miss it?) for some reasonable number here on Meta - it would indicate a cross wiki interest? Cheers --Herby ^{talk thyme} 06:41, 4 June 2008 (UTC)

1000 at one content wiki and at least 100 at another (and 5000 total, 100 at Meta)? It would be good to have people who are active at more than one wiki. --Millosh 09:30, 4 June 2008 (UTC)

I have been looking at that '100 edits on two content wikis' - I think quite some of us here who are fairly active cross wiki do have only a main account on one content wiki and here on meta. I feel that it needs a bit of tweaking there. What about: "5000 edits in total, admin here and on a content wiki, considerable work done on the content wiki and meta concerning 'vandalism', a unified account, and a fair number of edits accross a fair number of wikis concerning cross wiki cleaning and no large conflict situations on the cross-wiki part". --Dirk Beetstra ^{T C} (en: U, T) 09:21, 4 June 2008 (UTC)

That sounds good to me, too. --Millosh 09:33, 4 June 2008 (UTC)

5000 edits (home) + 1000 edits (across wikimedia) is very reasonable and yes, those with no vandal fighting background would really have no need for the rights anyways....but it should apply only to wikimedia wikis, and the requirement for the user to be active on Meta per herby is also a really good idea...--Cometstyles 09:35, 4 June 2008 (UTC)

I strongly oppose 5000 edits at home (because even don't have it :). 5000 edits (globally) + 1000 edits (home) + common sense seems to be fine — VasilievV ² 09:38, 4 June 2008 (UTC)

The number should not be carved in stone, it should be met with some reasonability, and if someone has 2 home wikis with each approx 3000 edits, and is admin on both (or other combinations etc.), that should be discussable then. But as a starting point 5000 should be good. --Dirk Beetstra ^{T C} (en: U, T) 09:42, 4 June 2008 (UTC)

{ec) There has to be "wriggle room" here.

There are those who I think most would agree should be allowed to request these rights & Beetstra is certainly one of those in my mind. However we do need to consider the fact that there will be a rush of people who suddenly decide a new badge is the in thing to have (sorry getting old & cynical :)). Getting 5K edits with even popups is easy - it seems some of the newer stuff could get it done very quickly.

I think we must consider the qualitative contribution as well as the quantitative here. They must be actively (currently) doing things that need to tools on multiple wikis to me - I'm not certain I qualify (& feel free to look at luxo). There really are a very small number of Wikimedians that could be considered for this role in my view --Herby ^{talk thyme} 09:43, 4 June 2008 (UTC)

And as a ps I think you have to have 5K edits somewhere --Herby ^{talk thyme} 09:43, 4 June 2008 (UTC)

I think that 5k edits shouldn't be a local, but a global requirement. 1k edits may be a local demand. Note that we are talking now about a lot of edits. --Millosh 10:11, 4 June 2008 (UTC)

(meh & I said I wouldn't edit :)) A point was made up a bit about 3K+3K being ok & that seems an idea BUT there must be quality & quantity across wikis currently (all important words IMO).

5k is no biggy - I have close to 10k on two (today maybe 10k on both :)) and close to 5k on another & I'm not sure I am experienced enough....--Herby ^{talk thyme} 10:17, 4 June 2008 (UTC)

The limit on the home wiki is a difficult one. 5k on en is not a strange number, 5k on a small wiki is something else. --Dirk Beetstra ^{T C} (en: U, T) 10:19, 4 June 2008 (UTC)

Yes, when there are no a lot of articles, you can't make minor edits for edit count; but you have to write/translate articles. It is very easy to me to get 100+ edits per day at en.wp; but, much more difficult to sr.wp (while I have 15k+ edits there, but I am there from the first half of 2004). --Millosh 10:22, 4 June 2008 (UTC)

(If I keep editing this thread enough I'll have 5k on Meta :)). I still say - quantity & quality & currently active - there has to be room for discretion. Reflecting I actually have three 5k wikis (including my original username) & one close to but if I'm not actively working across wikis on something (spamming included) I would not need or justify the rights - I know I have strong feelings about using rights but there it is - if you need them, get them, if you are not using them hand them back. Sadly this is not a commons view among those who actually have the rights --Herby ^{talk thyme} 10:47, 4 June 2008 (UTC)

Well, if you are performing 5k of edits giving sensible thought to this thread, then you certainly earn to be a global admin ;-). I indeed to believe that, like being an admin here, it might be good to have a semi-annual review of the global admins (do they still use the tools, did they not get into major trouble etc.). --Dirk Beetstra ^{T C} (en: U, T) 11:06, 4 June 2008 (UTC)

Annual confirm is already added. --Millosh 11:09, 4 June 2008 (UTC)

Conclusion?

May we try to conclude something? My proposal is: --Millosh 11:02, 4 June 2008 (UTC)

• Recent edits stay unchanged (at least 50 at Meta and two content projects [per project] during the last month). --Millosh 11:02, 4 June 2008 (UTC)
• Total edits: --Millosh 11:02, 4 June 2008 (UTC)
  • at least 5000 through all wikis. --Millosh 11:02, 4 June 2008 (UTC)
  • at least 1000 at one content wiki. --Millosh 11:02, 4 June 2008 (UTC)
  • at least 100 at the other content wiki. --Millosh 11:02, 4 June 2008 (UTC)
  • at least 100 at Meta --Millosh 17:54, 4 June 2008 (UTC)

I think that this is fair. We are searching for cross-wiki editors and the most important number is total at all wikis. It is not reasonable to demand the same amount of edits at the home project and the second one if numbers are high. --Millosh 11:02, 4 June 2008 (UTC)

Added (after one day without comments). --Millosh 11:01, 5 June 2008 (UTC)

I disagree with the edits to Meta requirement, for a number reasons. (a) It's easy to run up a couple of hundred edits here doing nothing terribly useful (voting in polls, discussing inter-wiki links and such), (b) those edits are often not indicative of the level of knowledge we should be looking for (c) it's an additional obstacle that could prevent a few interested users from qualifying and (d) there's no indication what use the edit requirement here, or indeed, elsewhere will actually achieve. They look like completely random, arbitrary numbers. Is someone with those exact number of edits better suited to the AVF than someone who doesn't ? Nick 11:24, 7 June 2008 (UTC)

Do you have some formula for calculating those numbers? If so, please share it with us. As I see, you want to remove number of edits at Meta. OK. Anything else? --Millosh 13:53, 7 June 2008 (UTC)

Removal of an edit count requirement at Meta would be one thing, and the potential to remove an edit count requirement completely, so how about 5000 edits OR 6 months experience on the home wiki, and 100 edits or 1 months experience on another wiki, all of which could potentially be waived if the user has permanent sysop on those wikis (unlikely, but plausible). Edits don't equal experience and I feel it's easy to make the necessary number of edits to qualify for the AVF position without learning anything about the local projects policies and the way things are done around the WMF sites. Nick 00:45, 8 June 2008 (UTC)

That's ok because we have an RFP before they get tools. If they don't know what they're doing they won't pass muster. The edit requirements are just so we can set a lower bound on who may apply to avoid having our time wasted by people who shouldn't even be applying.  – Mike.lifeguard | ^@en.wb 03:23, 8 June 2008 (UTC)

Levels?

The following discussion is closed: Proposal didn't adopted

---

Might I suggest we focus more on a criteria that reflects the type of activity we would expect someone applying for this right to be doing, rather than at pure edit count. What we really want is someone with a history of cleaning up vandalism on small wikis - you don't need sysop rights to start doing that (some of it just needs reverting). Isn't what we're looking for someone who has spent say a month or two actively reverting vandalism on small projects? If the Global rollback permission comes into effect, could we perhaps require that people spend some time using that lesser right on global wikis without incident before they can have this right? Use global rollback as a training ground, and as an indicator that the user is truly willing to spend a reasonable amount of time on small wiki cleanup? WjBscribe 09:45, 4 June 2008 (UTC)

Yes, it is possible. We may make agenda of introducing new permissions to the group. --Millosh 09:54, 4 June 2008 (UTC)

Just because you don't have 5000 edits, doesn't mean its a bad idea ;)...i think people haven't got this idea clearly in their head , we are talking about "Global sysops" (or whatever name is chosen), the ability to be admins on 730 wikis on wikimedia, the ability to block ips and delete pages, this is not something small like Global rollback, this is a very dangerous user right and in the wrong hands can do more damage than good, and having such minute edit requirement is really very silly, this will really create problems on bigger wikis like enwiki, dewiki, frwiki and plwiki and most of these wikis will definitely disagree with this idea, so setting such a "low" requirement is just calling for trouble, I will also like to add a new proposition to the policy i,e,

• It can only be given to those that have been on any wikimedia wiki for over a year and only to
• those users who have never been banned on any wiki.

  these requirements will make sure that it doesn't go into the hands of socks, meatpuppets cross-wiki trolls i.e users banned on one wiki for trolling/vandalism/socking etc....--Cometstyles 09:56, 4 June 2008 (UTC)

I don't think I said anywhere that there shouldn't be a requirement in terms of edits/times served/being a sysop somewhere. What I was proposing was that people should spend some time with the lesser right (global rollback) to demonstrate they can use a cross-project right without incident, before being given the greater level of global access. WjBscribe 10:05, 4 June 2008 (UTC)

We may make some levels: (1) during the first month user has global rollback and something more; (2) during the second, user has something more; (3) during the third user has full global rights (as described at the policy page). --Millosh 10:08, 4 June 2008 (UTC)

(stopping editing here now toooo many ecs!) Comets speaks wisely & to WJBS I did use the word "qualitative" above & I think there must be that. Not totally happy with the "never been blocked" one - if you use Luxo with blocks you will see I've been blocked on two wikis - but it wasn't me honest :) I had to get some imposter accounts cleared for SUL --Herby ^{talk thyme} 10:10, 4 June 2008 (UTC)

Cometstyles did say "banned" not "blocked". WjBscribe 10:12, 4 June 2008 (UTC)

So what's the difference between the two? - Andre Engels 08:51, 12 June 2008 (UTC)

Ok I stand corrected --Herby ^{talk thyme} 10:18, 4 June 2008 (UTC)

Thanks for pointing that out, banned users pose more of a risk but if a user was blocked for small violations like 3RR or minor civilty issues, then its not really a problem :).. --Cometstyles 10:25, 4 June 2008 (UTC)

Personally I would not be very happy with anyone with a block log entry getting cross wiki rights (I'm not saying "don't let them have them" - I'm saying I would not be that happy about it --Herby ^{talk thyme} 10:49, 4 June 2008 (UTC)

As I said, we may make some "transitional period" with introducing less controversial permissions firstly. And about global rollback... We (stewards) don't have a consensus about introducing anything without asking community. So, we are asking the community once (this proposal) instead of a number of times (per permission). --Millosh 10:03, 4 June 2008 (UTC)

Getting blocked when doing cross-wiki clearing is very easy, I have seen someone being blocked after doing cross-wiki cleanup .. if it is banned then indeed that should disqualify for this tool, and large conflicts (outside the home wiki(s)) should be brought to discussion. --Dirk Beetstra ^{T C} (en: U, T) 10:23, 4 June 2008 (UTC)

Guidelines should be written for those purposes. If some global sysop is blocked because of some crazy admin(s) (for example, admins who are treating real nonsenses [so, not articles like "2 is a number bigger than 1 and lesser thatn 3"] as valid articles), global sysop shouldn't lose their privileges, but if blocked because of making troubles, they should. In the first case, they should leave to the stewards to solve the problem. --Millosh 10:31, 4 June 2008 (UTC)

I am certainly a fan of WJBscribe's idea of requiring potential AVFs to have a period with lesser permissions globally (ie global rollback). This has been sort-of done at my home wiki of en.wikibooks, where we have just given patroller and rollback status to someone who is on their way to admin but isn't quite ready. This lets us watch their work with those tools while they gain the necessary experience. Similarly here, we can require that people get global rollback first. Then, provided they behave themselves and do good work and (etc...), they may request more global tools.  – Mike.lifeguard | ^@en.wb 15:11, 4 June 2008 (UTC)

Same here. I think being a global rollbacker is a good start before becoming an AVF. On a side note, what is the difference between a sysop and an AVF? Besides the latter having the rights globally. --Erwin(85) 15:47, 4 June 2008 (UTC)

A local sysop voted by the local community can decide what to delete, some things without needing to have requests for it. An AVF should not decide what to delete on a local wiki but only intervene if there is ongoing vandalism and no local available. An AVF should leave the controversial stuff (like stubs) etc. alone. Best regards, --birdy geimfyglið _(:> )=| ∇ 15:58, 4 June 2008 (UTC)

Fully agree with birdy. Cross wiki work is a sensitive area & needs handling with sensitivity. When I stray onto other language wikis I am very conscious that the links I see as "spam" may not be seen the same way by locals & that I need to tread carefully --Herby ^{talk thyme} 16:06, 4 June 2008 (UTC)

Indeed, but I meant the technical difference. AFAIK an AVF can do all things that a sysop can do, correct? It speaks for itself though that AVF's should only handle spam and vandalism. --Erwin(85) 08:00, 5 June 2008 (UTC)

Conclusion?

May we say something like: "For the period of the first month AVf will get only 'Editing permissions'. After that time, people will be able to vote to oppose a AVf. If there is no opposition for AVf will get full rights. If opposition is voiced, then the AVf may lose AVf status if support falls below 75%. No quorum is required. It is not a vote to gain support status, but a poll to express disagreement with the current situation. The point is not to bug everyone to vote to support the AVf again (if there is no opposition, there is no point in voting your support again. If a AVf is not really strongly infringing rules, but is creating work for the community because of a lack of trust, then it is best that people have the possibility of expressing their opposition." (Mostly copied from the part related to confirmation.) --Millosh 17:09, 4 June 2008 (UTC)

I don't understand what you mean by "editing persmissions" - anyone can edit the wikis already. Do you mean global rollback? If so, I think there will be a process to request that too, so... this will not work as suggested.  – Mike.lifeguard | ^@en.wb 00:30, 5 June 2008 (UTC)

See Anti-vandal fighter#Editing permissions :) --Millosh 06:21, 5 June 2008 (UTC)

So, you mean that someone should request for both permissions? I think that we should make the process easier. User is asking once for permissions, but they have period to prove themselves (it may be one moth, but it may be three months, too; whatever we decide). And AVf has a confirmation process after that period. Note that stewards don't have such conditions for their rights. We are here around a step too far. --Millosh 06:27, 5 June 2008 (UTC)

May we conclude here to add my proposal or someone has a better idea? --Millosh 13:46, 6 June 2008 (UTC)

I think splitting these permission up is a tad silly, and increases bureaucracy unnecessarily. Keep in mind that we will have (hopefully) sane people discussing the potential AVF in an RFP, so there is no need to add layer upon layer of useless bureaucracy. If people wish to have a trial period, then a while with global rollback should be sufficient. With this suggestion, once would get then global rollback, then global "editing permissions", then full "AVF permissions"?!

As a side comment, Millosh, you may wish to stop pushing this proposal so hard. Adding things to the proposal "after 24h with no comments" is a tad pushy. This needs to have a very high level of consensus, which you are not helping by being so single-minded. Please chill out a bit.  – Mike.lifeguard | ^@en.wb 15:00, 6 June 2008 (UTC)

No one said in the previous section anything about the proposal for a day, after very frequent posting. No one said nothing above, until now. As well as everything may be changed if someone disagrees again. There are a lot of potential issues regarding the policy to be solved, so I am trying to make things more efficient. --Millosh 20:56, 6 June 2008 (UTC)

About "levels": I have to say that I didn't understand you what do you want. I don't think that any kind of testing period is needed. However, you said that you want some kind of testing period -- assuming that those persons should be admins before their candidacy, as well as raising requirements for their candidacy. Global rollback is a lesser permission than being a local admin. --Millosh 20:56, 6 June 2008 (UTC)

So, the question is: Do you think that it is really necessary to have "rollback" level before or not? Or, what is your proposal? (Again, I am fine without any change.) --Millosh 20:56, 6 June 2008 (UTC)

General requirements

The following discussion is closed: Proposal didn't adopted

---

Separating the new issue... So, we need a set of "general requirements" like "user is not disruptive", "user wasn't banned [not blocked]" etc. May someone make some wording for that for the policy? --Millosh 10:36, 4 June 2008 (UTC)

My proposal for general requirements is: --Millosh 15:32, 5 June 2008 (UTC)

• Candidate should be technically skilled. They should show that understands issues like: (1) General knowledge of Internet: IP addresses and ranges, open proxies, manipulating with web based and host based tools like "nslookup/host", "whois", RIPE site etc. are. (2) Good (but not perfect) knowledge of wiki syntax. (3) General knowledge in wiki concept and Wikimedia projects. (4) Manipulating with bots would be plus. --Millosh 15:32, 5 June 2008 (UTC)
• Candidate should show that they are trustworthy: (1) Candidate didn't show disruptive behavior. (2) Candidate is following Five pillars in their Wikipedian work or equivalent in their work at other projects (which should be defined). --Millosh 15:32, 5 June 2008 (UTC)

For the technical skills, candidate may show their work or may wait to be asked. Examples for the questions may be: (a) Describe with your own words what would you do if you see that someone made vandalisms from IP addresses 70.70.70.5, 70.70.64.3 and 82.82.90.1. (b) Write a wiki code for table which foreground color is green and background color is blue in such manner that I may see your code clearly. --Millosh 15:32, 5 June 2008 (UTC)

For the trustworthy issues, voters should be able to show examples which are proving that a candidate was showing a disruptive behavior or that candidate doesn't follow Five pillars or similar in their work. --Millosh 15:32, 5 June 2008 (UTC)

Sorry, some of this seems silly to me. Since these users will be doing only simple "antivandalism" work, what justification is there for a requirement about being able to make a table? Equally, some may well be able to serve in this role without knowing detailed info about rangeblocks. And what's the deal with making then write a little essay? No, I think the normal model of granting permissions is fine; this would be rather restrictive.  – Mike.lifeguard | ^@en.wb 20:21, 5 June 2008 (UTC)

The other their role is to help to the communities, including dealing with wiki syntax. By the role, they will be maybe the most important contact between the global community and some small communities. We shouldn't send to some small local community with not a lot of touch with the rest of the community a contributor who is not able to show reasonable level of knowing wiki syntax. Making table is not so hard (it may be copied). --Millosh 20:29, 5 June 2008 (UTC)

So, is it possible to conclude some set of general requirements (not necessarily related to questions) or not? If so, please, propose your version. --Millosh 13:45, 6 June 2008 (UTC)

No. Each person will have their own (hopefully rational) set of ideals against which they will test the candidate. The normal RFX process is fine; we need no further constraints.  – Mike.lifeguard | ^@en.wb 15:02, 6 June 2008 (UTC)

So, [your] conclusion is not to change anything? (I am fine with it.) --Millosh 20:57, 6 June 2008 (UTC)

Voting for candidates

I think that voting for candidates shouldn't be simple "yes/no", but a list of explained reasons why some candidate should or shouldn't be an AVf. Votes without explanation and links shouldn't be counted. Votes expressing only that a voter like or not a candidate shouldn't be counted. Voter has to give all answers: --Millosh 15:32, 5 June 2008 (UTC)

For example, one vote should look like: --Millosh 15:32, 5 June 2008 (UTC)

• Against --~~~~
  • Technical skills:
    • General knowledge of Internet: Candidate showed enough of knowledge.
    • Good knowledge of wiki syntax: Candidate showed enough of knowledge.
    • General knowledge in wiki concept and Wikimedia projects: Candidate showed enough of knowledge.
    • Manipulating with bots: Candidate manipulates with bots very well.
  • Social skills:
    • Disruptive behavior: Candidate showed disruptive behavior at a number of situation [1][2][3][4][5].
    • Following Five pillars: Candidate partially follows Five pillars: Problems with NPOV [6][7][8] and problems with civility [9][10][11].
  • Rationale: While candidate is technically skilled, candidate showed a high level of disruptive behavior and because of that permissions and rights shouldn't be granted to them.

Voting yes/no is a really bad way for giving trust to someone. At the other hand, expressing full position toward a candidate will give to voters much higher responsibility. If they are using lies or obstructive methods for or against a candidate -- it will be prove that they are obstructive, so they wouldn't be able to count on the same permissions in the future. --Millosh 15:32, 5 June 2008 (UTC)

Of course, I added some of the "general requirements". You may add other requirements or make better concept or wording for requirements classification. --Millosh 15:32, 5 June 2008 (UTC)

Similarly here... requesting permissions should never be akin to checking boxes off on a form. Rather we should be discussing things as we do normally for RFXs. This idea has me baffled :(  – Mike.lifeguard | ^@en.wb 20:21, 5 June 2008 (UTC)

Such formalized way of voting should be of some help in passing simple support/oppose options. At least, voters will have to express their position toward a couple of issues. We may model those questions for voters during the time. --Millosh 20:34, 5 June 2008 (UTC)

I agree with Mike, this is getting overly bureaucratic IMO... we don't need this many specific guidelines. RfX's have worked fine for Wikimedia so far. Cbrown1023 talk 23:46, 5 June 2008 (UTC)

Whatever... In 100% of polls I see 80% support/oppose votes without any explanation or even with explanations without a lot of sense. Check, for example, last steward elections. People are voting for their friends and against contributors which they don't like. At some point it should be stopped, but it is obvious that this is not the right time for that. --Millosh 21:04, 6 June 2008 (UTC)

Guidelines

If policy successfully adopted, we need to write guidelines for this role. So, let's start. --Millosh 10:41, 4 June 2008 (UTC)

• AVf should have a typical template at their user page where users should be introduced where to complain about AVf's behavior. --Millosh 10:41, 4 June 2008 (UTC)
  • Impracticle as long as there is no method of unifying userpages on various projects. - Andre Engels 08:47, 12 June 2008 (UTC)
    • You may write a bot for adding informations at user pages at all wikis :) Also, it is assumed that if someone doesn't act as a global sysop somewhere, there is no need for introducing themselves. --Millosh 09:57, 12 June 2008 (UTC)
• We should have such page here. --Millosh 10:41, 4 June 2008 (UTC)
• Some more description around what should be treated as abusing rights (making troubles to a community) should be added there. Also, there should be written what is not an AVf's mistake and how to react in such circumstances (generally, to leave some steward to deal with it). --Millosh 10:41, 4 June 2008 (UTC)
• Don't delete stubs. --Millosh 17:15, 4 June 2008 (UTC)
  • Against. "Don't delete stubs _just because they are stubs_." might be ok (but even so, deleting a one-word article on a project without any users doesn't seem like a bad thing to do). But a rule that would allow them to delete a page consisting of the word "assholes" 200 times, but not one consisting of the word "assholes" 3 times is just plain stupid. - Andre Engels 08:47, 12 June 2008 (UTC)
    • OK, make a better wording for that advice :) --Millosh 09:57, 12 June 2008 (UTC)
• Be careful about treating something as spam. Some cultures are much smaller (than English or German) and something which may be treated as a spam inside of bigger cultures may be completely valid information in smaller ones. --Millosh 17:15, 4 June 2008 (UTC)
  • Disagree. Spam is spam. - Andre Engels 08:47, 12 June 2008 (UTC)
    • • spam is not spam a quick reading of en:Wikipedia:Spam will make it clear that there are cases where what looks like spam is allowed. Now put it in other languages and cultures and it becomes even less clear, so the warning by Millosh is very valid. Vandalism is much easier to identify than spam. Dbiel 14:34, 13 June 2008 (UTC)
        • In practice it is frequently the behaviour that makes some editing "spam". I far prefer "excessive external link placement". Where an IP (or a user) edits a number of wiki (or just one) only placing links which are removed by users whether local of global in perspective then that is "spam" as we speak of it here. If I ever were a global sysop then I certainly would be using the rights on that basis - not lightly but with some experience --Herby ^{talk thyme} 08:10, 13 June 2008 (UTC)
          • I agree that "excessive external link placement", which is only one portion of Wikipedia spam, is an area that GS members can be very effective without the need for much care, but other types of Wikipedia spam do require care and in many cases should simply be ignored by GS users unless they have a high degree of understanding in the specific wiki they are editing. Dbiel 14:14, 13 June 2008 (UTC)
            • Sure - care comes with experience. I currently remove spam on a number of non en wikis etc. I look carefully before I do it. I try & find a local sysop for advice if I am unsure. I've been reverted once out of quite a lot of edits. The role we are looking at here is most certainly not for the inexperienced or unthinking folk. Thanks --Herby ^{talk thyme} 14:26, 13 June 2008 (UTC)
    • I said just "be careful". Some cultures really have market as an inherent part of their society (Kenya is the example). So, it is possible that giving links to the commercial sites with short description may look like a spam, but it may be not a spam. Maybe to reword this? --Millosh 09:57, 12 June 2008 (UTC)
• If you want to use your permissions on larger projects, you may ask the community for yourself or for a general approval for all AVfs. --Millosh 11:03, 5 June 2008 (UTC)
• Content disputes are not your business. You should leave it to the local community. --Millosh 16:29, 5 June 2008 (UTC)
• Trolling is not your business. If some troll disrupts a project without admins, report it to stewards. If a troll is marked as such by the community and community without sysops (or the only sysop is a troll) clearly asks for your help, you may help them. However, in the later case, you have to consult others. Note, also, that the goal in such situations is to have more local admins who are able to deal with such problems. --Millosh 16:29, 5 June 2008 (UTC)
• If you abused your rights your rights will be removed. However, it is very likely that you will get indefinite block at the local project, too. --Millosh 00:55, 7 June 2008 (UTC)
  • That's quite strong. They are not allowed to make mistakes? - Andre Engels 08:47, 12 June 2008 (UTC)
    • This is about abusing, not about making mistakes. See the section #Opt-out and removing rights for some more details about that. --Millosh 09:57, 12 June 2008 (UTC)
• ...

From the English Wikipedia, and information of wikis

The following discussion is closed: The English Wikipedia adopted policy WP:GRU

---

There is a discussion on en: at Wikipedia:Wikipedia_talk:Administrators#New_global_userright. Users agree there that there are enough rollbackers and administrators to deal with vandalism and that timezone is not an issue. So asking the community on en.wikipedia for usage of AVF tools would mean passing the mandatory processes (w:wp:RFR for rollback rights and w:wp:RFA for admin tools). Some are talking of a possibility to opt out too. En: is a special case, but I think that other major wikis will be concerned by this as well. I suppose that at least all major wikis should be informed (I just informed fr:). Cenarium (talk) 02:49, 5 June 2008 (UTC)

Thanks for your comment on enwiki just to inform you"Local projects must be respected. Even though their permissions are global, anti-vandal fighters are not allowed to use their rights on any project with a substantial community of active administrators (e.g. the English Wikipedia) without explicitly asking the community, even for such minor things as using rollback. Anti-vandal fighters not respecting this rule will lose their privileges immediately."see Anti-vandal fighter --Mardetanha ^talk 02:55, 5 June 2008 (UTC)

I am aware of this, as you can see from my comment on en:, "This is pretty clear in the proposal, en.wp is given as an example where the AVF tools should not be used without consent of the local community". I am merely stating facts, I commented here in the hope to discuss the issue further. Cenarium (talk) 03:04, 5 June 2008 (UTC)

I think that it's important to inform the local communities, so that we can have a wider view and bring them in the discussion. I'm new at meta so I don't really know how things work. Cenarium (talk) 03:08, 5 June 2008 (UTC)

Hmm .. I have a bit of a problem with this part of the discussion. Spammers (and I expect vandals) tend to hit the top wikis (mainly because the interwiki links are better for those). So we do get global rights (lets say rollback), and then we can't use it for the biggest part of vandalism/spam because we have to let it be done by locals, as they have enough rollbackers, until we also go through the whole procedure on all those wikis? So then it is just as easy for me to go through all the wikis and ask for rollback on them, and when I have rollback on the top 40 (which probably I will not get on number 35, as I only have 4-5 revert edits there), I ask here for global rollback? --Dirk Beetstra ^{T C} (en: U, T) 10:22, 5 June 2008 (UTC)

Some people at the mentioned page on en.wp expressed positive statement toward giving to this group a rollback permission. So, AVfs will have it, but they should ask such communities for using rights. And I am almost sure that it will pass because it is not a big deal. This policy has to respect developed local communities. Because of that, Meta is not the right place for talking about permission usage on larger projects. --Millosh 10:40, 5 June 2008 (UTC)

In that case we need a multilingual guide here explaining global right, with a boilerplate explanation of why this user has global right (in each language). When acquiring global rollback here, that user has to go to the rollback-request-page on all these wikis, with a formal message (which can then point back to the boilerplate message here on meta) why the user has global rollback, with formal request for admins to allow them to use it (I expect some admins on the e.g. Polish wikipedia to speak English, but the majority may not speak it (sufficiently), nor can I understand replies).

Do we also have to ask all wikis whether they want to be asked on a user-by-user case, and compile lists of where we have to acknowledge and where not? Also, do we have to excempt the wikis where we have to acknowledge from the global rights, as I am afraid that we will make mistakes in the heat of vandalism-revert actions (rollbacking on wikis where we should not, but if I have to revert all these (did not check if I have to!) I am sure I will forget that I should not have used it on one or two ..)? --Dirk Beetstra ^{T C} (en: U, T) 12:06, 5 June 2008 (UTC)

I see this as one of the first issues for AVfs group. Contributors elected as AVfs should organize themselves at the best possible way to avoid endless asks for permissions by every AVf. --Millosh 14:16, 5 June 2008 (UTC)

Some issues should be solved at the beginning of their work as SWMT members: --Millosh 14:16, 5 June 2008 (UTC)

1. To define what precise which project is not active, which needs maintenance during some part of the day and which doesn't need any kind of AVfs activity. Of course, it should be organized transparently, at Meta. --Millosh 14:16, 5 June 2008 (UTC)
2. Finding a way to monitor and measure progress of the small projects. Even finding what some project needs to become a mature one (ok, a number of active admins -- or, better, hours of activity of admins; but how to reach needed numbers?). --Millosh 14:16, 5 June 2008 (UTC)
3. To make all necessary documents related to their work. One of them is a template "I am AVf and you may complain about my work here." which should be put at every user page of one AVf. The other is a document which describes an ask to large projects: which permissions we may use? Etc. --Millosh 14:16, 5 June 2008 (UTC)

It might be a good idea to get input from as many communities as possible regarding the proposed policy, no matter how small or large (maybe run a notification bot, or something like that). It is reasonable to expect not all will approve, but addressing such concerns should help ease the potential introduction of this user group. It would also assure an adequate representation of the global community in voting to adopt this policy (which is only fair) and allow everyone to get familiar with the work these volunteers would do, before they actually get to it. Just a thought, anyway... --Кале 14:48, 5 June 2008 (UTC)

Write such bot for me and ask for permissions to use it at all projects :) I think that this idea is a good one, but not so possible. I was willing to make such tool a couple of months ago, but a number of contributors was against such idea because it would be "dangerous", "spamming" or whatever. There is no reasonable method even for sending messages at all projects. List of Wikimedian pubs (the page started, also, by me) has only 25 listed pubs/village pumps of 700. Plus some of them (like ru.wp and da.wp) have weird methods for adding a comment. Unfortunately, according to present technical possibilities, community may be informed only through foundation-l mailing list. --Millosh 15:39, 5 June 2008 (UTC)

Of course, it doesn't mean that you are not free to inform as many projects as you are able to inform; as well as to organize such effort with other contributors. --Millosh 15:39, 5 June 2008 (UTC)

I think this discussion is unneeded because the vandal fighters should/will work mostly on small wikis with only some and/or inactive admins and not on big projects like en:, de: or fr: because there are really enough admins that can deal with vandalism themselves very easily. --MF-W 18:38, 6 June 2008 (UTC)

Hmm, no, I don't think this is the same, and I think this needs discussion. Yes, vandalism on any wiki should be dealt with by the editors/admins on en. But what AVF should be concerned with is the vandalism on wikis where there are no(t enough) administrators, and with (large/wide scale) cross-wiki vandalism/POV-pushing/spamming (which may seem small on the individual wikis). When possible, the latter should be handled by the local administrators, but when the activities are ongoing, disrupting, and clearly cross-wiki the AVF should have the possibility to perform his actions also on the big wikis, to minimize disruption, and succes of the vandal/spammer/POV-pusher. I therefor hope that the individual wikis are not going to say "no, we don't want to see AVFs here at all", but I hope they are going to say "They should not be using their abilities here without first asking if they can use it, and then only when it is to stop and revert blatant cross-wiki disruption." And then still they should try to let the local community do most of the work (note: even on en there sometimes are posts on en:WP:AN that there is a large backlog on en:WP:AIV, and bots can do a lot of damage in a short time). --Dirk Beetstra ^{T C} (en: U, T) 17:33, 7 June 2008 (UTC)

Technical restrictions?

The following discussion is closed: Opting-out technically adopted in the second proposal

---

It's completely possible that I'm simply overlooking something in the proposal, but is there any way to restrict use of the tools by AVFs on a technical level? While I know that only trusted users and current sysops would be selected as AVFs, it seems that the whole issue could be solved (and a lot of feathers unruffled) if there was a way to allow individual wikis to opt out from even allowing AVFs access to the tools. --jonny-mt ^{en me!} 01:24, 6 June 2008 (UTC)

Permissions are global and, AFAIK, there is no possibility to exclude it technically, except by some hardcoding MW or database. However, all large projects are by default out of this. Usage of the permissions at those projects without community approval will lead to permissions removal. --Millosh 11:34, 6 June 2008 (UTC)

It will need to be made clear to people with this access that any usage on major Wikis, even accidential, will result in indefinite blocks unless it was self-reverted immediately and did not cause any harm (eg. not a block of an established contributor, which always results in drama even if immediately self-reverted). If it was not malicious or deliberate, they could obviously be unblocked when the tools are removed and they promise never to do such again, should they get the tools back at a later date. Most likely, if it can be proved the act was deliberate and made knowing that the wiki was excluded from AVF scope, the user will be considered banned from that project for breaching trust and abusing global tools. I will certainly advocate for such a position on the wikis I am active on, in the event that someone deliberately and knowingly uses AVF tools on the likes of enwp, enwn, and Meta. Daniel (talk) 23:42, 6 June 2008 (UTC)

But, it is related to the local policy. As nobody really thought about policy related to the global blocks (only spammers and open proxies were discussed), it is not possible to add that somebody will be blocked globally. The only action which may be done globally is the rights removal. However, particular projects may adopt some policies (or they don't need because similar policies exist; e.g. admin rights abuse regulation may be good enough for this purpose, too) and it may be added inside of AVf policy that abusing rights at a particular project may result not only with removal rights, but, also, with a local block. But, I don't think that it is a matter of a global policy. If someone abused rights, stewards will remove their rights immediately and local community may block such user before or after rights removal (and abusing rights with removing a block may result urgent action by stewards). --Millosh 23:57, 6 June 2008 (UTC)

Sorry for the confusion; yes, I meant blocked locally, of course. Daniel (talk) 00:06, 7 June 2008 (UTC)

I think that such information should stay inside of the guidelines. Policy doesn't deal with well developed local communities and it is up to the local communities what to do with abusive users in the sense of blocks. So, something like "Note that you may be indefinitely blocked at the local project if you abuse your global rights." should stay inside of the guidelines (and I'll add it now at the section "Guidelines" at this talk page). It may stay inside of the policy, but I don't see a lot of sense: definitely, they won't be blocked by a steward, but by a local admin. --Millosh 00:21, 7 June 2008 (UTC)

And about projects lists: This should be one of the first jobs after the policy adoption. I mentioned above some of the first jobs for AVfs. This should be discussed by the interested communities, AVfs and stewards. --Millosh 00:03, 7 June 2008 (UTC)

Anti-vandal fighter/Wikis. Thoughts? Daniel (talk) 00:20, 7 June 2008 (UTC)

I rearranged your page. Projects without enough of admins are not able to decide. Consensus should be reached about which particular projects are small and which are not. --Millosh 00:26, 7 June 2008 (UTC)

If its Global and if there is no opt-out option, then I believe we would have to make the requirements a bit more" harder" since big wikis like enwiki and dewiki have strong RfA policies and I don't think they would want someone with 1000 edits on enwiki have global rights, since I believe enwiki's policy says 3000...--Cometstyles 00:31, 7 June 2008 (UTC)

I already added stronger requirements. See the section at the policy page. --Millosh 00:35, 7 June 2008 (UTC)

As well as the bottom of the section #Number of edits. --Millosh 00:37, 7 June 2008 (UTC)

Oh great,sorry for not seeing that...:) ..--Cometstyles 01:44, 7 June 2008 (UTC)

Difference between Admin and AVF?

The following discussion is closed: Global sysops wouldn't have the same rights as admins, while permissions are comparable. Also, global sysops would have the permissions at all projects

---

Can someone list the differences in tools between Admin and AVF? Why not just give the AVF the full Admin privileges? Why bother restricting edits to full-protect pages when the AVF can simply change the protection level and then edit? Why bother restricting anything when the AVF can edit user JS files, the most sensitive admin function, with which they can impostor login screens to obtain user passwords? —Centrx→talk • 02:05, 7 June 2008 (UTC)

AVFs are not administrators of local wikis. If a local community decided to protect some page and AVF unprotects it, AVF will lose their privileges immediately. So, editing protected pages is forbidden for AVFs. --Millosh 14:01, 7 June 2008 (UTC)

That should be outside of their scope, anyway. They should be concerned with large-scale active cross-wiki vandalism, which can not happen on a page which is fully protected (except when an admin/AVF would be the culprit, in which case the situation should also not be handled by the AVF, but on 'a higher level'). For all other edits (the good faith ones) they should restrain themselves. --Dirk Beetstra ^{T C} (en: U, T) 17:41, 7 June 2008 (UTC)

If they be focused on vandalism, why should they be allowed to edit user JS files? —Centrx→talk • 19:18, 7 June 2008 (UTC)

Because vandals may use scripts to disrupt the wiki. Also, I think this is not a separate permission, so it cannot be removed without also removing other permissions we clearly want them to have.  – Mike.lifeguard | ^@en.wb 20:03, 7 June 2008 (UTC)

So, then, is the role of AVF solely to deal with matrix vandalism and disruption, or is it to assist in administration on wikis with few or no admins? From reading the proposal, I thought the latter was the case; either way, there are issues.

Cross-wiki vandalism is incredibly hard to identify: how are AVFs supposed to identify such cases? There is no Special:GlobalSearch or Special:GlobalRecentChanges. Vandalism on individual wikis is identified and dealt with, but cross-wiki vandalism can't be dealt with by AVFs unless it's identified, and expecting every single vandalism block to be cross-referenced across all WM wikis is ludicrous. In the case of persistant vandalism which isn't being contained by the application of blocks, which an editor identifies (through whatever means) as cross-wiki vandalism, then a steward can be requested code 3 to apply emergency rights changes in order to combat the threat; indeed, this emergency insurance is one of the main reasons for the existence of the steward class, besides SRP actions on non-crat wikis.

Note: Crosswiki vandalism is not hard to identify... see SWMT, we have an IRC channel that all Recent changes for the small wikis are reported by a few bots, see #cvn-sw. Cbrown1023 talk 00:08, 10 June 2008 (UTC)

In the second case, where AVFs are designed to take on administrative roles in small projects with too few admins, we will be plunging people into projects which they are possibly unfamiliar with, in languages most of which they will not even speak, and expect them to "lend a hand" in performing controversial tasks like blocking, page protection and (mass) deletion. There are going to be huge barriers in communication between local administrators and AVFs, and the "locals" are inevitably going to end up clearing up any unwitting mistakes made in unfamiliar circumstances – after all, it's a lot easier to identify blatant vandalism in English than in Serbo-Croat – which could further add to their workload.

Let's cut the weasel wording – this is global adminship by any other name. What's more, instead of the consensus procedure used in project RfAs, RfAVF will be qualified by a majority voting system like WM:RFA; considering that adminship requests on large wikis can fail with a majority of 80% with enough serious issues raised, and the fact that AVF is a far greater responsibility and has far greater potential to be misused (not to mention the controversy over the usergroup existing in the first place), this has serious potential to go horrifically wrong in many cases. Who's going to keep tabs on the AVFs to ensure that they're not using their rights on wikis where they are forbidden to use them by policy? More importantly, who do they answer to? haz (talk) 10:27, 9 June 2008 (UTC)

The place for complains should be at Global sysops/complain. Serious abuses will be handled quickly by stewards. --Millosh 12:07, 15 June 2008 (UTC)

Mass delete of pages

"As far as the proposer of this policy understands, the number deleted pages is limited. However, if a vandal already made a very large number of pages, anti-vandal fighter should be able to delete them with or without help of a program." - What do you mean by this? As far as I know, if you have the delete right, you can delete as many pages as you want. Do you maybe mean the bigdelete permission which allows you to delete pages with more revisions than $wgDeleteRevisionsLimit? --MF-W 14:28, 7 June 2008 (UTC)

I guess he's suggesting there's a throttle, so you can't delete more than a certain number of pages per unit time. The same is true for rollback on enwiki. You can't rollback more than a given number of edits per hour. --Erwin(85) 14:40, 7 June 2008 (UTC)

OK, but I think there's no throttle for deleting. And what is proposed? A throttle or no throttle? I guess it's the latter. --MF-W 15:05, 7 June 2008 (UTC)

I don't see the sense of this permission except regular delete is time limited. We should find the answer from developers... --Millosh 16:23, 7 June 2008 (UTC)

I think this is referring to Extension:Nuke. I don't think delete has any rate limits, or that avfs need bigdelete--Werdan7^{T @} 17:40, 7 June 2008 (UTC)

May you, please, research this and be sure about the conclusion? If you are sure, that permissions should be removed. --Millosh 18:17, 7 June 2008 (UTC)

There is no throttle on deleting pages. And the bigdelete permission is absolutely not required. However, I think access to Special:Nuke would be a good idea (ie it would have to be installed on all wikis then, as it is an extension). However, I'm not sure that we can decide here to install an extension on all other wikis without a bigger discussion on that. (Though it should be uncontroversial, IMO. It doesn't give any ability sysops do not already have.)  – Mike.lifeguard | ^@en.wb 20:06, 7 June 2008 (UTC)

I removed mass delete from the list of permissions. --Millosh 18:47, 8 June 2008 (UTC)

Why? Having Special:Nuke on all wikis should be done.  – Mike.lifeguard | ^@en.wb 19:01, 8 June 2008 (UTC)

:) I realized that it was the conclusion. I reverted my edit. --Millosh 20:14, 8 June 2008 (UTC)

Hm. I think that this is not Special:Nuke. --Millosh 20:17, 8 June 2008 (UTC)

Sorry, I don't understand you. I'm saying that we should install mw:Extension:Nuke on all WMF wikis, and these folks should have access to it.  – Mike.lifeguard | ^@en.wb 21:09, 8 June 2008 (UTC)

May you add/change [into the policy page] whatever you think that it should be added? If you think something should be added/changed... --Millosh 03:33, 11 June 2008 (UTC)

Small and large wikis

The following discussion is closed: The separate page exists: Small and large wikis

---

Please, take a look at Anti-vandal fighter/Small and large wikis. Maybe the best criteria for classifying wikis into small and large is existence of checkusers. Please, talk here about the criteria and edit page there. --Millosh 15:11, 7 June 2008 (UTC)

There are some fairly large wikis that doesn't seem to have their own checkusers, like fr.wiktionary and zh. and no.wikipdia for instance. --Jorunn 15:56, 7 June 2008 (UTC)

Yes, I am aware of this and it is mentioned that border cases should be discussed. --Millosh 16:16, 7 June 2008 (UTC)

I've modified criterias and generated a list. Please, check if there are wikis which are in the small wikis list but should be in large — VasilievV ² 12:26, 8 June 2008 (UTC)

Shouldent the size criteria (number of articles) be different for different projects, e.g. the albanian wikibooks is the 10th largest (by number of articles) but it hasnt even got 3000 pages yet, while the albanian wikipedia has more than 20,000 articles and is 50th-60th ?--Cradel 15:33, 8 June 2008 (UTC)

I don't think that the number of articles is a good definite criteria, like having CUs are. A project may have a lot of articles, but it may be not self-sufficient (Volapuk case). Having CUs assume at least around 30 active contributors interested in community issues, which means that they have more than 30 very active contributors. --Millosh 18:44, 8 June 2008 (UTC)

And the first example which I found there is Yiddish Wiktionary, which is very far from a mature project. --Millosh 18:52, 8 June 2008 (UTC)

Hm. I realized now that Yiddish Wiktionary has 170 articles. What is the criteria for them to be a large wiki? --Millosh 18:56, 8 June 2008 (UTC)

yi.wiktionary is generous with the sysop rights. I am under the impression that anyone who comes by and revert vandalism or behaves like a friend of the project gets sysops rights, and there is now 51 admins. If there is/was a criteria that says more than 10 sysops=large wiki, that is probably the reason it ended up on the large wiki list. --Jorunn 23:09, 8 June 2008 (UTC)

Wikinews: As a Wikinewsian, I know that out of en, de and pl, there is no any "large wiki" at Wikinews. --Millosh 18:58, 8 June 2008 (UTC)

So, it seems that 10 active admins rule is not good enough, too. I removed "50.000" articles rule, but I will not change anything more there until I hear the rest of you who participated in the page creation. --Millosh 19:05, 8 June 2008 (UTC)

I realized that a very good principle is 50.000 articles and more than 10 admins. However, projects like en.wn don't have 50.000 articles, so such projects should be excepted from the list. --Millosh 10:15, 10 June 2008 (UTC)

Hm. But, en.wn has CUs :) So, the first principle applies. --Millosh 10:18, 10 June 2008 (UTC)

What's the point in arguing over semantics? No one's going to say: "it doesn't matter that you don't want global sysops to work on your project, you don't meet our criteria for being a 'large wiki' so we're going to 'help' you anyway". If a project doesn't want the assistance of these users, then their opt-out is guarranteed (although I doubt any wiki, large or small, would turn down assistance in fighting vandalism). Unless they have opted out, acceptance of global sysops is implied, surely? If a project is not large enough to want to exclude global sysops, they are not large enough to not need extra pairs of hands. Happy‑melon 16:20, 10 June 2008 (UTC)

The point is to find as better as possible rules which may be automatically applied and save our time in analyzing performances of the communities. If some wiki has more than 10 admins or more than 50,000 articles (but, not both) and doesn't have CUs, it has to be analyzed initially (if it is not obvious case, like yi.wikt [large number of admins, very small number of articles] or Volapuk Wikipedia [large number of articles, very small number of admins] are): we need to talk with those communities and realize are they self-sustainable. In all other arguments, I agree with you. --Millosh 17:36, 10 June 2008 (UTC)

Access to global blocking

Since global sysops are created to fight vandalism on small wikis, they need access to Special:GlobalBlock (IP blocks, not installed yet) and Special:CentralAuth (SUL account blocks, now only lock/hide, but there'll be also blocks in future) — VasilievV ² 11:06, 8 June 2008 (UTC)

Not that I disagree, but what is the difference with stewards then?  – Mike.lifeguard | ^@en.wb 17:30, 8 June 2008 (UTC)

Stewards have access to checkuser, oversight and granting/removing of user rights. Nakon 17:37, 8 June 2008 (UTC)

Well now I just feel silly :)  – Mike.lifeguard | ^@en.wb 17:45, 8 June 2008 (UTC)

I think that I said inside of the proposal that AVFs will work at global block with stewards when this feature become reality. --Millosh 18:45, 8 June 2008 (UTC)

Only concern

The following discussion is closed: Requirement changed from "at least 50 edits at Meta during the last month" to "at least 50 edits at Meta during the last 2 months"

---

The only thing I can see where problems would arise would be with this:

Edits for the last month (so, if you apply for permissions at August 12th, this is your sum of edits for July, not for the period July 12th -- August 11):

• at least 50 edits at Meta during the last month
• at least 50 edits on at least two projects (per project) during the last month

Mainly the part about Meta and the "last month" standard. All this will do is cause a rush of users request the permission at the end of the month when they have racked up the needed number of edits. Also, I don't think requiring 50 meta edits is a great idea either; I think we need something to show the user is watching meta, but edits are not a great indication of activity level. To solve the first, I say we stick with 50 edits in the last 2 months for Meta, and for the other two projects, the currently system is fine. Thoughts? Monobi (tŇalk) 22:37, 8 June 2008 (UTC)

I also felt this requirement was not so good but I think this would be a good solution. --MF-W 14:02, 9 June 2008 (UTC)

Agree with Monobi. If I was looking which requirements I had / I had not, the one about Meta was the only one I had not. Though, I am not really active in vandalism fighting so we should add a requirement to check if you're active cross-wiki, in fighting vandalism. SPQRobin 15:50, 9 June 2008 (UTC)

I also agree with Monobi. I'm going to change the proposal. OhanaUnited^{Talk page} 01:49, 14 June 2008 (UTC)

And Cometstyles reverted it. So, is there anyone who does not want that it will be changed? --MF-W 12:28, 14 June 2008 (UTC)

I think that edits on Meta are important because they show the meta activity of the contributor. And keeping small projects means that a contributor should be active at Meta. --Millosh

I am asking Cometstyles to come over and comment his revert. OhanaUnited^{Talk page} 02:28, 15 June 2008 (UTC)

I am sure it was just a minor oversight, there is definitely strong consensus here. I have undone his reversion and Comets will surely comment here. :-) Cbrown1023 talk 03:13, 15 June 2008 (UTC)

Thanks kibble. OhanaUnited^{Talk page} 06:35, 15 June 2008 (UTC)

It seems that I misunderstood requests from this section. I agree with changes. --Millosh 10:59, 15 June 2008 (UTC)

• The only reason I reverted it, I explained on my talk page and since millosh agrees with the above, I'm also for it.. :) ..--Cometstyles 11:07, 15 June 2008 (UTC)

I added more precise definition for Meta (requirements are for the last two months, not for the period of 60 days before asking for permissions. --Millosh

Generally a bad idea

The following discussion is closed: Opting out adopted in the second proposal

---

Asking people to not do something, and then giving them the capability to do it, and then providing them with the easy excuse that they didn't realize what they were doing, is not going to work. Nearly every "admin abuse" complaint comes from the idea that admins CAN do something, but shouldn't. We are not creating a small wiki patrol team, we are creating global admins, regardless of the name you give them, something that the large projects will detest, and the small projects will be overwhelmed by. Don't make this group, please... It just invites admining on projects where people don't know what they are doing, and I am sure this right will be harder to remove than advertised, they always are. Please don't make this group! Prodego ^talk 04:45, 9 June 2008 (UTC)

I totally agree with you, when I first heard about this..I was really against it because I knew abuse is imminent, it will be just a matter of time,but slowly realized that this idea will benefit wikimedia more in the long run, though looking from the POV of bigger wikis like enwiki or dewiki, I would generally find this too be mildly absurd :P ...anyways this will benefit the small wikis more than it will to the bigger wikis, though it does create a sort of a cabal, its generally more beneficial to the smaller wikis in terms of vandalism and spambot attacks which generally gets unnoticed by most people...--Cometstyles 06:23, 9 June 2008 (UTC)

Well, then again, adminship on an existing content project is a requirement for the proposed rights allocation, and potentials would still have to apply via (pseudo-)RfA. However, having a bunch of administrators with what is essentially nothing less than global adminship, and giving them the ability to perform controversial administrative tasks on possibly unfamiliar projects and, in most cases, in completely alien languages, seems crazy. If they have experience in the project and know the language, then why not file a request at SRP like everyone else? haz (talk) 10:27, 9 June 2008 (UTC)

Stewards don't know all Wikimedian languages and they are doing the same job. --Millosh 10:38, 9 June 2008 (UTC)

Stewards however, are some of the most respected users, and have been elected by all the projects, not simply a small group on meta, as these global sysops would be. Prodego ^talk 17:25, 9 June 2008 (UTC)

I understand Prodego's concerns (and expect that there will certainly be 'global admin abuse'), but also agree with cometsyles and haza-w that the net benifit to smaller projects will be substantial. A couple of non-wikimedial projects I fool about with do occasionally have 'lack of admin' type issues. So, I support the proposal with a clear 'deadmin' procedure. --Rocksanddirt 17:36, 9 June 2008 (UTC)

Could it not be made such that projects can opt out on a technical level? That would doubtless provide the advantages, without the major disadvatages. I know this is not currently possible, but I don't see why it couldn't be done. Prodego ^talk 19:56, 9 June 2008 (UTC)

Over at en:Wikipedia:Global rights usage we are working up a model policy to address some of Prodego's concerns. Ideally I would like a technical feature prohibiting AVFs from adminning wikis that opt out, especially because they will have unlogged permissions such as viewing deleted contribs, etc. But if this policy does pass, I'd like a prominent link to the en.wp policy to remind AVFs who might not be familiar with local customs. MBisanz 01:01, 10 June 2008 (UTC)

Yes. en.wp policy should be a good example for other projects how to make a policy for AVFs. So, it should go into the policy, as well as at a separate page which lists all existing policies. --Millosh 10:11, 10 June 2008 (UTC)

Agree, wikis with a custom policy regarding theses users should show them a notice (easy to target with js checking wgUserGroups), preferably with some kind of standarised icon showing what are they allowed to use and what not. Although these would mostly be big wikis where they shouldn't do any action, a mid-size wiki opting out could be problematic. And having to start looking in a foreign langage where do they have the janitor policy (if they have), just to revert an edit, is completely wrong. Platonides 11:15, 11 June 2008 (UTC)

I thoroughly object to technical "opting out" of global groups. enwiki is as much a part of Wikimedia as other wikis. I discussed with VasilievVV the possibility of defining "sets" of wikis on which specific global groups apply — but it is absurd to allow wikis to disallow global groups altogether. Werdna 08:09, 12 June 2008 (UTC)

Generally a good idea

The following discussion is closed: Thanks for the support :)

---

I like this idea and heartily support it! Bstone 02:41, 11 June 2008 (UTC)

Tho perhaps the name "global sysop" is not the best? Can be a bit misleading. Bstone 04:15, 11 June 2008 (UTC)

I don't like that name, too. However, it is the decision for the name. --Millosh 04:23, 11 June 2008 (UTC)

"Global sysop" is better than "anti-vandal fighter", though, as that could be interpreted as someone who fights anti-vandals or is against vandal fighters. :) Scott5114 06:31, 11 June 2008 (UTC)

Yes, better, but I preferred other names, like "nomad" is, for example :) --Millosh 09:34, 11 June 2008 (UTC)

SUL

The following discussion is closed: SUL is needed for a global sysop because of using rights and rights abusing

---

Why should a global sysop have a unified account without unattached accounts? Is this the same for all global groups? --Erwin(85) 07:05, 11 June 2008 (UTC)

Global sysop with username X which at yy.wiki has username Y wouldn't have global sysop rights at yy.wiki. It is, also, applied for stewards, but the main steward's job is at meta (granting and revoking permissions). --Millosh 09:38, 11 June 2008 (UTC)

To Erwin, since I made that change, If is user is not totally Global meaning not all his account is his, then him having a global right will mean he won't be able to use it on those wikis, and it also helps to prevent abuse by users with that name, so if you are fully unified, you can be judged easily for all your actions...--Cometstyles 10:05, 11 June 2008 (UTC)

Opt-out and removing rights

The following discussion is closed: Opting-out adopted in the second proposal

---

There has been some significant concern about this proposal voiced on, at least, the English Wikipedia. I think it would be reasonable to post a bug request asking that developers enable an opt-out for this rights group (and related "levels"). I see no harm in allowing local project opt-out, since the point of the proposal isn't to force admins on projects. The policy of immediately removing rights from users that violate local policies is there - but as others have said, you aren't expecting global sysops to be familiar with all local project admin action policies. How many should they be familiar with? Just the large ones? The large ones, ones with CU, ones with an active community including admins and 'crats even if they are relatively small and no CU?

I'm also concerned that the stewards will decide not to enforce the "immediate" nature of desysopping, particularly in the case of rollback or other minor use in contravention of local policy. Have we had an expression from them of their opinion on this issue, and will this policy (once accepted, if it is) result in a description of this sort of event being added to the steward policy?

I'm prepared to submit the bug request citing the WT:ADMIN page on the English Wikipedia as evidence of consensus that en.wp does not request the services of global sysops/anti-vandal fighters on that project. I'm a little concerned that I don't think objections and problems pointed out on this page have received the right sort of attention - with all due respect to Millosh, his defense of this proposal and enthusiasm in pushing it forward seems to be resulting in less than due regard for local project concerns. Avruch 00:27, 12 June 2008 (UTC)

I think that the need to immediately remove rights is not that big of an issue. Any local admin can block any Goblal Sysop for violations on the local Wiki. Actually local Wikis can technically opt out. It is not a clean as one would like, but it would work. Simply block all Global Sysops locally and require them to have a separate local account if that wanted to work in that wiki. Something like a bot account. The local wiki would need to maintain a separate log clearly indicating that the blocks were for technical reasons of blocking global rights rather than for any violation of those rights. Dbiel 04:21, 12 June 2008 (UTC)

As far as I know, blocking someone doesn't remove sysop rights. So this would hinder people with those actions that aren't the problem, but do nothing against those actions that are. - Andre Engels 08:56, 12 June 2008 (UTC)

Avruch, en.wp adopted the policy WP:GRU related to the global rights yesterday. And, of course, while stewards will not remove permissions if some action was done by mistake, if it was a clear abuse, even for rollback (but, en.wp allowed usage of rollback to global sysops) -- their rights will be removed. BTW, a lot of stewards are participating in building this policy. (As a proposer, I am a steward, too.) --Millosh 05:04, 12 June 2008 (UTC)

At en.wiki though, some "mistakes" result in emergency desysopping. For instance, an en.wiki admin who disclosed a deleted BLP would be emergency desysopped, even if it was a mistake. Also, afaik, if I block another en.wiki admin, they can unblock themselves and continue to block and unblock other users, while remaining blocked themselves. Would global sysops be unable to unblock themselves at the local level? MBisanz 07:46, 12 June 2008 (UTC)

OK, it is obvious that mistakes don't have the same weight. BTW, disclosing BLP may not be treated as a mistake. By mistake may be treated a technical actions which make one process (like, accidentally deleting some page). However, if someone made some systematic mistake (deleting a group of pages or so), even there wouldn't be any intention, permissions should be removed because of technical unreliability. --Millosh 08:18, 12 June 2008 (UTC)

Also, any global sysop will have to follow local rules at the projects which have explicitly defined policies. In the case of en.wp, global sysops will have to follow WP:GRU, as well as all policies which affect permissions which they may use (e.g. rollback policy and similar). --Millosh 08:18, 12 June 2008 (UTC)

And, at the end, as a steward, I really don't want to see any unreliable global sysop. While I am personally always for giving permissions to any constructive contributor, I am, also, very fast in removing permissions to unreliable permissions holders. --Millosh 08:18, 12 June 2008 (UTC)

I appreciate that, but I still see no reason not to allow a technical opt-out for opt-out minded wikis. I think if it were available, en.wp would go that route rather than adopt and enforce the global rights policy. Will the intention of stewards to immediately desysop in most instances of misuse of global rights be documented in the steward policy? Have you considered asking that this particular rights group be unable to take actions while blocked? Avruch 13:32, 12 June 2008 (UTC)

I see opting-out technically as somewhat socially problematic (are we the same community?). However, if there is a significant amount of large projects which are willing to opt-out, it should be implemented. So, the right place for the discussion about opting-out is your local project, firstly. Actually, I don't see any option how to stop, for example, en.wp or de.wp from opting-out technically if the software implementation exists. --Millosh 15:15, 12 June 2008 (UTC)

About the second issue we were discussed at the #wikimedia channel this morning, and I'll repeat what did I say here: --Millosh 15:15, 12 June 2008 (UTC)

1. Removing permissions immediately if someone made a serious abuse of the rights is out of the question: It will be done at the time when the first steward is aware of that. --Millosh 15:15, 12 June 2008 (UTC)
2. There is a possible set of "small abuses" or, better, the situation when a couple mistakes would be made by a global sysops. According to en.wp rules, the third minor mistake/abuse may lead (at least) to the rights removing. For example, if someone didn't use rollback button appropriately three times. In such cases, policy on en.wp states that such global sysop will be blocked until their permissions wouldn't be removed. So, we have a couple of possible options: --Millosh 15:15, 12 June 2008 (UTC)
   1. Stewards remove permissions to the user (steward did it or user asked it). --Millosh 15:15, 12 June 2008 (UTC)
   2. Stewards don't remove permissions (it is possible that some global sysop would be very useful in maintaining small wikis and that it is really stupid to remove his rights because of small abuse or a couple of minor mistakes): --Millosh 15:15, 12 June 2008 (UTC)
      1. Global sysop is indefinitely blocked from editing at en.wp (or any local project). --Millosh 15:15, 12 June 2008 (UTC)
         1. If a global sysop in such case remove their block, this is a clear example of heavy abuse of the permissions, so, the rule one will be used.) --Millosh 15:15, 12 June 2008 (UTC)
      2. Global sysop makes another account at en.wp and uses it as an ordinary user. --Millosh 15:15, 12 June 2008 (UTC)

In all of the cases, en.wp (or any other project) is protected very well from abusing the rights. And it is obvious that any kind of heavy permissions abusing is not a game with happy end for the global sysop who wants to do that. --Millosh 15:15, 12 June 2008 (UTC)

Final proofreading

The following discussion is closed: Finished.

---

So, it is the time to start with the final proofreading. We have two and half days before the voting. Please, read the article again and fix bad wordings, spelling errors etc. (I am not a native English speaker, so I can't be so useful for this task.) --Millosh 08:21, 12 June 2008 (UTC)

The shortcut is "AVF". Should we add another to represent the new name? A minor thing, but just asking :-). — Monobi (talk) 16:39, 12 June 2008 (UTC)

"You can edit". :-) Of course you can add a new shortcut, just use your best judgement. Cbrown1023 talk 17:30, 12 June 2008 (UTC)

Access to undelete

The following discussion is closed: Opting-out technically adopted in the second proposal

---

The answer given to "what about misuse by using the gloabl sysop access on a large wiki" has been "if people do, they will have it removed".

My sole concern given the safeguards in the proposal, is for the actions that can be undertaken for which no trace exists (eg, global sysops will be able to read all deleted revisions, on all wikis, large and small, and this is not usually logged).

Question - can the log be enhanced (I assume there'll be a log) so one can look up all global sysop actions with optional <action type>, <user>, <wikilanguage> and <wikitype>, thus:

All global sysop <actions of any kind> by <User:Example> on <en> <wiktionary>.

All global sysop <protection changes> by <any user> on <de> <wikipedia>.

I think that would be very reassuring. Without this, there's no way to know if any more "silent" options have been misused, or to check a users' entire usage or check for global sysop actions being done on a "large" project. The normal logs only show delete/undelete, protect/unprotect and block/unblock whereas global sysops will have ability to do more. FT2 ^{(Talk / email)} 04:56, 13 June 2008 (UTC)

I think that would be excessive. Not a lot of people will get Global sysops, so I doubt these issues will come up. Monobi (talk) 05:50, 13 June 2008 (UTC)

Why would global sysops need undelete in the first place? I thought they were vandal fighters, they should not be judging if something needs to be restored, merely if its blatant vandalism that needs deleting. MBisanz 08:03, 13 June 2008 (UTC)

For undeleting articles which they deleted (by mistake). I mentioned that a couple of times: When/if the permission "undelete if I deleted" would be made, it would replace undelete permission. (And it stays clearly in the policy.) --Millosh 08:35, 13 June 2008 (UTC)

About logs: Yes, logs should be seen at one place and developers should be asked for that. --Millosh 08:35, 13 June 2008 (UTC)

And, again, about "silent" options: English Wikipedia has more than 1500 admins. I would be happy to see 10% of that number as global sysops, but I don't think that we will have such number in the next year or so. This means that it is not a problem related [only] to global sysops, but to all other admins. --Millosh 08:35, 13 June 2008 (UTC)

I don't really see the problem. Honestly, what's the worst that a global sysop could do with the 'view deleted revisions' right? Werdna 04:24, 15 June 2008 (UTC)

I could swear an admin at en.wiki was emergency desysopped for agreeing at another forum to give copies of deleted pages, oh right, it was User:Everyking. MBisanz 08:46, 15 June 2008 (UTC)

propose slightly stricter criteria

The following discussion is closed: Requirement changed from "being administrator, bureaucrat or checkuser at [one project]" to "being administrator, bureaucrat or checkuser at at least two projects"

---

I propose increasing the requirements from adminship, crat, or checkuser on one project to two. If we're going to be trusting these users to interact with other languages and other cultures, they should already be used to it. This will also help them be familiar with working with different policies and different attitudes across projects. And users with better credentials will better persuade those that don't like editors from other projects passing judgment where they see fit. This will only strengthen the case that these users are trustworthy enough to act on other projects. --DeadEyeArrow 05:51, 13 June 2008 (UTC)

This sounds like a very reasonable requirement especially with the large number of project that exist and which they will have access to with sysop rights. Dbiel 06:41, 13 June 2008 (UTC)

I agree, too. So, let's wait a day to hear what do others think. --Millosh 08:29, 13 June 2008 (UTC)

Personally I think this is a reasonable approach. I guess I might be fussy & say one of the project should be one of the "big" ones maybe. It would be possible to be a sysop on a couple of minor language non wp projects with half a dozen votes (I realise that someone like that probably would not be granted the rights but if you are going to "tighten" it?). --Herby ^{talk thyme} 08:38, 13 June 2008 (UTC)

I suppose that the preference for adminship would be one big project or Meta + another project. But, I think that it should stay as a preference, not as a requirement. "One big project" would mean that a lot of contributors are not in the same position. --Millosh 08:59, 13 June 2008 (UTC)

What's a big project? I don't know. Therefore, I agree with Millosh that it should stay a preference. Being an admin on two projects is a good idea though. I expect all global sysops will already be an admin on meta and thus also on another project, but there's no harm in actually making it a criterium. --Erwin(85) 10:12, 13 June 2008 (UTC)

No adminship on Meta is NOT a criteria and wil never be one, it will just bring a lot of unwanted people on Meta having multiple RfA and most of not all will fail the requirements since we may be forced to strengthen it, permanent multiple-project admin is a good requirement, and by permanent I mean not a temporary one granted by the stewards through Stewards request/permissions..--Cometstyles 12:31, 13 June 2008 (UTC)

I agree, there shouldn't be a requirement that one of the Wikis be a big or any specific one but I did mean for it to be a content wikis. If we narrow the criteria to a wiki or kind of wiki it could lead to problems. --DeadEyeArrow 06:27, 14 June 2008 (UTC)

To require adminship on one big wiki would be a bad idea. Example a user has adminship on 10 small wikis but no big wikis and is already doing GS type work on 10 more wikis; to require him to get adminship on a big wiki prior to becoming a GS is wrong. Granting him the GS tools would make his work much easier. Dbiel 14:23, 13 June 2008 (UTC)

Watching this I'm striking that aspect of my comment - I'm not bothered about it. --Herby ^{talk thyme} 14:36, 13 June 2008 (UTC)

I support two rather than one... I see the reasoning for wanting one of them to be "big" and would be OK with either one on that, but I'd hate to see requiring meta adminship. ++Lar: t/c 02:09, 15 June 2008 (UTC)

Changed from one to two. --Millosh 10:57, 15 June 2008 (UTC)

Candidates should be already administrator

Global sysop should be trusted in wikis. I propose this clause.

• Global sysop candidate should be already administrator(or bureaucrat,CheckUser,Oversighter).

Thank you!--Kwj2772 13:33, 13 June 2008 (UTC)

ahh actually that clause is already there

• "Being a Administrator, Bureaucrat or CheckUser on a content project"...--Cometstyles 13:43, 13 June 2008 (UTC)

Oops. I missed. sorry.--Kwj2772 14:44, 13 June 2008 (UTC)

Define "content project"... is Commons? Is Species? Meta? I'm thinking of the projects in the *.wikimedia.org, and if they are considered "content" projects. Monobi (talk) 16:12, 13 June 2008 (UTC)

Does mediawiki.org count as a content project? --MZMcBride 17:54, 13 June 2008 (UTC)

It should be. You may reword sentences to make it more clear. --Millosh 18:00, 13 June 2008 (UTC)

Okay, I guess if all these count as content projects, then what aren't content projects? Incubator? ArbCom wiki? Monobi (talk) 20:05, 13 June 2008 (UTC)

Incubator is definitely a content project, but ArbCom wiki, OTRS wiki, Internalwiki, etc. are not. Cbrown1023 talk 20:09, 13 June 2008 (UTC)

(un-denting) Okay, so basically a sysop on any public wiki? Monobi (talk) 20:22, 13 June 2008 (UTC)

I wouldn't say that, no. :-) For example, quality: and advisory are public but they are not "content projects". The wording now is probably the best we can get it. Cbrown1023 talk 21:03, 13 June 2008 (UTC)

Optionally, we may list "content wikis" at a separate page. --Millosh 21:07, 13 June 2008 (UTC)

Er, that would be a crazy idea. :-) It would be a lot easier to list non-content projects. Cbrown1023 talk 22:27, 13 June 2008 (UTC)

any wiki with a ".wikipedia.", ".wiktionary." ".wikibooks." ".wikinews." ".wikiquote." ".wikisource." ".wikiversity." in its domain can be classed as a content wiki + a few of those on the ".wikimedia." domain such as Incubator, wikispecies, and above all commons, I don't believe Mediawiki.org qualifies as a "content project" since it doesn't have a big community and most are developers..--Cometstyles 23:32, 13 June 2008 (UTC)

If we consider the wikis listed at Template:Sisterprojects (which are the most well known), then the wikis of the first, second and third row can be viewed as content wikis (of whatever language). But I'm not sure that the others qualify. Meta is a coordination wiki, not really a content wiki, but it may be an exception. Cenarium (talk) 01:29, 14 June 2008 (UTC)

We may rearrange the page Global sysops/Small and large wikis to include more details. There are already enough details there. --Millosh 09:59, 14 June 2008 (UTC)

Please remember that test.wikipedia does not count. Daniel (talk) 17:04, 14 June 2008 (UTC)

There he goes again, crushing my dreams ;-) . Monobi (talk) 22:04, 14 June 2008 (UTC)

I vaguely recall something about a +bureaucrat and Wikispecies... :) Daniel (talk) 01:35, 15 June 2008 (UTC)

Acceptable wikis

So I went through the list ot figure out where sysopship should count towards the criteria.

Content wiki

• incubator.wikimedia.org
• commons.wikimedia.org
• wikisource.org
• species.wikimedia.org
• simple.wikipedia.org

Maybe a content wiki

• beta.wikiversity.org
• www.mediawiki.org
• tlh.wikimedia.org (I can't view the wiki)

Not a content wiki

• wikimania2008.wikimedia.org
• wikimania2009.wikimedia.org
• wikimaniateam.wikimedia.org
• nz.wikimedia.org
• de.labs.wikimedia.org
• en.labs.wikimedia.org
• meta.wikimedia.org
• quality.wikimedia.org
• test.wikipedia.org
• advisory.wikimedia.org
• wikimediafoundation.org
• grants.wikimedia.org
• internal.wikimedia.org
• nostalgia.wikipedia.org
• board.wikimedia.org
• chair.wikimedia.org
• comcom.wikimedia.org
• office.wikimedia.org
• searchcom.wikimedia.org
• chapcom.wikimedia.org
• spcom.wikimedia.org
• auditcom.wikimedia.org
• otrs-wiki.wikimedia.org
• exec.wikimedia.org
• collab.wikimedia.org
• arbcom.en.wikipedia.org
• wg.en.wikipedia.org

Any that I missed or are also unclear? MBisanz ^talk 02:20, 16 June 2008 (UTC)

• Re: tlh.wikimedia.org; er, no... that's a non-exist wiki that was created somehow when we deleted the Klingon Wikipedia... definitely not. ;-) Cbrown1023 talk 04:22, 16 June 2008 (UTC)
• Simple Wikipedia should not be on this list, it's not being questioned... it is a Wikipedia like everything else. Cbrown1023 talk 04:22, 16 June 2008 (UTC)

  I'm not questioning Simple, just that those are some of the different content projects that people might wonder if they are content, and I'm saying they are. MBisanz ^talk 09:28, 16 June 2008 (UTC)

• It is my opinion that if Incubator is a content wiki (which it most certainly is), then Beta.Wikiversity is too. Cbrown1023 talk 04:22, 16 June 2008 (UTC)
• Meta-Wiki is the only one that might be a content wiki. Technically, we have documentation on here and other stuff to write about... but if there is something in the final requirements about Meta-Wiki edit count, we do not need to count it as adminship on content wiki. Cbrown1023 talk 04:22, 16 June 2008 (UTC)

Languages

This question may be out of place, but since this topic is directly related to wikis in all languages, is this discussion being held in the other languages of Meta? or just in English? I do not see many non-english signatures here. (note: I have a very limited knowledge on how Meta works) Dbiel 20:47, 14 June 2008 (UTC)

Losing privileges immediately?

The following discussion is closed: "losing privileges immediately" is not about (a couple of) mistakes, but about the intention or about the systematic mistakes.

---

It seems a bit harsh that they lose their privileges immediately if they use powers on a Wiki with admins. Anyone can make a mistake, especially on something trivial like rollback.--Cato 22:48, 14 June 2008 (UTC)

I tend to think that the reality of applying the policy of immediately removing privileges will be a bit slower than immediately; but the real point is simply the fact that the incorrect use of these powers will not be allowed and will be dealt with swiftly. Dbiel 00:58, 15 June 2008 (UTC)

Furthermore, local policy may mean that differing degrees of severity are used relating to blocking the accounts of users who use their tools, from accidental use to malicious use. Daniel (talk) 01:36, 15 June 2008 (UTC)

Would it be possible to allow local bureaucrats to remove the user's privileges locally without interfering with the user's global permissions? They would not have the permissions on any wiki from which they have been removed from? Thunderhead 08:30, 15 June 2008 (UTC)

No, but see the possible options at the bottom of the section #Opt-out and removing rights. --Millosh 10:05, 15 June 2008 (UTC)

I suggest that we should email inactive admins at least once and give them 2 weeks to respond and to become active again. OhanaUnited^{Talk page} 22:10, 15 June 2008 (UTC)

What happened to Global rollback?

Was Global Rollback absorbed with the global sysop? Personally I'd like to have it over the entire sysop bit... at the moment deleting, etc w/ global sysop is excessive and would go unused for most users, while being able to rollback instead of undo (which is epicly slow) would be great. Monobi (talk) 03:50, 15 June 2008 (UTC)

If there is really need for global rollback, there is no problem in making this policy. But, let's wait for the conclusion of this policy proposal. --Millosh 10:08, 15 June 2008 (UTC)

Bureaucracy

This proposal strikes me as excessively bureaucratic. Why do we need all of these requirements, instead of trusting the community to determine who we can trust with these permissions? Werdna 04:25, 15 June 2008 (UTC)

Which community? Discussion on all 700+ wikis every time is problematic. Discussion here means it's decided by the "meta regulars" ... now we're all a good bunch to be sure, but I suspect that by adding some qualifications/restrictions etc, we won't have someone with 50 edits on some tiny wiki making global admin because 5 of his friends turned up and 3 random bystanders didn't spot the issue. That's exaggerated for effect but I'm thinking that's the thinking. ++Lar: t/c 06:23, 15 June 2008 (UTC)

Sure.. Requirements to demonstrate involvement are good. But that list seems a little long and weird. Every requirement should be obviously attributable as evidence of ability to perform the task at hand. Editing your userspace twice per day on meta wouldn't do anything to indicate your ability, but it would make you meet the 50e/month to meta requirement. --Gmaxwell 22:54, 19 June 2008 (UTC)

And a significant number of voter would vote against such candidate :) It is really not possible to make the perfect rules. The intention is to clearly say that a candidate has to be active on Meta. But, it is true that we may reword it into a less formal construction (something like: "A candidate should show relevant activity on Meta during the last months."). --Millosh 02:13, 20 June 2008 (UTC)

Poll

The following discussion is closed: the poll is prepared

---

I prepared the poll. If something should be fixed, please do it until midnight today. --Millosh

Please be more specific with the time. Midnight today on a post with no time stamp is rather meaningless (time zone and date please) Dbiel 13:55, 15 June 2008 (UTC)

Copied from the poll page:

According to the policy proposal, voting for the policy starts at June 16th, 2008 at 00:00 UTC and ends at June 30th, 2008 at 23:59 UTC.

Dbiel 13:59, 15 June 2008 (UTC)

Hm. Sorry for making confusion. I thought that it is not important to be formally precise at this talk page :) --Millosh 16:04, 15 June 2008 (UTC)

Policy for requesting global sysop status

No problem with this - with the exception of 50 edits on meta (last point). Meta is not a "normal editing" wiki. There are a lot of user, which edit since years, which follow daily what happens on meta, but who edit very occassionally only. On the other hand, you find a lto of user, who just discus everywhere and also here, without knowing what meta is. I think it is a bit problematic. -jkb- (cs.source) 16:32, 15 June 2008 (UTC)

I have also been questioning the meta requirement, but lacking knowledge of who edits here, have been not mentioned it before. If a user has admin rights on several small wikis and has been doing vandalism work on several more but lacks the meta edit count I would think that his history of vandalism work should override the meta edit count requirement. I would even go as far as to question the admin requirement if his edit history supported the fact that he was already doing the work of a global sysop but with out the tools to make it easier. But in this case it might make sense to simply grant him admin rights on one of the wikis he has been active on first, to be sure he was able to handle the new tools properly before granting the tools globally. Dbiel 17:18, 15 June 2008 (UTC)

What about the following change to the policy:

The edit count requirement on meta may be waved, in limited cases, where the user has a extensive edit history of past vandalism work on multiple small wikis.

If some is already doing the work of a global sysop, why force a meta edit count requirement before granting him the tools to do the work faster and easier? I believe that this was a major part of the logic for en.wikipedia making rollback available to non-admins who basicly were doing the same work done by rollback, but the harder way using undo. Dbiel 17:34, 15 June 2008 (UTC)

Being at Meta and reporting vandalisms is a very important part in the process of dealing with vandalism. I don't see housekeeping tasks as tasks which may be done without coordination with others. --Millosh 18:34, 15 June 2008 (UTC)

Please explain in more detail. I can not see the relationship between Meta and reporting vandalisms. I do know for a fact that most if not all vandalism on en.wikipedia is not reported on Meta. Dbiel 19:26, 15 June 2008 (UTC)

Organized efforts in cleaning vandalisms and vandalism prevention has its central at Meta. So, anyone who is willing to get permissions for working on that issue should take part in SWMT before getting permissions. Also, those users are not only vandalism fighters, but global helpers, too. I really don't want to see a global sysop who doesn't know what Meta is. --Millosh 21:46, 15 June 2008 (UTC)

So it sounds to me that what you are really saying is that SWMT membership is a requirement of being a Global Sysop; and if that is the case it should be added to the list of requirements. Dbiel 23:17, 15 June 2008 (UTC)

SWMT is just a preference because it is not so strong Meta institution. --Millosh 23:27, 15 June 2008 (UTC)

How can SWMT be just a preference and also, as you stated above, "Organized efforts in cleaning vandalisms and vandalism prevention has its central at Meta. So, anyone who is willing to get permissions for working on that issue should take part in SWMT before getting permissions." That sounds like a requirement to me. Dbiel 04:13, 16 June 2008 (UTC)

I would add SWMT membership as a requirement, but some time ago (this is maybe still above, maybe in the archives) someone convinced me that SWMT is too informal to be a requirement. And the only measure is Meta. Personally, I would support/oppose nomination in relation to candidate's activity at SWMT. So, just my (maybe not only my) preference; it is not added inside of the policy. --Millosh 16:00, 16 June 2008 (UTC)

Millosh, you are right. But as I stated above: if somebody knows what meta is or not - you cannot judge this from the amount of 50 edits in two months. -jkb- (cs.source) 22:05, 15 June 2008 (UTC)

that is true, I do think 50 edits in 2 months is not enough and those that don't see the relation between Meta and vandalism, are really NOT what we are looking for in a global sysop and enwiki has a big community which can easily deal with vandalism on their own and they don't need Meta's help, but there are 720+ other wikis that might, and Meta is mainly for those wikis ....--Cometstyles 22:19, 15 June 2008 (UTC)

Counter proposal

I have voted against the proposal as it stands, not because of the not-existence of an opt-out, but of the current state and form of the proposal. I do believe that if the system needs global sysops, that they should be global, as the word says.

Yes, I know, some local wikis have other definitions of vandalism/spamming etc., but adding a clear porn domain to the main page is vandalism everywhere (well, main pages are generally protected), as it is probably to almost every other page on every wiki, except for the page of the domain itself. As is uploading an offensive picture by someone who is clearly not a regular editor on the wiki, or creating strongly offensive pages.

Wikis with quite some admins can generally handle these problems themselves, but fact remains, that every now and then there is a post on the english administrators noticeboard that there is a large backlog on administrators intervention against vandalism page (and that is on the biggest and most active wiki), some vandalism is not noted until the cross-wiki aspect is known (this edit is only noted as vandalism after 5 hours on the en wiki, as it looks quite genuine and OK, but if you see the history of cross-wiki edits, POV pushing and use of alternate sites (or without that when there is not yet a new site available to use) by a handful of sockpuppets then the story is different), and performing only 3 vandalism edits on a wiki is per wiki not a reason to block, if the total adds up to 300 cross-wiki edits of exactly the same nature, it is better to have the account blocked on a couple of wikis to prevent further disruption when he hits 10 cross-wiki edits. And if you then first need to contact the appropriate pages on all the wikis, and wait for response ...

I'd like to try and see what happens with a counter proposal:

• Global sysop, that is on all wikis, no opt-out.
• Global rights should only be used when working against global vandals, i.e. vandals that clearly hop wikis as fast as they can load the page on another wiki (and interwiki links are very helpful!)
• For this, the editor who gets this type of rights should have wide support:
  • Only admin votes are counted (i.e. admins who are an admin somewhere on one of the approx. 730 wikis), all editors are allowed to state their opinion.
  • Voting is only closed when there are votes from at least 3 unique admins from at least 15 different content wikis.

Comments/additions? --Dirk Beetstra ^{T C} (en: U, T) 18:54, 16 June 2008 (UTC)

• Has absolutely no chance of going through. Just try to explain en.wp users that admins on some other wps will be able to revert vandaliss on en.wp.--Yaroslav Blanter 20:29, 16 June 2008 (UTC)

• You want 45 admins from 15 different wikis to vote in each selection of a global sysop? These people should just run for steward. Avruch 22:17, 16 June 2008 (UTC)

  This would perhaps be a good way to rethink the role of stewards... but that would rock the boat too much, so forget I said anything.  – Mike.lifeguard | ^@en.wb 03:03, 17 June 2008 (UTC)

Quick replies: Yes, as I explained, even on en with all their admins (and I am one of them), there sometimes is a lag to block people which are disrupting only en, if a global watcher has to first warn to say that there is someone globally busy disrupting, and then wait until he gets a local block, then yes, why not find some people that are trusted enough by the community to perform the tasks globally, and that is why I say that there has to be a very, very wide support, so yes, voters have to come from a large number of wikis, and be trusted users there. If they are going to be global sysop on only the smaller wikis, then why vote at all? Just show your cross-wiki behaviour to the stewards (which are already trusted members), and if they say it is OK, make someone sysop on a handful of smaller wikis.

I am an editor who monitors cross-wiki external link additions, and I do see at the moment that a lot of spammers hit the top 30 (where the global sysops would not have any power in the current setup), and there is at the moment no way to stop them, until they have done quite some damage. OK, global rollback and global blocking would help, but also this, and therefor I propose this counter proposal. Really trusted members with a large backup, who can use their tools everywhere when the disruption is clearly cross-wiki (and only then!). --Beetstra public 11:14, 17 June 2008 (UTC)

Avruch said a good thing here: Such [trusted] contributors should be stewards. However, the problem is that around +10 stewards per year is not enough for the community growth. --Millosh 13:44, 17 June 2008 (UTC)

You may want to check my contribution on a Buryat wikipedia: bxr:Special:Contributions/Yaroslav_Blanter. Note that I am not a sysop there and not a steward, this really took 25 minutes of my time. For the vandal, it took a couple of minutes. With the rollback option, for me it would take 2 minutes too.--Yaroslav Blanter 16:11, 17 June 2008 (UTC)

Edit counts over FIVE THOUSAAAAAAAAND!

I see a few fans of editcountitis put in a hard requirement for 5000 edits. That is a stupidly large number of edits, and it will likely bias global sysop selection toward the English Wikipedia where there are other motivations to amass a stupidly large number of edits.

Edits are free. You get them in any quantity you want by running AWB or TWINKLE. They say nothing about your commitment to the project. You cannot tell anything interesting about someone by whether they have edited five hundred, five thousand, or fifty thousand times.

Please remove that pointless requirement from the policy.

Rspeer 05:53, 17 June 2008 (UTC)

You probably should have more than 5000 edits on smaller wikis, creating a user page on all the wikis will give you a good start. And you should be present in the IRC channels where the smaller wikis are monitored, for at least 3 months. Then you might know what you are dealing with, it is stuff like this (in more than 600 small wikis), and this. If you still want the rights after that you might deserve them. --Jorunn 08:00, 17 June 2008 (UTC)

What are you talking about? I'm not running for global sysop.

Using edit count as a measure of the worth of an editor is stupid and easily gamed. Nobody "deserves" anything just because they've spent a lot of time making small edits to increment a number. Rspeer 18:41, 13 November 2008 (UTC)

One more idea

So, according to discussion at Metapub, I realized that the policy may exclude en.wp; as well as to disallow to people only active to en.wp to vote about it. What do others think about that? --Millosh 08:56, 17 June 2008 (UTC)

I don't think there is any basis on which to exclude members of any community from a meta poll. Avruch 13:19, 17 June 2008 (UTC)

If the policy is not applied to their project, I don't see a reason why should they vote. --Millosh 13:41, 17 June 2008 (UTC)

Of course, if a user is active at some other project, too; this is the other case (activity at, for example, en.wb or en.wn). --Millosh 13:45, 17 June 2008 (UTC)

My point was more that there doesn't seem to be a policy or precedent basis on which to exclude community members based on whether or not the particular proposal will impact them. I think that this sort of exclusion is a bad idea, particularly if it begins with excluding the English Wikipedia community. That'd be a simple extension of the resentment that some of the meta community already feel towards the largest project, and the fact is that every editor of en.wp is as much a member of the WMF community as any editor at any other project. Announcements at en.wiki don't "skew" results unfairly, inclusion of en.wiki voters doesn't "bias" the poll, etc. Avruch 14:11, 17 June 2008 (UTC)

If something is needed to the great majority of projects (more than 700) and only the en.wp community shows selfishness, I don't see a reason why not to go in other way. The situation is not sustainable and if one community is so selfish to block the rest of the communities, I don't see any other option. --Millosh 14:30, 17 June 2008 (UTC)

And if you try to exclude the en.wp community, you're being selfish by trying to force a policy through that will help you, but harm en.wp. Make sure that your policy will not affect en.wp (that is: wait until opt-out is implemented), and most people from en.wp will no longer be interested to vote. And the others will be more likely to be sympathetic to the small wikis. -- Eugene van der Pijll 08:40, 18 June 2008 (UTC)

Of course, in that case policy will not affect en.wp. --Millosh 16:17, 18 June 2008 (UTC)

So, essentially you're arguing that we exclude everyone that doesn't agree with the policy from disagreeing with the policy. Good plan. Wait, what? --slakr 03:55, 19 June 2008 (UTC)

Bad idea, per Slakr. Very very bad idea and a slippery slope to boot. SQL^{Query me!} 04:08, 19 June 2008 (UTC)

Nope. The idea is very precise. If you (people from en.wp) are not willing to participate into the global matters, then others shouldn't suffer because of you. Very simple. Analysis of the poll will be taken after the end of the voting process. If it says that en.wp systematically voted against (unlike others), then I don't see a reason why to include you in any further development of others communities. Of course, if it is not only up to the en.wp community, then it is something different. So, in other words: No, I don't want to exclude anyone who is against the idea, but only en.wp community. --Millosh 05:17, 19 June 2008 (UTC)

Millosh, a global policy, a global group, has to be approved by the global community. That community includes enwiki. Meta is for "the coordination of the Wikimedia Foundation's projects", all of them. People from enwiki made their opinion known in a global matter, right in this current poll, so I think they are willing to participate. Prodego ^talk 06:03, 19 June 2008 (UTC)

A policy which doesn't affect en.wp doesn't need to be approved by en.wp community. --Millosh 06:28, 19 June 2008 (UTC)

So long as it gives users a technical right there, it does. And even if not, it affects the wikimedia brand, which enwiki is a part of, and thus, has an interest in. If you ignore that, you could argue this only affects small wiki's (should it become so technically) but no one from small wikis is going to meet the 5000 edit global sysop requirement. So who exactly would get this right? People from big wikis, where people have made 5000 edits. So there is an interest from wikis like enwiki, dewiki, etc. The exclusion of enwiki editors from being global sysops is completely ridiculous, and probably violates some foundation policy, so I am just going to ignore that. Prodego ^talk 06:36, 19 June 2008 (UTC)

In that case global sysops will not have technical rights at en.wp, of course. About WMF policies: please, give me where it is written and I'll reconsider this proposal. --Millosh 06:43, 19 June 2008 (UTC)

I'm fairly certain the defined scope of meta, per Policy#Breakdown_of_scope, places it on an equal level with all other projects, for the coordination of all projects, also, per Foundation_issues "The "wiki process" as the decision mechanism on content" and "Ability of anyone to edit articles without registering" are final rules. Saying that one project can exclude users of another project, because they tend to have an opinion it doesn't like, would seem to break these rules. MBisanz ^talk 07:08, 19 June 2008 (UTC)

I am not convinced. Anyone may edit, some votes will be counted. I don't see any rule which is against the cooperation between two or more projects. This one policy will consider cooperation between all projects except en.wp. --07:42, 19 June 2008 (UTC)

However, it seems that I need to mention that we are talking now about the second proposal (not about the third one), which still includes en.wp. --Millosh 07:42, 19 June 2008 (UTC)

Whether or not something affects enwiki is your opinion. Decisions that change the power structure and centralization of the entire organization are de facto going to affect every member of that organization in some form or another— period. In most countries, for example, they don't prohibit their lawmakers from voting on legislation that seemingly "doesn't affect them," because that's, frankly, absurd. Disenfranchising a group of people based on your opinion is, in my opinion, dangerous. --slakr 06:38, 20 June 2008 (UTC)

So, you are saying that en.wp community should be able to command to other communities how should they cooperate? Sorry, but, no, thanks. --Millosh 08:02, 20 June 2008 (UTC)

No, but we do have a good article on straw man arguments. Perhaps I need to repeat my viewpoint more lucidly; for, it's fairly simple: as I see it, you're advocating excluding a party from voting due to your personal belief that the outcome of that vote will in absolutely no way, shape, or form affect the party that's being excluded from the decision-making process. Again, I, personally, believe that your logic in arriving at that decision is critically flawed and has no basis in reality. Moreover, if you are not satisfied with how voting is performed in democratic environments throughout the world, I feel that you will continue to find this community frustrating, and you will perpetually arrive at strong disagreement when attempting to alter those mechanics in order to advance your point of view. --slakr 08:21, 20 June 2008 (UTC)

Tomorrow or the day after tomorrow I'll make the analysis of the voting process; so we will have the exact numbers. Things are simple: en.wp community is overrepresented in any multilingual issue because of the fact that English is world's lingua franca. So, if en.wp community behaved much differently than other communities, and, especially, if en.wp community would behave much differently from other communities during the poll for the next proposal (which will address all reasonable comments), then I really don't want to waste my time on dealing with en.wp community. Other communities may live without en.wp community. --Millosh 15:27, 20 June 2008 (UTC)

And about your view of democracy: If you think that democracy is a simple majorization, and if the majorization is the main argument of the en.wp community -- then it is really scary for all others and a very strong reason why should they run away from dealing with the en.wp community. --Millosh 15:27, 20 June 2008 (UTC)

So if I'm reading this correctly, your main problem is with enwiki? Perhaps we should just bar them from all voting, but then what would we do when dewiki would yield its majority? Eliminate them, too? Then what's the next one? And the next? And the next? Eventually we'll get down to only you. Majority or not, if you don't like how democratic communities work, the answer is not to revoke the majority's ability to vote— ever. Well, unless, of course, your goal is dictatorship, then by all means. --slakr 18:32, 20 June 2008 (UTC)

About de.wp: If the other large project do the same which en.wp did, it would be a completely different situation. I am saying here that one project -- whatever the size of the project is -- can't block a process which has a support from other projects. If the community from de.wp behaves similarly as the community from en.wp behaves, then the situation should be seriously considered. --Millosh 03:04, 21 June 2008 (UTC)

And, no, democracy is not a simple majorization and you should know that from your work at en.wp. This is especially true in the situation when the projects are highly independent. If other projects are willing to implement something without en.wp -- it is their right to do. --Millosh 03:04, 21 June 2008 (UTC)

Millosh, you have got to be kidding. How more unwiki can you get? And you're a steward? Excluding a group from participation and voting, the largest wikipedia at that, is totally against what we stand for. I can't believe you proposed this. And what did users do to deserve this? Nothing other than oppose your idea. — Rlevse • Talk • 00:18, 21 June 2008 (UTC)

To say one more time: This would be the option if the second proposal fails just because en.wp community majorization (just voting against or having dumb comments like "too risky" is). And this is a method how to avoid obstruction. Look down, I still see the obstruction: Prodego is arguing that 1 person makes a community. --Millosh 03:04, 21 June 2008 (UTC)

And you seem to be arguing that one rogue steward can decree invasive policy across the entire WMF, no matter how many people from how many wikis object. Do you plan to exclude entire communities from voting, one by one, until the proposal passes? Your behavior and arguments have become increasingly anti-democratic as this debate goes on -- in spite of your claim that you represent small wikis, you responded to the concerns of a user from one such small wiki by openly declaring you know how to run their project better than they do. "Too risky" is not a dumb comment, in the face of naked power hunger, and mentalities like "if you disagree, you can't vote" are rather telling. I appreciate that you care deeply about helping small wikis, but there is considerable disagreement from many reasonable people over whether this will actually help or harm them, and it's past time you recognized that. Luna Santin 04:05, 21 June 2008 (UTC)

I said above: "If the other large project do the same which en.wp did, it would be a completely different situation.". --Millosh 04:18, 21 June 2008 (UTC)

I'm afraid I don't see how. Luna Santin 08:56, 21 June 2008 (UTC)

If not only en.wp community behaves toward the proposal at such obstructive manner, this would mean that we have wider problem about we should discuss. And, of course, in that case, the policy proposal wouldn't have a lot of sense. --Millosh 08:21, 23 June 2008 (UTC)

Tell you what: prove it. Go through all of the votes, both those in support and those in opposition, and demonstrate the editing distribution of the voters. Next, eliminate all of the votes from editors primarily active on enwiki. You'll find something interesting: it'd still fail miserably (because you still have to eliminate the nice amount of support votes from enwiki, too). But hey, it's your proposal; so, by all means— be anti-democratic about the whole thing if you're so convinced the evil enwiki cabal is out to kill your proposal. --slakr 22:23, 24 June 2008 (UTC)

Hehe. There is a very different behavior of the most of en.wp opposing voters and the most of nl.wp opposing voters: The last group voted against because of the lack of communication and explaining the policy proposal them in their language. And it is very obvious that the most opposing persons from nl.wp are constructive. Unlike the most of opposing en.wp voters. There is a significant difference between real problems with the proposal and obstruction. --Millosh 10:32, 25 June 2008 (UTC)

• I don't see where you are going with this, Millosh, or why it should even continue to be discussed (either here in this context, or on the mailing list on the context of one vote one project). It looks like a large number of the later opposers come from de.wp - so should we exclude all of en.wp, all of de.wp, and any other group of people that oppose the proposal? Avruch 19:18, 26 June 2008 (UTC)
  • I am not for the principle "one vote one project". I think I said it clearly at the list. I listed there opinions (as well as at Talk:Global rights) to be discussed (as the Duch guy proposed). Just that. --Millosh 22:50, 26 June 2008 (UTC)

The second and the third proposal

So, I added two next proposals related to the global sysops role: --Millosh 16:34, 17 June 2008 (UTC)

1. 2nd proposal addresses introduction of the technical possibility for opting out. We are discussing now about that proposal. --Millosh 16:34, 17 June 2008 (UTC)
2. 3rd proposal fully excepts the English Wikipedia from the policy. The third proposal should be discussed only if the second proposal fails. --Millosh 16:34, 17 June 2008 (UTC)

According to the discussion at the next section, I want to be more precise: This talk page should be used now for the discussion about the 2nd proposal. The first proposal is discussed at the Metapub and it is too early to discuss about the third proposal. --Millosh 17:08, 17 June 2008 (UTC)

The fourth proposal: let us stop and wait and discus first

Millosh, as I stated somewhere yesterday: slowly it will be a bit difficult to follow the proposals. Everybody who votes now does not know what he/she is voting for. So:

1. stop voting now
2. give somewhere a draft text (may be, the one we are voting for now)
3. state there, that we shall discuss it for one (two, three...) week
4. after this time we shall have not a draft but a discussed proposal, which we can give somewhere to be voted for - if en.wiki should vote as well or not, this will depend on the proposal itself
5. and then we shall vote again, this time with a discussed text (one proposal only)

My suggestion. -jkb- (cs.source) 16:50, 17 June 2008 (UTC)

I wasn't clear, I'll be more precise in the section above. We are in the phase of voting and in the phase of discussing the second proposal. There is no need to wait the end of the voting process. And, of course, I'll announce the second proposal (and the third one for the case if the second wouldn't pass) at all relevant places (the poll section of Metapub, wikien-l and foundation-l). --Millosh 16:57, 17 June 2008 (UTC)

I don't think that the voting should be stopped now. It may give to us a good picture of the present relations inside of the global community. Thus, the next poll may be started between 1st and 10th July or so. --Millosh 16:57, 17 June 2008 (UTC)

I would suggest waiting until opt-out is implemented. Some feature requests take years (SUL!). Until that time, your proposals cannot be acted upon anyway, so why hurry now? -- Eugene van der Pijll 08:27, 18 June 2008 (UTC)

Hm. I don't think that I am hurrying. At the best, I think that the next proposal will be voted through one month. However, there is a number of organizational and other issues which should be addressed this time. So, we should just continue to work on the policy. Nothing else for now. --Millosh 17:05, 18 June 2008 (UTC)

Millosh, I am afraid we do not speak about the same thing. I speak about the proposal to arrange here global sysops. The situation now is that it will not be done. Or do you think that 80 percent of the votes will support this??? Either the first or the second or the third proposal??? No, not. Nobody knows now what he/she is voting for. I just try to rescue the proposal for the future, maybe two or three weeks postponed but then secure. We need a voting which is OK for all. This voting is not OK, it is a chaos. -jkb- (cs.source) 17:07, 17 June 2008 (UTC)

Hm. I agree with your intention. But, let's wait for others to say something about that. BTW, voters are voting now about the current proposal (described at the page Global sysops), as well as for the possibility for introduction of the opting-out. The second proposal should treat opting-out as the implemented feature. And I don't see anything wrong in voting twice or three times. If the third proposal wouldn't pass -- simply, we will not have global sysops; which means that we would have to find some other way for dealing with global issues. Let's say, the community will say that it is not able to take care about itself without the Foundation. --Millosh 17:15, 17 June 2008 (UTC)

• Milosh, I am afraid we have lost. Even if somebody crosses out a couple of dozens of votes of the users who just registered to vote and did not even bother to create a user page, it has no chance of going through. I think we should indeed stop voting and slowly prepare another proposal. This another proposal should have an opt-in option and we are going to opt-in the projects. I would suggest identifying the number of projects (probably around 500-600) which will be interested in the proposal, putting the proposal at their village pumps, and if there are no objections forthcoming, in two weeks declare they have opted in. (If en.wp users will travel to these village pumps voting against, this can be handled by stewards). Then we can vote it here, with the list of opted-in projects attached.--Yaroslav Blanter 07:07, 18 June 2008 (UTC)
  • For opting in option there is no need for voting. Stewards may do that: they are taking care about small wikis (more than 700) and other ~30 wikis may be asked one by one. However, I would like to see are we able to make a global policy. --Millosh 16:35, 18 June 2008 (UTC)
  • As you are the second person who are for closing the poll, I will not say that it shouldn't be done. However, I would like to leave the poll because of the further analysis. If we close the poll now, we will not have the full picture about who supports, who opposes and why they are doing so. --Millosh 16:35, 18 June 2008 (UTC)
  • And, as I see, we are already preparing the second proposal in the sense of discussion about it :) --Millosh 16:35, 18 June 2008 (UTC)

Rephrasing the paragraph on "Permission usage"

I really hate the phrasing of the paragraph on "Permission usage". This is practically unreadable. A rewrite (for opt-in) could be:

The Global Sysop should use his global permissions only:

• If some wiki doesn't have any administrators at all, the Global Sysops should take care of that project all of the time.
• If on some wiki there are no active administrators for part of the time (like the night hours, in a specific time zone), they should take care of that wiki during the unmonitored times.
• As permitted by the local community or local policy. That is, any of the larger wiki's can make its own decision on what Global Sysops are allowed to do.

Even though from a technical perspective, their permissions are global, Global Sysops are not allowed to use their global permissions, even for such minor things as using rollback, on any project with enough active administrators, unless this is explicitly allowed. Global Sysops not respecting this rule will lose their privileges immediately.

Projects that have decided to give some local rights to Global Sysops should report these local rights at Global sysops/Wikis. Projects are encouraged to also have a local page with their local policy: such a page should be in English (or have an English translation). A good example for defining what global sysops are and aren't granted to do locally may be found at w:Wikipedia:Global rights usage of the English Wikipedia. However, such a page is not mandatory: the important thing is to list the local rights at Global sysops/Wikis, so as to have these data available at a central place.

In addition, a Global Sysop should preferably not use his global permissions on his home project (even when this has granted local rights to Global Sysops), unless he is an admin there.

I do not know if this is what is intended, but at least I understand what it says. - Brya 06:15, 18 June 2008 (UTC)

May you rephrase this section from the second proposal? --Millosh 16:36, 18 June 2008 (UTC)

Actually that does not seem possible, as it contradicts itself: it does not make a choice between opt-in or opt-out. The above rewrite is for opt-in. For opt-out it could read:

The Global Sysop should use his global permissions primarily on a wiki that doesn't have any administrators at all (Global Sysops should take care of that project all of the time) or on a wiki without active administrators for part of the time, like the night hours, in a specific time zone (Global Sysops should take care of that project during the unmonitored times).

Even though from a technical perspective, their permissions are global, Global Sysops are limited in practice: all large projects have a possibility to opt-out. At such projects a Global Sysop will have only those rights that have not been precluded by that project. Global Sysops not respecting this rule will lose their privileges immediately.

Projects that have decided to opt-out, in one or more respects, should report the limitations imposed at Global sysops/Wikis. Preferably they should also have a local page with their local policy: such a page should be in English (or have an English translation). A good example for defining what global sysops are and aren't granted to do locally may be found at w:Wikipedia:Global rights usage of the English Wikipedia. However, such a page is not mandatory: the important thing is to list the imposed limitations at Global sysops/Wikis, so as to have these data available at a central place.

In addition, a Global Sysop should preferably not use his global permissions on his home project (even when this has not chosen to opt-out), unless he is an admin there.

I hope this helps. - Brya 06:11, 19 June 2008 (UTC)

Thanks! It is really good that some English native speaker reword this :) --Millosh

In the concept of opting-out technically, there will be the next options: --Millosh 06:40, 19 June 2008 (UTC)

1. Small wikis (full access). --Millosh
2. Large wikis
   • Wikis which didn't opt-out technically and didn't say anything: While global sysops would have technical permissions at those projects, they wouldn't have rights to use them. Large wikis should make a decision (so, opting-in by policy). --Millosh 06:40, 19 June 2008 (UTC)
   • Wikis which didn't opt-out technically and which defined how the global rights should be used (from full access to only one permission [for example, rollback]). At those wikis global sysops will have technically limited permissions, as well as they should strictly follow rules for their usage. Of course, those wikis should define those rules in English. --Millosh 06:40, 19 June 2008 (UTC)
   • Wikis which opted-out technically. At those wikis global sysops would have permissions as regular users. So, it should be mentioned that they wouldn't be able to do anything against rules there. --Millosh 06:40, 19 June 2008 (UTC)

That could read (opt-in, but with technical opt-out implemented):

The Global Sysop should use his global permissions only:

• If some wiki doesn't have any administrators at all (a "small wiki"), the Global Sysops should take care of that project all of the time.
• If on some wiki there are no active administrators for part of the time (like the night hours, in a specific time zone)(also a "small wiki"), they should take care of that wiki during the unmonitored times.
• On a wiki that does have active administrators (a "large wiki"), Global Sysops should only act as allowed by the local community or local policy, as listed at Global sysops/Wikis.

The page at Global sysops/Wikis lists all the projects that have decided to give some local rights to Global Sysops. The page provides detail as to which rights exactly. Projects are encouraged to also have a local page with their local policy: such a page should be in English (or have an English translation). A good example for defining what global sysops are and aren't granted to do locally may be found at w:Wikipedia:Global rights usage of the English Wikipedia. However, such a page is not mandatory: the important thing is to list the local rights granted at Global sysops/Wikis, so as to have these data available at a central place.

Even though from a technical perspective, their permissions are global, Global Sysops are not allowed to use these global permissions, even for such minor things as using rollback, on any project with enough active administrators, unless this is explicitly allowed. Global Sysops not respecting this rule will lose their privileges immediately.

Therefore, Global Sysops are prohibited from acting:

• On "large wikis" which have opted-out technically. At these wikis their global permissions will not work, and they can only do what a regular user can do.
• On "large wikis" which have not opt-outed technically and which have not listed any local rights granted at Global sysops/Wikis. At these wikis their global permissions will work, but nevertheless they are prohibited from doing more than a regular user can do.
• On "large wikis" which have not opt-outed technically and which have listed a limited (partial) set of local rights granted at Global sysops/Wikis, except as provided by this partial set of local rights. At these wikis their global permissions will work, but nevertheless they may use these global permissions only as allowed by the local rights granted. Otherwise they are prohibited from doing more than a regular user can do.

In addition, a Global Sysop should preferably not his global permissions on his home project (even when this has granted local rights to Global Sysops), unless he is an admin there.

Brya 06:00, 20 June 2008 (UTC)

Random notes

• (Any global) policy should have the short form: about what it is, what are the main benefits and how the main concerns are addressed. --Millosh 17:01, 18 June 2008 (UTC)
• (Any global) policy should be presented to all large project. There is around 30 of them. --Millosh 17:01, 18 June 2008 (UTC)
• This means that any policy should have a number of contributors who speak different languages and who are interested in its adoption. --Millosh 17:01, 18 June 2008 (UTC)

TODO

• Finalize the page Small and large wikis. (I moved it to the main space, with the subpage Small and large wikis/Statistics.) It should be announced at the foundation-l; let's say that 7 days for working on it would be enough. --Millosh 17:22, 18 June 2008 (UTC)
• Prepare the small description of the policy for translations. --Millosh 17:22, 18 June 2008 (UTC)
• Prepare the page for ideas for what global permissions should be used. Announce it at foundation-l. --Millosh 17:22, 18 June 2008 (UTC)
• Find interested persons for translating and explaining the policy proposal to the ~30-50 large wikis (around 20-30 languages). --Millosh 17:22, 18 June 2008 (UTC)
• ...

A review of the second proposal

I've taken a look at the second proposal, and I have a number of comments:

1. Most importantly, the proposal should explicitely say that it can only be adopted after the technological opt-out is implemented. I think that it is clear from the current poll that anything else would be unacceptable for most of the opponents of the first proposal. So either postpone a poll on this proposal until the feature request (bug 14556) is closed, or add something to the section "Transitional note" like "If the community votes in favour of this proposal, the policy will take effect as soon as the technological possibility for wikis to opt-out is implemented in the MediaWiki software, and activated on the servers."
2. The intro is still talking about "all Wikimedia projects". Change that to "most Wikimedia projects". I propose replacing the text from "Their role is global... " until the end of the paragraph with "They have administrative permissions on a large number of Wikimedia projects, especially those without enough active administrators. They are allowed to use these rights for vandalism fighting only."
3. Requirements: you can lower these reqs. The 5000 edit criterion was only implemented because this is comparable to the edit count of the average admin candidate at enwiki; if a global sysop does not have any powers there, there is no need for the global sysop requirements to reflect those of enwiki.
4. Permission: remove the part about small wikis. Global sysops may use their powers at all wikis that haven't opted out. I would also remove the part about "partial rights": any wikis that have enough community to discuss these local policies, have enough communtiy to take care of their own wiki. They may allow the global sysops on their project, if they want, but they are not the main target group of this policy, and I wouldn't make this policy and the work of the global sysops more complex because of them.
5. In the section "Permissions" it says that there is a possibility to "opt-out technically from the policy partially or fully". Are you sure about that? I think it's likely that only full opt-out will be possible. Perhaps we should wait with this description until the feature is implemented?
6. The difference between small and large projects is only in the initial status of the projects, so you can move the details about small and large wikis to the adoption section: "When the policy is adopted, global sysop privileges will become available at small Wikimedia projects, see Global sysops/Small and large wikis for criteria and a list of small projects. Large projects are assumed to have enough admins not to need assistance of global sysops, and they will be opted-out of the policy by default. Projects may decide to change their opt-out status at any time."

I hope these comments are useful. -- Eugene van der Pijll (m) 12:25, 20 June 2008 (UTC)

Yes and thanks. I agree with all comments except the one about requirements (3) (actually, I was thinking to add some of the points which you mentioned, before). Requirements are discussed a lot during the preparation of the first proposal and it seems that the majority is unhappy with all proposals :) So, we should find a way how to decide about them... --Millosh 15:44, 20 June 2008 (UTC)

Hm. And about the size of the community: I think that it would be good to define a way how to opt-out (for smaller communities). Procedure for the CheckUser election seems almost ideal to me and I think that it should be implemented here like: "The community may opt-out if at least 30 active contributors ["active contributor" should be defined] voted in favor of the opting-out in the proportion defined by local policies for the qualified majority (it may vary between simple majority up to 85% majority) for the most important community decisions (like defining important new policies is). If such policy doesn't exist, majority of 80% would be needed for technically opting-out. The same procedure is needed for any large project for opting-in by policy." (Actually, the first proposal was, also, opt-in by policy.) --Millosh 15:44, 20 June 2008 (UTC)

So, I think that it would be a good idea that you add all other changes into the policy proposal (as you think that it should be worded). If anyone objects, it is not so hard to change it. --Millosh 15:44, 20 June 2008 (UTC)

I think that any community that wants to opt out, should be allowed to opt out. So if 1/1 users wants to opt out, that wiki should be opted out. I would propose that lack of consensus for having global sysops should be enough to opt out. Prodego ^talk 17:52, 20 June 2008 (UTC)

One user is not a community. Need for 30 users is a need for a sustainable community which doesn't need help from anyone. Also, this proposal is "opt-in" (from the first version) and we are introducing now opting-out technically. While opting-in is a serious issue for one community, opting-out technically from other communities is, also, a very serious issue. So, both decisions should have significant majority (at least, a defined majority [or decision-making process] at a local project; AFAIK, you at en.wp don't need to vote about a proposal). --Millosh 02:44, 21 June 2008 (UTC)

• This is an improvement on the original, which I opposed. I could support this. giggy _(:O) 08:58, 23 June 2008 (UTC)

Userrights

There is a presumption being made here that (I think?) may be being overlooked.

That of a "global user".

So (at the moment), are all Sister project userrights "packages" the same for: "anyone", "user", "autoconfirmed", "sysop", etc.?

What about global bots?

There's a proposal "somewhere (I recently read) suggesting that all checkusers automatically become global checkusers.

I think it's probably not a good idea to have both global sysops and local sysops. Sysops should be the face of Wikipedia (last I recall). And with SUL, a sysop should be able to help whatever, whereever.

Though, to be honest, I thought the whole point of global permissions was damage control (or even being proactive concerning damage control).

If we're going to combine damage control with helping out the small wikis, then we should give this more thought.

The trouble (as I see it), is: each project has their own "policies" to trip over, and of course the language barrier.

So we could have:

1.) "global" sysops with access to all media wiki wikis (the current proposal)

2.) "global" sysops with access to all sister projects of the language which they are granted access to.

3.) "global" sysops with access to all language wikis of a specific sister-project.

I think #3 may only be useful in a small number of cases.

And I think that #2 makes a heck of a lot more sense than #1.

And really, if #2 (and possibly #3) were to be implemented, we would still have something rather close to #1, to deal with such particular situations, they're called stewards.

I still think SUL is a great idea, but the whole userrights question, especially when concerning what a "package" of userrights should be, is something that really needs discussion. Things just look like they're moving more than a bit too quickly. - Jc37 04:31, 24 June 2008 (UTC)

Deleted pages - issues concerning them

Although this proposal sounds like a good one (I myself can't actually get it working on my localhost MW install) - the only problem is, would it be considered an abuse of the system if a global sysop undeleted a page that was deleted as the result of a PROJECTNAMESPACEHERE:Votes for deletion/Articles for deletion etc. and then moved it with full edit history to their own wiki, then re-deleted the page once the GFDL was satisfied??

I wonder if this could be seen as being bold per the English Wikipedia's policy, or as wheel-warring??

There would have to be some limitations to this, but this is an issue to consider. Thanks, AP aka --Kelsington 18:28, 8 July 2008 (UTC)

I don't actually see what the problem would be; an AfD-type discussion is to delete the page from that project, not to delete the content from the entire WMF system. However, I don't think global sysops should be using their undeletion abilities without at least some commentary from the community. EVula // talk // ☯ // 18:57, 8 July 2008 (UTC)

The actual problem is of sysops undeleting pages on a particular project, then re-deleting them again without consent, or at least, the approval of the community. I wasn't implying the deletion from the entire WMF system of pages. Thanks, AP aka --Kelsington 18:59, 8 July 2008 (UTC)

Well, there are two things right there: the undeletion, and the redeletion. The redeletion is a non-issue; in the scenario presented, there was clearly a reason to delete it, so there's no reason for it to not remain deleted. That just leaves whether undeletion is proper or not. The situation outlined clearly specifies that the article is being undeleted solely to be transwikied, meaning that the net effect on the initial project is none, while there's a net gain on the receiving project; furthermore, the transwiki preservs the GFDL information. So ultimately, we just need to specify whether global sysops can undelete to transwiki, which I think is quite reasonable in this sort of situation (though a warning that it shouldn't be done willy-nilly is a good idea; perhaps restricting undeletion to just transwikis or user requests would be a good idea).
Keep in mind, however, that global sysops are only going to be active on projects with small communities, which may or may not be big enough to have a valid deletion process anyway. :) EVula // talk // ☯ // 19:10, 8 July 2008 (UTC)

The actual issue was them using their powers on major projects (e.g. Wikibooks, Wikiversity etc.) rather than smaller ones. Well, in theory anyway. Thanks, AP aka --Kelsington 19:12, 8 July 2008 (UTC)

Well, larger projects will be able to opt-out of the process entirely if they don't want them. However, if someone were to create a page on the English Wikibooks in the wrong language and it was deleted, I think it would be reasonable for a global sysop to undelete it, transwiki it to the proper language, and then re-delete it. EVula // talk // ☯ // 19:15, 8 July 2008 (UTC)

Though this would generally not be controversial, it does depend a bit on why the page was deleted and what project it is proposed to be moved to. Ideally, if the page belongs on another project, the deletion discussion would have been closed as transwiki. If the global sysop is knowledgeable about the inclusion criteria of the project they plan to import it too, I guess them going ahead and doing it anway would be OK, but people often assume that material is acceptable o another project that isn't - e.g. when suggesting a trasnwiki to wikisource for example overlook the prohibition on original research, or the need for it to be a complete source. There can also be incompatible licenses - e.g. material cannot be transwikified to Wikinews which uses a CC license attribution Wikinews, rather than GFDL crediting individual contributors. The global sysop really needs to know what they're doing so it would probably be best to have a discussion before doing this in any event. WJBscribe (talk) 22:33, 18 July 2008 (UTC)

• I do like the idea of global sysops. Maybe we should consider adding import and transwiki as part of the tools global sysops have. The probably bigger issue is a global sysop deleting a page against consensus, where there was a clear consensus at the local AfD/VfD page, and then wheel-warring to keep it. Hopefully such a thing will never happen. --Kelsington 19:19, 8 July 2008 (UTC)

I should add that opt-out of the global sysop proposal would probably let the internal wikis (e.g. internalwiki, otrswiki, langcomwiki, and maybe those like the Pennsylvania Wikimedia chapter wiki) be excluded from it. I can't really see any need for global sysops on those, but, WMF-wide, it's probably a good idea, especially for new projects (as and when WMF creates them, which is probably happening right now). That's my 0.02 cents on it. Thanks, AP aka --Kelsington 19:22, 8 July 2008 (UTC)

I honestly can't think of a scenario where a global sysop overriding community consensus is justifiable, outside of copyright violations. EVula // talk // ☯ // 19:26, 8 July 2008 (UTC)

While this is going to be a rabidly unpopular opinion, I think that the global admin group should perhaps leave copyright infringement situations up to the stewards and local community to deal with. Make a very wide, bright line between obviously acceptable global admin actions (reverting obvious vandalism and blocking the vandal, for instance) and those which may cause harm to both the image of the global admins and their ability to perform their function. If I post a nice long article from another source in a language you're unfamiliar with, but you find it online, then how do you know it's actually a violation? What if the contributor is the person who wrote the original text? Perhaps the text included a license but we simply couldn't read it... like I said, I'd rather the community or stewards deal with the repercussions of that sort of situation. The global admins will be plenty busy anyway. Kylu 00:07, 3 August 2008 (UTC)

• That I agree with. However, I have seen on en.wikipedia some local Arbitration requests over this (e.g. the notorious Daniel Brandt wheel warring incident) etc. However, I can't see the need for the global sysops on internal wikis, or the local chapter ones. Thanks, AP aka --Kelsington 19:28, 8 July 2008 (UTC)

Opt-in and group rename

Okay, so obviously, "Global sysops" is no longer a correct name for the group, as we have both the desire to limit these users from sysop abilities on projects that don't want them assisting and the technical ability to enforce it using wiki sets.

So, let's say we create the group (we'll need to decide on a new name probably) and make a large wiki set of projects with no administrators.

Next, we make the group apply only to those projects and allow (optionally) projects with administrators to opt-in if they'd like. I know of a few small projects that would probably welcome roving administrators who can do uncontroversial admin tasks.

I can't see anyone arguing that the group would have no merit, in that case. Projects can opt-in and opt-out whenever they feel like it, we have a large pool of potential helpers, and the various backlogs are obliterated.

Any opinions? Kylu 00:01, 3 August 2008 (UTC)

For me sounds an good idea if we can give all wikis ability of opt-in and opt-out .specially the projects who has administrators--Mardetanha ^talk 00:15, 3 August 2008 (UTC)

• No more voting for new names, that was a failure, and just like all the other global names, we should leave it to the stewards to come with a name which is more neutral and will not make it seem like steward-lite and a name which the enwiki community can not complain about XD XD, so looking at the last votings, the possible names can be "Janitor", "nomad", "Anti-vandal fighter" and "Cross-wiki maintenance", you choose..Good luck :P ..--Cometstyles 00:20, 3 August 2008 (UTC)

Wait, you don't like "Steward Lite: Same great taste, less power." ? Oh well... "Cross-wiki janitor" sounds good to me. Kylu 00:45, 3 August 2008 (UTC)

Edit counts: Why?

Why does this policy now include several hard requirements for edit counts? As I said above, edit counts don't indicate anything about your contribution to the project. All I got was a nasty response from Jorunn that I was trying to be a global sysop and didn't "deserve" it.

I'm not running for global sysop, and I'm not trying to lower the barrier to becoming one. I'm just asking that this policy be based on something real, like whether the candidate is a good, consistent, and level-headed contributor to the project, not how many thousands of times they've edited. There's no way to measure whether someone "deserves" to be an admin, and if there were a way it certainly wouldn't be counting edits.

I propose removing the list of edit count requirements from this policy. When evaluating someone's request to be a global sysop, we can look at the quality of the edits they have made, instead of how many of them there are. Rspeer 18:51, 13 November 2008 (UTC)

People like hard limits: Saying that a user has to have 5000 edits or something, as set out in a cold, unfeeling document on a policy page hidden in the darkest recesses of the wiki makes them feel personally exempt from responsibility in the event that their choice turns out to be a lemon. If you elect someone and it turns out to be a vandal, you get to say "Well, he qualified by numbers!" instead of admitting that your judgment is at fault. Ideally, all wiki processes and elections should be true consensus, weighing the editing and use of rights of the individuals in determining whether to supply them with such additional abilities. We have lost both the ability and desire to review people minutely, however: The sheer overwhelming numbers of edits many editors have quashes these.

I've considered proposing a minimum number of adminships on other projects to be eligible for global adminship, but that may well not be in our favor. Currently, a prerequisite for adminship on Meta is adminship on another project. This is another example of a hard limit, but one that has its own peculiarities. Requiring a minimum number of adminships on other projects opens the way for promotion of the abuse of smaller projects (where it takes less actual work to attain such adminships, typically) and advances the concentration of "power" (as userrights). While no single userright grants a editor inherent authority above and beyond those of other, not similarly button-blessed editors, it does cause a disparity in actual authority when other, less experienced editors assume them to have such authority.

Perhaps we should consider a "wiki-reputation voting" system, where each person has some visible gauge to assist other editors in determining the perceived usefulness and authority of their fellows? :) Kylu 20:05, 13 November 2008 (UTC)

Compare the requirements for stewards to the requirements for global sysops. This is ridiculous, and I'm removing the requirements pending further discussion.  — Mike.lifeguard | ^@en.wb 18:06, 14 November 2008 (UTC)

Excellent work. :D --MZMcBride 18:17, 14 November 2008 (UTC)

Well done, Mike. OhanaUnited^{Talk page} 17:47, 15 November 2008 (UTC)

I was starting to suspect that the minimum requirements for global sysops were to avoid granting anyone the access. :) Kylu 22:35, 15 November 2008 (UTC)