Talk:Global sysops/2009

Appointment section

It isn't very clear. Is this going to be something like requests for global rollback where the stewards will vote and allow comments from anybody? Or will it be more open and the weight of opinions from stewards and "regular" users be more equally balanced? Otherwise, looks good. - Rjd0060 14:50, 27 July 2009 (UTC)

Because we are talking about global sysop, I suggest global sysop candidate should get 80% of support, should have 25 more supports than opposition. In short, candidate must meet (support)>={(oppose)+25} & {(support)*100}/{(support)+(oppose)}>=80. It is a little higher than that of medium-size wikipedia. If only stewards opinion would be reflected, I will  Oppose. Kwj2772 (msg) 15:12, 27 July 2009 (UTC)

I wasn't really sure about the appointments section, so I deliberately left it obscure. I was thinking, however, that it would be great if we could make it not-a-vote. Instead, it would be more like an enwiki AFD discussion, where people would bring up support/oppose votes based on things that matter towards global sysops – Number of cvn edits, time spent at cvn, history of adminship use or misuse elsewhere, etc. – rather than having a vote system, where it could easily be gamed by allowing people with grudges from local project politics to ruin a RfGS. A steward could simply analyze consensus at the end and decide whether there is enough trust from the comments that bring up valid reasons only to add someone to the GS group. What do you guys think of that idea? NuclearWarfare 15:40, 27 July 2009 (UTC)

Sounds good to me. People holding grudges have disrupted enough votes already, afaic, and I think stewards are perfectly capable of judging the capacities of the candidate in question. Wutsje 15:59, 27 July 2009 (UTC)

I have a little problem with having a vote directly on SRG. I'd like the vote to be placed somewhere else, so that SRG and the other Steward request-pages are (hopefully) only requests that can be done as soon as a steward sees them... Laaknor 20:42, 9 August 2009 (UTC)

But the process should be similar to global rollback requests one. --Nemo 06:58, 11 August 2009 (UTC)

Who then is qualified enough? The appointment of sysops should be after the certification of the knowledge and ability of the member to perform in a specific category and approved by an expert. There is no point in allowing members across categories, to allow access to fields that they may not be capable in, and poses a risk should they impose their own views on what should be objective. I am tentatively for the new system, given the pragmatic conditions, however due to nature of constricting data flow from users, it is quite against the spirit of wikipedia and should be dealt with care in the respect that will empower the appointed far too much.--User:Tuapugui 06:58, 11 January 2010 (UTC)

So...

Any other comments? NW (Talk) 19:14, 8 August 2009 (UTC)

«Projects may opt-in or opt-out at their own discretion if they obtain local consensus»: this looks great to me, but perhaps someone will object that a feature enabled without local consensus should be disabled if there isn't local consensus, not only if there is consensus to disable it. Maybe we can say that local active users can start an "opt-in confirmation", and if there's no consensus to opt-in the wiki opts-out. Not sure, just a proposal to avoid empty opposition. --Nemo 10:34, 10 August 2009 (UTC)

Are there a real need in Global sysops? I mean, are stewards so overwhelmed with routing maintenance of small wikis that they need help? Ruslik 15:31, 10 August 2009 (UTC)

Sadly, many stewards are not active enough to help the small wikis as they need. An additional group of users who can take some limited steward-like actions seems reasonable to me. I have no comment on this specific proposal yet, because I haven't read it.  — Mike.lifeguard | ^@en.wb 22:38, 10 August 2009 (UTC)

I meant that currently there are only 24 users with Global rollback. Assuming that half of them become Global sysops, we will have only 12 of them. This will not be much help for stewards. Ruslik 08:26, 12 August 2009 (UTC)

How do you know this? Are you a steward? Do you actively fight global vandalism/help small wikis? It's probably best to listen to the stewards/people with experience when they say it would help. 12 people *is* a lot, if they're active. Cbrown1023 talk 14:42, 12 August 2009 (UTC)

Ruslik, there have been occasions where for a period of 2-3 hours, I have been unable to have a vandal-only account blocked, and at points, frequent global rollbackers such as J.delanoy and I have even almost had to resort to asking the sysadmins, which is highly not preferred. In my opinion (Full disclosure, I am an active global rollbacker and the author of this proposal), the global sysop group is long overdue. NW (Talk) 01:57, 13 August 2009 (UTC)

@NucleaWarfare: Can you please let me know on my talk page which cases you are talking about?

@Ruslik: As well, Cbrown is correct - if global sysops are meant to help stewards with certain tasks then listen to the stewards. 12 global sysops would make a difference, especially considering these are likely to be more active than some of our current stewards.  — Mike.lifeguard | ^@en.wb 01:16, 15 August 2009 (UTC)

Looks like a fairly reasonable proposal.Geni 14:02, 31 August 2009 (UTC)

As things stand now, I think this proposal should be adopted immediately.  — Mike.lifeguard | ^@en.wb 18:30, 31 August 2009 (UTC)

CentralAuth and GlobalBlock

I saw in the previous proposal that global sysops would be allowed to use Special:CentralAuth and Special:GlobalBlock for their cross-wiki countervandalism works. Is this going to be implemented or this idea was rejected?. Thank you, df|  08:40, 10 August 2009 (UTC) (Moved from above section NW (Talk) 01:57, 13 August 2009 (UTC))

Giving access to Special:GlobalBlock seems like a good idea, as long as there is an understanding that IPs shouldn't be blocked for extended periods of time with a steward's approval. I don't see any particular reason for giving access to Special:CentralAuth though; does anyone else see a reason? NW (Talk) 01:57, 13 August 2009 (UTC)

I'd tend to say yes but *only* for evident vandalism cases and evident bad faith accounts. Help with SUL, deleting global accounts, merging, etc... should be carried by stewards. — df|  09:04, 13 August 2009 (UTC)

Well, for abusive usernames, a steward has to run a checkuser to block the proxies and oversight things anyway, so I really don't see a point to it. However, I would be fine with it either way. NW (Talk) 21:41, 13 August 2009 (UTC)

It would probably be useful to allow access to CentralAuth... I've been sorely tempted to give out temp-steward for that purpose on more than a few occasions. This should be used for emergency situations only, however.  — Mike.lifeguard | ^@en.wb 01:13, 15 August 2009 (UTC)

I'm not sure whether hiding accounts is a separate right... it should be if it isn't & global sysops wouldn't hide accounts (that's oversight-like, and they're not cleared for that).  — Mike.lifeguard | ^@en.wb 01:19, 15 August 2009 (UTC)

I shall remove the part about access to Special:CentralAuth then, per discussion with you that it is most probably not a separate right. Does the current list of usergroup rights look accurate to everyone? NW (Talk) 01:54, 15 August 2009 (UTC)

What about giving access to centralauth but stating that hidding of accounts will not be permited except serious circumstances?. — df|  09:47, 15 August 2009 (UTC)

That would be fine with me, but perhaps we could have a system where any lock + hide taken must be emailed to the steward mailing list (good anyway, because of the necessity of the checkuser needing to be run)? NW (Talk) 13:22, 19 August 2009 (UTC)

As far as I know, not all the lock+hides are checkusered but, when bugzilla:18183 gets fixed those hidden users will dissapear on the Special:Log/globalauth so I think that a courtesy note stating that "Account XXXX has been hidden because YYYY" would be OK. Best regards, — df|  14:09, 19 August 2009 (UTC)

That would be fine with me, but what do the stewards think? (Hint, your time to jump in) NW (Talk) 14:43, 19 August 2009 (UTC)

Nearly a month without comments so I guess folks agree with that... Shall we add it to the list of permissions? Regards, — df|  11:28, 11 September 2009 (UTC)

No, I don't think that's acceptable. No access to CentralAuth until certain bugs are fixed (ie real global blocking of accounts, with appropriate block options). Please let's leave it out.  — Mike.lifeguard | ^@en.wb 13:26, 11 September 2009 (UTC)

Update

• Update: List replaced with a detailed set of the specific userrights, so people could object to some or add to it. So, anything missing? Anything ought to be there that isn't? Any way to easily synthesize this effectively so casual readers could understand it with just a quick readover? NW (Talk) 02:16, 15 August 2009 (UTC)

• Looks like a good proposal. I know some wikis are more particular than others about open proxies, so we may need to remove the proxyunbannable component. MBisanz ^talk 02:30, 15 August 2009 (UTC)

Can you group the rights so that it is easier to see which permissions are (traditionally) associated with what usergroup? Or maybe make a sortable table or something. J.delanoy^gabs_adds 03:10, 15 August 2009 (UTC)

I tried to reorganize it by dividing the userrights into several subsections: block, delete, protect, etc. Really, the only thing different between this and regular administrators is access to Special:GlobalBlock. NW (Talk) 04:42, 15 August 2009 (UTC)

<-- Would it be possible to add the global rollback right rather then just rollback (or would that already be the case?) or maybe just add the global rollback flag to them as well. The main reason I think of this is to offer wikis a wider choice. For example EnWiki which does not have approval for global sysops but DOES have a approval for global rollback and EnWikinews which specifically allows a global sysop to use rollback and nothing else. Jamesofur 21:09, 7 October 2009 (UTC)

I imagine that members of the global sysop group would retain the global rollback flag as well; that should solve the issue that you brought up. NW (Talk) 21:49, 7 October 2009 (UTC)

aye, definitely I only mentioned it because I know a lot of people have a tendency to remove "repetitive" flags :)Jamesofur 22:28, 7 October 2009 (UTC)

Bump

And one last "bump" of the thread. NW (Talk) 02:58, 9 September 2009 (UTC)

• This needs to be discussed on Foundation-l and Wikimedia Forum before we can even start to think we have a consensus. Thanks.  — Mike.lifeguard | ^@en.wb 13:27, 11 September 2009 (UTC)

  I advertised on foundation-l, but I really got no response from there. Would you mind bringing it up; perhaps people would be more willing to listen to a "regular" that just me. NW (Talk) 21:46, 11 September 2009 (UTC)

  Question: How is it going here? --Dferg 22:04, 3 October 2009 (UTC)

• For what it is worth, I  Support the basis of this idea. Tiptoety ^talk 22:43, 3 October 2009 (UTC)
•  Support too. Imho, the current proposal is better than others. --Lucas Nunes 02:16, 4 October 2009 (UTC)
• I, on the other hand,  Oppose OhanaUnited^{Talk page} 05:17, 4 October 2009 (UTC)

  Might I ask why? Simply opposing really does not help. Tiptoety ^talk 05:23, 4 October 2009 (UTC)

  Even after going through rounds of changes, it's still a bad proposal. And you probably had a glimpse of that, seeing how it has been advertised numerous times at Wikimedia Forum and mailing list but yet to generate interest because it had already went through many failed proposals and lost everyone's interest. OhanaUnited^{Talk page} 05:09, 5 October 2009 (UTC)

  But what makes it bad? Maybe then we can improve it. Tiptoety ^talk 05:19, 5 October 2009 (UTC)

  Actually, I'd argue that the reason there is little interest is because it is such an obviously good idea. All the outstanding issues from previous discussions have been resolved, and we're in the final stages of tweaking and advertising. If you have changes you wish to see, let's hear them.  — Mike.lifeguard | ^@en.wb 15:20, 11 October 2009 (UTC)

•  Support I like the idea: will help a lot in Small Wiki Patrol. Pmlineditor ∞ 10:45, 5 October 2009 (UTC)
•  Support: I think this is a good idea. This will allow for a lot more fixes to happen much quicker. As an admin on en-wikipedia I find thing happen pretty quickly, but I imagine on other wikis besides the English and German ones things take considerable turnaround time. This will alleviate the backlog. Valley2city 16:22, 5 October 2009 (UTC)
•  Support: Sounds a promising feature.Email4mobile 19:02, 5 October 2009 (UTC)
• Needs to leave CentralAuth out. Also do we have consensus on how these folk are selected? Tentative support. ++Lar: t/c 20:26, 5 October 2009 (UTC)

  CentralAuth is out for sure, and rough/vague consensus is to have global sysops selected at SRG similar to how global rollbackers are selected, I believe. NW (Talk) 20:39, 5 October 2009 (UTC)

  Yes, that is my reading of the page. A user who is interested in said rights would file a request at SRG, but more similar to a regular RfA and would only be promoted per consensus. Lar, is that what you are asking or more "what is the criteria for candidates?" Tiptoety ^talk 23:17, 5 October 2009 (UTC)

  Yes. Plus some gently worded guidance about what a successful candidate should be bringing to the table, perhaps? (clean recent block log, multiple wiki experiences, admin on at least one already... I don't know exactly but those strike me as plausible) ++Lar: t/c 01:12, 6 October 2009 (UTC)

• I tentatively support this, but (and forgive me if I'm missing it) has there been a discussion about which wikis would be included? faithless (^speak) 23:31, 5 October 2009 (UTC)

  Yep, see the section entitled Scope. As for which wikis specifically those would be, I'm not so sure, but I imagine the list of projects will be generated using List of Wikimedia Projects by Size to get the list of projects with <10 sysops and stewardry to get activity levels. NW (Talk) 00:29, 6 October 2009 (UTC)

  Ah, okay, thanks NW. I misunderstood that section before. Thanks! faithless (^speak) 00:46, 6 October 2009 (UTC)

•  Support per above arguments. A good idea. Tempodivalse [talk] 16:34, 6 October 2009 (UTC)
•  Support A good idea. Maximillion Pegasus 18:52, 6 October 2009 (UTC)
•  Oppose - on some language wikipedias there is a requirement that a sysop be fluent in that language. The last thing they want is a bunch of fools who don't speak the language (for example who are English-only speakers) invading and trying to "run" things as they see fit, or even trying to do anything at all that only a fluent sysop should do. That's basically what this proposal is. If that happens, it will kill off many language projects for all practical purposes, since native speakers will be even less interested in contributing to it or even reading something that is being "controlled" by non-speakers. On the other hand, if someone can speak a language fluently and wants to become a sysop, let them use existing procedure to become a sysop on that particular wikipedia. 70.105.32.242 17:52, 7 October 2009 (UTC)

  Hence why a project can opt-out. Tiptoety ^talk 19:13, 7 October 2009 (UTC)

  I'm sorry, it seems you fundamentally misunderstand what the proposal is about. Please do re-read it and you'll find that global sysops are explicitly and specifically intended to do countervandalism, anti-spam and uncontroversial maintenance where language is next-to-irrelevant. The folks who will be doing this work know what they are doing, and know where their boundaries are.  — Mike.lifeguard | ^@en.wb 15:20, 11 October 2009 (UTC)

• I will only support this idea if a project has the ability to opt-out of global sysop. If that is the case, then I will  Support. Otherwise, I  Oppose. Razorflame 19:14, 7 October 2009 (UTC)

  As stated at Global sysops, projects will have the ability to opt-out. Cheers, Tiptoety ^talk 19:16, 7 October 2009 (UTC)

•  Support Mostly per others above but having another small group of people who could actively help with active vandalism would be a huge help. The global rollback feature is great and I think helps the small wikis but even with that most response has to be done by local admins (who are often infrequent) or stewards (who are a small group with a lot to deal with already). As stated below I don't think they need the ability to add user rights, thats something that can be left to local admins and isn't in anyway a rush issue. On the less straightforward side I sorta feel for something with access to the global block procedures (something which I think is important) and a position of trust across many wikis it may be nice to require identification to the foundation and over 18 like we currently do for oversight,checkuser and steward. I think that would also help show small wikis they were trustworthy.Jamesofur 21:06, 7 October 2009 (UTC)
•  Support No worse than global bot flag. Especially since wikis can opt out. However I don't think they should have the ability to global block...that should only be steward level. -Djsasso 03:58, 8 October 2009 (UTC)
• Definitely  Support, as I said previously. --Nemo 18:00, 8 October 2009 (UTC)
•  Support I like this idea. -- Mercy (☎|✍) 07:57, 9 October 2009 (UTC)
•  Support no question at all. --Herby ^{talk thyme} 18:23, 9 October 2009 (UTC)
•  Support This is needed to fight vandalism in small wikis. --Winhunter 02:53, 11 October 2009 (UTC)
•  Support - This is a good idea for smaller wikis. --Skenmy ^talk 09:00, 11 October 2009 (UTC)
•  Support, entirely good idea. Stifle 10:41, 12 October 2009 (UTC)
•  Support If support is clear here (which it is at the moment), dont waste time discussing it at Foundation-l or Wikimedia Forum.--Kozuch 06:48, 13 October 2009 (UTC)
•  Support in general, a quite good idea, especially for small wikiprojects while fighting vandalism (as far as I've seen, it's an essential their problem).--Microcell 14:06, 15 October 2009 (UTC)
• Certain  Support. vvv 16:49, 15 October 2009 (UTC)
•  Support --Dirk Beetstra ^{T C} (en: U, T) 10:21, 19 October 2009 (UTC)
•  Support -- Cirt (talk) 22:32, 19 October 2009 (UTC)
•  Support -- I normally go through the speedy deletions for wikis with 1 or 0 sysops weekly, but I think it would be useful to have some experienced SWMT users act as admins, since they are the ones fighting vandals. Global rollback does not cut it when fighting a vandalbot. --Daniel Mayer (mav) 03:10, 22 October 2009 (UTC)
•  Support quite good idea! — YourEyesOnly 03:33, 22 October 2009 (UTC)
•  Support --WizardOfOz 18:47, 22 October 2009 (UTC)
•  Support -- Jrooksjr 20:05, 25 October 2009 (UTC)
•  Support Language-fluency is the one plausible concern I see, but vandalism concerns override that, and there is the possibility of opt-out. Move it along, I'd say. Brons 17:30, 27 October 2009 (UTC)
•  Support - the rough edges of earlier proposals seem to have been smoothed out. -- sj · translate · + 04:53, 29 October 2009 (UTC)
•  Support Cowtung 19:58, 8 January 2010 (UTC)

Votes

What's the point of the support or oppose comments here? --Erwin 19:08, 22 October 2009 (UTC)

•  Support the comment above, he's right. Besides, the voting page is here-- OlEnglish 13:05, 8 January 2010 (UTC)

Editprotected request of sorts

Would it be possible to advertise this discussion at Special:Watchlist? I ask here because I have no idea what the corresponding MediaWiki page is. NW (Talk) 02:17, 4 October 2009 (UTC)

Done. —Anonymous Dissident^Talk 06:04, 4 October 2009 (UTC)

Local Visibility

As far I have experiense, actions made by stewards are not always visible on the local RecentChanges and local Loggs. Will the actions made by global sysops be visible on RC and local Loggs? -- Lavallen 19:22, 6 October 2009 (UTC)

Yes. Actions taken by global sysops will be shown on the relevant RecentPages page on the relevant wiki execpt global blocking that will be shown on the RecentChanges of meta and will be logged on Special:Log/gblblock. Hope that this answers your question. Best, --Dferg 19:46, 6 October 2009 (UTC)

Not all wikis have the same set of groups. On sv:wikipedia I can grant rollbacks, but on sv:wikisource I can't, since we do not have any such group. Can a global sysop grant rights like rollbacks and autopatroll on a wiki that do not have such a group? -- Lavallen 19:59, 6 October 2009 (UTC)

No. They would be governed by the rules of the wiki in which they are editing. If a wiki does not have rollback enabled, then they would not have the ability to grant it to a user there. Really, they would be acting as if they were a local administrator. Tiptoety ^talk 20:03, 6 October 2009 (UTC)

 Support, then feel free to grant all global sysops a babelfish! -- Lavallen 20:12, 6 October 2009 (UTC)

Actually, after looking here it appears as if global admins would not have the ability to edit userrights. Tiptoety ^talk 20:16, 6 October 2009 (UTC)

Aye, I think granting rights would be something that should be more local, generally they can wait anyway while the main job of the global sysop is to respond to "emergency" situations. Jamesofur 20:58, 7 October 2009 (UTC)

Agreed. Tiptoety ^talk 20:33, 8 October 2009 (UTC)

No granting rights (except perhaps autoconfirmed-equivalency?) and no global blocking... those need clarification if there is any confusion. ++Lar: t/c 03:35, 11 October 2009 (UTC)

The current proposal allows for global blocks. Tiptoety ^talk 17:23, 11 October 2009 (UTC)

But not locks or access to CentralAuth. Pmlineditor ∞ 17:25, 11 October 2009 (UTC)

Next step?

It is apparent the "discussion" portion is winding up, and people are starting to simply vote on the proposal. Seeing as the consensus here appears to be in support of global sysops, should the next step be putting it into a more "global" vote? If so, I think it would be a good idea to put up a watchlist notice on those wikis that are going to be effected by such a change. Tiptoety ^talk 20:02, 6 October 2009 (UTC)

I posted a notice on the Wikimedia Forum as well as both Foundation-l and Wikipedia-l mailing lists (the first two suggested by Mike Lifeguard at the top of the #bump section. I think our next step has to be to try and get some translations for the text of the proposal and get notices up to other wikis. I'm not sure if we want to go and individually put up banners or do we want to do a global one? Jamesofur 21:45, 7 October 2009 (UTC)

Default enabled wikis

I have something to ask:

1. How many wikis would be enabled global sysops by default?
2. If there is something urgent in a small wiki, such as, some over-flooded vandalism, or upload many images without license and source, how can local users announce their sysops?
3. Some disruptive edits are just test edit, change some words, curse something in their local language, how can sysops do if they don't know the language to recognize those? I think that if there is no local community to put speedy templates, request for block and protect, the global sysops will be useless. Do you have plans for this situation?

Tân (talk) 16:09, 8 October 2009 (UTC)

Global sysop will be enabled for all projects which have fewer than 10 sysops or 3 active admins unless they opt out (AFAIK). Local users will announce sysops by !voting as usual. About the third question, I'm not sure, I think Google Translator might help and sometimes vandalism is really blatant ;). This is from what I know: you might get a better answer from others. Pmlineditor ∞ 17:16, 8 October 2009 (UTC)

I think ultimately we should only be electing user to be global sysop who have a large amount of clue. If a user sees something in another language that appears to be vandalism, but when translated is a borderline case then they should probably leave it, alert the local admins, and/or attempt to contact another user/global sysop who speaks that language. Really global sysops should only be taking administrative action in clear cut situations. Tiptoety ^talk 20:33, 8 October 2009 (UTC)

I think Vinhtantran was asking how many wikis "all wikis except..." actually is. Does someone want to take the time to figure that out?

Given the importance and sensitivity of the role, I have little doubt the standards used for adding people to this group will be sufficiently high so as to minimize the risk of harm (whether intentional or inadvertent). Equally, anyone asking for the permissions would likely have a history of cross-wiki countervandalism work - they already know how to deal with vandalism well, including in languages and scripts they cannot read. Point well taken, but I think it is not a problem, simply something to be conscious of as once we start seeing requests for permissions.  — Mike.lifeguard | ^@en.wb 21:12, 8 October 2009 (UTC)

I know that. ;-) I was discussing his last point. :-) That said, I can generate a list of the wiki's that would be effected. Give me a bit though. Tiptoety ^talk 22:31, 8 October 2009 (UTC)

The table below shows the 581 open wikis that fit the criteria. Each row includes the total number of sysops, and the number of sysops that have edited or performed a logged action within the last two months. (Some wikis listed below may be closed, if they're marked open in the toolserver database.)

Included wikis

Project Number of sysops Link to category Number of items afwiki 15 Kategorie:Kandidate vir spoedige verwydering 1 angwiki 1 Flocc:Candidates for speedy deletion 1 arwiki 26 تصنيف:صفحات للحذف السريع 28 arwikibooks 5 تصنيف:صفحات للحذف السريع 6 arwikiquote 3 تصنيف:صفحات للحذف السريع 4 arwikisource 9 تصنيف:صفحات للحذف السريع 1 arywiki 4 تصنيف:صفاحي ف التحياد الزربان 2 aswiki 3 শ্ৰেণী:ক্ষিপ্ৰ বিলোপনৰ প্ৰাৰ্থী 18 aswikisource 1 শ্ৰেণী:ক্ষিপ্ৰ বিলোপনৰ প্ৰাৰ্থী 1 azbwiki 5 بؤلمه:ویکی‌پدیا:سیلینه‌جک صفحه‌لر 14 azwiki 14 Kateqoriya:Sürətli silinəcək səhifələr 2 banwiki 2 Kategori:Artikel yang layak untuk dihapus 5 bclwiki 3 Kategorya:Tolos-tolos na mga pagparà 2 bewikibooks 1 Катэгорыя:Старонкі да выдалення 1 bewikisource 2 Катэгорыя:Артыкулы да хуткага выдалення 51 bgwiki 24 Категория:Страници за бързо изтриване 22 bhwiki 1 श्रेणी:तुरंत हटावे लायक पन्ना 13 bnwiki 12 বিষয়শ্রেণী:দ্রুত অপসারণের যোগ্য 4 bnwiktionary 1 বিষয়শ্রেণী:দ্রুত অপসারণের যোগ্য 5 cawiki 18 Categoria:Sol·licituds de supressió immediata 2 cebwiki 5 Kategoriya:Kandidato sa pagtangtang dayon 1 cewiki 2 Категори:Википеди:Сиха дӀайаккхаре 9 chywiki 0 Category:Candidates for speedy deletion 1 ckbwiki 6 پۆل:پەڕەکان بۆ سڕینەوەی خێرا 11 commonswiki 201 Category:Candidates for speedy deletion 12 cswiki 34 Kategorie:Údržba:Stránky ke smazání 2 cswikibooks 3 Kategorie:Údržba:Smazat 1 cswikiquote 2 Kategorie:Údržba:Smazat 1 cswikisource 3 Kategorie:Údržba:Smazat 17 cswikiversity 3 Kategorie:Stránky určené ke smazání 3 cswiktionary 3 Kategorie:Údržba:Smazat 17 cvwiki 2 Категори:Тӳрех кăларса пăрахмалли статьясем 5 dagwiki 3 Pubu:Candidates for speedy deletion 1 dawiki 23 Kategori:Sider der er foreslået slettet hurtigt 3 dewikibooks 7 Kategorie:Wikibooks: Schnelllöschkandidaten 3 dewikiversity 11 Kategorie:Wikiversity:Löschen 13 dtywiki 1 श्रेणी:मेटौन पड्या पन्नाअन 20 emlwiki 2 Categoria:CANCELLA 1 enwiki 1,061 Category:Candidates for speedy deletion 12 enwikibooks 9 Category:Candidates for speedy deletion 11 enwikinews 17 Category:Speedy deletion 7 enwikiversity 15 Category:Candidates for speedy deletion 9 enwiktionary 102 Category:Candidates for speedy deletion 31 eowiki 14 Kategorio:Tujforigendaj artikoloj 59 eswiki 64 Categoría:Wikipedia:Borrar (definitivo) 4 eswikinews 11 Categoría:Borrar (definitivo) 9 eswikiquote 5 Categoría:Wikiquote:Borrar (definitivo) 3 fawiki 36 رده:صفحه‌های نامزد حذف سریع 161 fawikisource 3 رده:درخواست‌های حذف سریع 1 fawiktionary 3 رده:صفحه‌های نامزد حذف سریع 6 fiwiki 29 Luokka:Pikapoisto 2 fiwiktionary 9 Luokka:Roskaa 3 frwiki 159 Catégorie:Wikipédia:Suppression immédiate demandée 3 frwikiquote 5 Catégorie:Suppressions immédiates demandées 3 frwikisource 16 Catégorie:Suppression 6 frwikiversity 7 Catégorie:Suppressions immédiates demandées 13 frwikivoyage 5 Catégorie:Suppressions immédiates demandées 4 frwiktionary 33 Catégorie:Suppressions immédiates demandées 3 ganwiki 2 分類:快速刪吥 1 glwiktionary 1 Categoría:Wiktionary:Páxinas para borrar 3 guwikisource 2 શ્રેણી:રદ કરવા માટેના પાના 1 gvwiki 2 Ronney:Duillagyn er çhionn-scryssey 1 hawiki 4 Rukuni:Candidates for speedy deletion 1,556 hawwiki 0 Māhele:ʻAoʻao no ke kāpae wikiwiki ‘ana 1 hewiktionary 5 קטגוריה:ויקימילון:למחיקה מהירה 17 hifwiki 1 vibhag:Mitae ke maang 1 hiwiki 5 श्रेणी:शीघ्र हटाने योग्य पृष्ठ 184 huwiki 27 Kategória:Azonnali törlésre váró lapok 8 huwiktionary 3 Kategória:Törlendő lapok 82 hywiki 9 Կատեգորիա:Վիքիպեդիա:Արագ ջնջման ենթակա էջեր 13 hywiktionary 1 Կատեգորիա:Արագ ջնջման ենթակա էջեր 3 idwiki 40 Kategori:Usulan penghapusan cepat 15 idwikibooks 4 Kategori:Artikel yang layak untuk dihapus 1 idwiktionary 5 Kategori:Artikel yang layak untuk dihapus 2 igwiki 1 Otú:Candidates nhichapụ ngwangwa 40 iowiktionary 1 Kategorio:efacenda 1 itwikibooks 3 Categoria:Da cancellare subito 3 itwikinews 4 Categoria:Da cancellare subito 1 itwiktionary 4 Categoria:Da cancellare subito 27 jawiki 39 Category:即時削除対象のページ 8 jawikibooks 3 カテゴリ:即時削除 32 jawikinews 3 カテゴリ:即時削除 10 jawikisource 3 カテゴリ:即時削除 6 jawiktionary 4 カテゴリ:即時削除 8 jbowiki 2 klesi:sutra vimcu 1 kawiki 3 კატეგორია:წასაშლელი გვერდები 12 kkwiki 16 Санат:Жедел жоюға ұсынылғандар 138 kowiki 24 분류:삭제 신청 문서 11 kuwiktionary 5 Kategorî:Gotarên ku bên jêbirin 19 kwwiki 1 Klass:Profyansow rag dilea 2 lbewiki 1 Категория:Speedy deletion requests 4 liwiki 6 Categorie:Kandidate veur sjnel eweg te goeje 178 lldwiki 1 Categoria:Deleteme 1 lmowiki 5 Categoria:De scancelà subit 9 ltwiki 9 Kategorija:Kandidatai skubiai trinti 2 madwiki 0 Bhângsa:Candidates for speedy deletion 1 maiwiki 5 श्रेणी:शीघ्र मेटाएल जाइवला पृष्ठसभ 5 minwiki 5 Kategori:Artikel nan patuik diapuih 5 mlwiki 14 വർഗ്ഗം:പെട്ടെന്ന് നീക്കം ചെയ്യുവാൻ സാധ്യതയുള്ളവ (എല്ലാം) 11 mnwiki 4 Ангилал:Устгалд орох хуудсууд 6 mrwiki 9 वर्ग:लवकर वगळावे विनंत्या 9 mswiki 13 Kategori:Calon untuk penghapusan segera 7 mswiktionary 1 Kategori:Laman untuk dihapuskan 13 mywiki 3 ကဏ္ဍ:မဆိုင်းမတွ ဖျက်ပစ်ရန်များ 7 mznwiki 2 رج:سریع حذف نومزه‌ئون 1 newiki 5 श्रेणी:शीघ्र मेटाउन नामाङ्कित पृष्ठहरू 1 nlwiki 36 Categorie:Wikipedia:Nuweg 1 nlwikisource 2 Categorie:Wikisource:Nuweg 9 nlwikivoyage 6 Categorie:Wikivoyage:Artikelen die direct verwijderd moeten worden 1 ocwiki 3 Categoria:Wikipèdia:Supression immediata demandada 85 orwiki 4 ଶ୍ରେଣୀ:Candidates for speedy deletion 2 pamwiki 1 Category:Candidates for speedy deletion 3 pawiki 8 ਸ਼੍ਰੇਣੀ:ਛੇਤੀ ਮਿਟਾਉਣਯੋਗ ਸਫ਼ੇ 41 plwiki 102 Kategoria:Ekspresowe kasowanie 3 plwikiquote 7 Kategoria:Ekspresowe kasowanie 1 pnbwiki 1 گٹھ:امیدوار برائے حذف شدگی 172 pswiki 0 وېشنيزه:د چټکو ړنگولو کانديد مخونه 1 ptwiki 66 Categoria:!Páginas para eliminação rápida 2 ptwikinews 5 Categoria:Páginas para eliminação rápida 2 ptwikisource 1 Categoria:!Páginas para eliminação rápida 5 ptwiktionary 4 Categoria:!Página para eliminação rápida 4 rowiki 16 Categorie:Pagini de șters rapid 1 ruwiki 73 Категория:Википедия:К быстрому удалению 29 ruwikibooks 1 Категория:Викиучебник:К быстрому удалению 107 ruwikinews 6 Категория:Викиновости:К быстрому удалению 8 ruwikiquote 5 Категория:Викицитатник:К быстрому удалению 5 ruwikisource 4 Категория:К быстрому удалению 2 ruwiktionary 13 Категория:Викисловарь:К быстрому и безусловному удалению 47 sahwiki 2 Категория:Бикипиэдьийэ:Түргэнник соторго 1 satwiki 2 ᱛᱷᱚᱠ:Candidates for speedy deletion 4 scnwiki 5 Catigurìa:Pruposti pi eliminazzioni lesta 2 sdwiki 3 زمرو:ترت ڊاٺ جا اميدوار 1 shwiki 11 Kategorija:Kandidati za brzo brisanje 5 simplewiki 16 Category:Quick deletion requests 3 siwiki 2 ප්‍රවර්ගය:ඉක්මන් මකා දැමීම සඳහා යෝජිතයෝ 18 skwiki 8 Kategória:Wikipédia:Kandidáti na rýchle zmazanie 5 slwiki 23 Kategorija:Predlogi za hitro brisanje 5 snwiki 0 Category:Candidates for speedy deletion 1 sowiki 1 Category:Tirtir 3 srwikisource 3 Категорија:Брзо брисање 1 srwiktionary 6 Категорија:брзо брисање 5 suwiki 6 Kategori:Artikel anu kudu dihapus 1 svwiktionary 13 Kategori:Wiktionary:Raderas? 1 swwiki 13 Jamii:Makala kwa ufutaji 2 tawiki 33 பகுப்பு:விரைந்து நீக்கப்பட வேண்டிய பக்கங்கள் 43 tawikisource 3 பகுப்பு:விரைந்து நீக்கப்பட வேண்டிய பக்கங்கள் 141 tawiktionary 6 பகுப்பு:நீக்கப்பட வேண்டிய பக்கங்கள் 9 tewiki 12 వర్గం:Candidates for speedy deletion 3 tgwiki 5 Гурӯҳ:Википедия:Номзадҳои ҳазфи сареъ 3 thwiki 15 หมวดหมู่:หน้าที่ถูกแจ้งลบ 13 thwikiquote 1 หมวดหมู่:หน้าที่ถูกแจ้งลบ 306 thwikisource 2 หมวดหมู่:หน้าที่ถูกแจ้งลบ 95 thwiktionary 3 หมวดหมู่:หน้าที่ถูกแจ้งลบ 8 tlwiki 9 Kategorya:Mga pahinang mabilisang buburahin 8 trwiki 24 Kategori:Hızlı silinmeye aday sayfalar 2 trwiktionary 4 Kategori:Vikisözlük silinecek sayfalar 5 ttwiki 5 Төркем:Тиз бетерүгә кандидатлар 40 udmwiki 3 Категория:Википедия:К быстрому удалению 1 ukwiki 43 Категорія:Сторінки до швидкого вилучення 23 ukwikisource 5 Категорія:Сторінки до швидкого вилучення 1 urwiki 9 زمرہ:امیدوار برائے حذف شدگی 13 uzwiki 11 Turkum:Tezda oʻchirishga nomzodlar 42 uzwiktionary 1 Turkum:Tezda oʻchirishga nomzodlar 7 vecwiki 3 Categoria:Da descançełare suito 3 viwiki 20 Thể loại:Chờ xóa 19 viwikibooks 2 Thể loại:Xóa nhanh 6 viwikisource 2 Thể loại:Đề nghị xóa nhanh 7 wikidatawiki 59 Category:Wikidata:Deletion 1 yowiki 2 Ẹ̀ka:Àwọn ojúewé fún ìparẹ́ kíákíá 7 zh_min_nanwiki 4 Lūi-pia̍t:Tán-thāi khoài-sok thâi-tû ê ia̍h 1 zh_yuewiki 12 Category:即刻刪除候選 171 zhwiki 61 Category:快速删除候选 8 zhwikiquote 3 Category:快速删除候选 2 zhwikisource 6 Category:快速删除候选 2 zhwikiversity 3 Category:快速删除候选 1 zhwiktionary 6 Category:快速删除候选 5 Total 4,707 Available as TSV: download

—Pathoschild 04:46:16, 09 October 2009 (UTC)

Should i add this to Small and large wikis?

Furthermore we should discuss a concept how we could easily check if global sysops are enabled on a wiki. At the moment i always have to search on a special page or the wikiset on meta if global bot is enabled on this wikis. I think that should be easeier for global sysop because otherwise on emergency you ping an member on irc although he/she cannot help you. (Perhaps local existence of Project:Global Sysop). Merlissimo 04:15, 24 October 2009 (UTC)

Allowed actions

This proposal says that global sysop rights are strictly for maintenance and countering abuse. I assume that "countering abuse" is reverting and deleting vandalism and blocking vandals. But what is "maintenance" more exactly? I assume it is regular activities that are not emergencies, such as deleting/fixing broken redirects, deleting orphaned talk pages (on wikis that has such a policy), updating MediaWiki messages, and probably other things to. Would it be possible for a project such as sv.wikisource (which has feew but active admins) to only allow global sysop to do the tasks related to abuse, while allowing only local sysops to do the maintenance tasks? /Ö 11:58, 9 October 2009 (UTC)

Global sysops are generally for handling vandalism and related works. If a project has no need for global sysops they may also opt out. Pmlineditor ∞ 12:00, 9 October 2009 (UTC)

I personally think it would be more then fine to have local projects put their own restrictions on global sysops. I think the "maintenance" things would really only come up on wikis where there were no active administrators at all, on other wikis I would agree with you most of that should wait until a local admin is available (or not if the wiki decided they wanted it differently). It may be useful to have a page set up specifically to list what local wikis have allowed/restricted a GS to do. (for example the EnWiki and EnWikinews policies linked on the bottom of the proposal).Jamesofur 12:25, 9 October 2009 (UTC)

I take that back, it was on the old proposal but examples:

• Local policies on global rights usage
  • en.wikipedia
  • species.wikimedia
  • en.wikinews

Jamesofur 12:31, 9 October 2009 (UTC)

I would much rather that local policies restricting what global sysops may do are not allowed, or specifically and strongly discouraged. We're talking about hundreds of wikis - if people need to know specific policies and which wiki the policy is for, we'll have effectively defeated the purpose here. I have no objection to standard "don't abuse your tools" pages like enwiki has, but anything detailed and project-specific is really not OK. If some project doesn't want global sysops, then they don't get global sysops - no fence sitting please.

However, to address the original concern about "maintenance" and what that actually entails. The category "maintenance" is intended to cover non-emergency actions like speedy deletions which have piled up. They still need to be deleted, but it may not fall under the "spam" or "vandalism" categories. Other examples might be fixing up Common.js if there are errors, or fixing broken redirects. Stuff that does need to be done, but isn't urgent in the same way vandalism is. It probably would not include deleting orphaned talk pages (and any project with such a policy probably doesn't need help from global sysops) or similar tasks. I'm not sure if we need something more specific in the policy.  — Mike.lifeguard | ^@en.wb 15:00, 9 October 2009 (UTC)

Completely agree. Each wiki having their own specific policy in regards to global sysop is going to get very confusing for the GS trying to perform an administrative action. With hundreds of wikis included, taking time to look up if each project has a local policy is going to be a waste of time and defeat the point. Tiptoety ^talk 16:48, 9 October 2009 (UTC)

I wasn't clear enough looking at what I wrote, I agree completely. I would tend to lean towards the "specifically and strongly discouraged" side of things rather then the totally not allowed side but if it got to be a large group of wiki's it would make the whole process unmanageable. Jamesofur 20:13, 9 October 2009 (UTC)

Any wiki that wants to tweak the things that global sysops can do needs to opt out, in my view. As Mike says, way too confusing if the rights/procedures vary. Either in, or out. That said I do think we need it very clearly deliniated what the default set is. As I said above, no global blocking, and no changing rights... those are key for support I think. I know I won't support it if rights changes are included (other than MAYBE autoconfirmed-equivalency). So no tweaking :) ++Lar: t/c 03:39, 11 October 2009 (UTC)

No rights changes for sure, but I'm confused as to why global sysops should not have access to global block? Vandalizing IPs often jump various wikis, and it would be pointless to keep blocking them on each individual IP. Global sysops will definitely come from the well-respected and experienced global rollbackers who know when global block is appropriate to use, so I don't understand why we would restrict it from them. NW (Talk) 04:03, 11 October 2009 (UTC)

I'm baffled as well! Perhaps Lar meant no locking of global accounts? I'm certainly in agreement there - global sysops cannot have access to Special:CentralAuth. However, they should have access to blocking global accounts if/when that gets implemented. And they should also have access to globally blocking IPs.

And I didn't know anyone was ever considering adding userrights changes to the permission set... that's a tad strange and I wouldn't support it. (can't find anywhere that it is suggested though).  — Mike.lifeguard | ^@en.wb 14:58, 11 October 2009 (UTC)

OK, now I see where userrights are discussed (#Local_Visibility) - however that is based on a misunderstanding of how permissiong work. Those rights changes wouldn't be possible with global sysop rights. The ability to change rollbacker permissions for users (etc) is granted to local sysops as a group - global sysops will not be part of that group, so they can't do those changes. So, it is a non-issue based on a minor misunderstanding. All is well :)  — Mike.lifeguard | ^@en.wb 15:02, 11 October 2009 (UTC)

Lock for sure should not be on there, and I feel strongly about it and would oppose the proposal over it. I did mean block as well, because right now global blocking is a Steward function, and global sysop doesn't mean global actions, it means local actions that can be done anywhere (globally) not specifically not allowed. But I'm rather weaker on that point. If everyone else feels differently I'm fine. ++Lar: t/c 19:21, 11 October 2009 (UTC)

Implementation

It's been quite a while since this was open, and the comments above seem to indicate that the vast majority of people like this idea. Would it be appropriate if we implemented Global Sysops based on this widely-advertised discussion 1 week from this post if there is still not significant opposition? NW (Talk) 03:16, 11 October 2009 (UTC)

tempting... ++Lar: t/c 03:37, 11 October 2009 (UTC)

Yes. I say go for it. Tiptoety ^talk 04:34, 11 October 2009 (UTC)

Agree with Tiptoety. Pmlineditor ∞ 09:07, 11 October 2009 (UTC)

I disagree. This is too radical to come upon so soon. #Next step? is much more reasonable. —Anonymous Dissident^Talk 11:24, 11 October 2009 (UTC)

I'd like to get it active as quickly as possible but I do think we want to try and get the word out more especially to smaller wiki's where this will effect them. I have made a request for translation and put the template on the main page (Template:Translation/Global_sysops). It looks ugly :( so if anyone has a better way to do it or I just did it wrong please feel free to go ahead and change it. I think it would be great if we could get an announcement out at least at the wikis that will be effected by default (listed above) maybe just a total global message? Jamesofur 11:46, 11 October 2009 (UTC)

Anonymous Dissident is right - this is too radical to implement without wider consultation. Perhaps a short centralnotice will be needed to get sufficient input :\  — Mike.lifeguard | ^@en.wb 14:55, 11 October 2009 (UTC)

Hm, alright. Prepare for this to remain open for quite a bit longer then. ;-) Tiptoety ^talk 17:21, 11 October 2009 (UTC)

Lets not jump the gun then... Pmlineditor ∞ 17:23, 11 October 2009 (UTC)

I don't think we would be jumping the gun. I am just saying that putting up a centalnotice will bring large crowds of people, and large crowds of people tend to disagree. But, maybe I am being cynical. We will see. Tiptoety ^talk 17:25, 11 October 2009 (UTC)

I fully agree with you... a centralnotice will create confusion and as such it will be difficult to get consensus in a short time then. But we've been without GSes for a long time, a week can't harm, can it? Pmlineditor ∞ 17:27, 11 October 2009 (UTC)

If large crowds disagree, large crowds disagree. This proposal is for the large crowds. It's a global user right, so therefore it's critical the global community is collectively happy about it. Consensus among Metapedians for something that affects everyone means very little. I think a Centralnotice is a good idea, with perhaps a vote appended. —Anonymous Dissident^Talk 01:16, 12 October 2009 (UTC)

I agree with AD here; this is a proposal that affects many, many, many projects, and shouldn't be implemented so quickly. Note, however, that I'm strongly in favor of this overall. –Juliancolton | ^Talk 01:24, 12 October 2009 (UTC)

I should note that I do support this proposal. But rushing into something this impactful is not a good idea. —Anonymous Dissident^Talk 01:35, 12 October 2009 (UTC)

I see. I think that a Central notice might be useful. Pmlineditor ∞ 13:15, 12 October 2009 (UTC)

Proposed for Global Blacklist: UGG boots

I've been getting spammed by someone promoting www.myuggs.org since Sept. 24, every few days. It appears to be a robot function, using different usernames with numbers added, and a block of the IP does not stop the abuse.

Here is a log of recent delections on my wiki: http://peswiki.com/index.php/Special:Log/delete

In doing a quick search, I see that other wikis are also being hig with the identical spam message. See http://www.google.com/search?q=myuggs.org+wiki

Samples:

• http://www.blender3dtutorials.com/
• http://sioc-project.org/aggregator/sources/6
• http://wiki.lupaworld.com/index.php/Ugg_Boots_%E2%80%93_Classic_Vs_Modern_Styles
• http://wiki.moztw.org/index.php/Aren%E2%80%99t_these_UGGS_you_EVER_did_see%3F

I'm tired having to delete there additions and block the user making these. I'd like to see a global ban on myuggs.org, and I'm sure the other wikis would as well.

Thanks

-- Sterlingda 06:25, 11 October 2009 (UTC)

You want Talk:Spam blacklist. Cheers, Tiptoety ^talk 07:28, 11 October 2009 (UTC)

Thanks folks, I'm taking a look at this now.  — Mike.lifeguard | ^@en.wb 14:51, 11 October 2009 (UTC)

Annual confirmations?

Do we really want that? I think not, for the same reasons Meta got rid of them for sysops. There is already a section on a vote of confidence, which seems to me to cover what's needed. I've commented the section out pending dicsussion.  — Mike.lifeguard | ^@en.wb 15:42, 11 October 2009 (UTC)

I was going to ask the same question too. Isn't that a bit redundant? Pmlineditor ∞ 16:24, 11 October 2009 (UTC)

I would be fine with getting rid of them. The only reason I left them in when I originally wrote this was because previous proposals had it, and I didn't want to change the proposal too drastically from them. But I agree that having annual reconfirmations is a bit pointless if any steward can already remove access for misuse. NW (Talk) 16:31, 11 October 2009 (UTC)

I would support removing it. Tiptoety ^talk 17:01, 11 October 2009 (UTC)

Yearly reconfirmations would not seem to me to be a particularly useful exercise, so I too support removing the clause. AGK 17:25, 11 October 2009 (UTC)

I am an awkward sod - I like annual confirmations. It means you can get rid of the dead wood without causing offence - not everyone drops their rights who should ;). --Herby ^{talk thyme} 18:10, 11 October 2009 (UTC)

Please see [1]. Global sysop are removed due to inactivity. Cheers, Tiptoety ^talk 18:23, 11 October 2009 (UTC)

IF we have a removal due to inactivity (and some informal agreement to actually do this from time to time) and IF we have a well thought out clause for votes of no confidence that can't be dodged, I don't think we also need the annual review. But absent both those being firm clauses with enforceable provisions, we do. ++Lar: t/c 19:18, 11 October 2009 (UTC)

Note there's already an inactivity section (6 months, btw, which I find just lovely :D). What is needed in the vote of no confidence section that isn't there already?  — Mike.lifeguard | ^@en.wb 16:18, 12 October 2009 (UTC)

Stewards and global sysops

The proposal in its current form proposes that the consensus for an editor to be elected as a global sysop would be evaluated by a steward. Such a method of election would conflict with the spirit of the steward office: that stewards are elected to use sensitive technical facilities to implement community decisions.

A more sensible approach might be to have the community vote on a candidacy for global sysopship on a Meta page, and for the steward to flag up the candidate only if the vote was supported by, say, 80% of the participants.

AGK 17:33, 11 October 2009 (UTC)

Stewards already grant some powers based on evaluation of requests. Perhaps a hybrid approach in which comment is solicited and then a decision taken? I am not sure I'm in favor of a strict 80% of whoever turns up with no discretion. ++Lar: t/c 19:16, 11 October 2009 (UTC)

I agree with Lar having a strict 80% support rate is extreamly high, you may have a good user who is highly recognised but gets say 79% of votes this would then surely be unfair on them even though they have put in alot of effort and are recognised by the community? Corruptcopper 18:33, 13 October 2009 (UTC)

I suggested 80% as an example; the cut-off percentage could really be anything. The more important issue is that the cut-off is a standard metric rule applied to all votes: adopting such a procedure would eliminate all steward discretion, which I think is more in keeping with the spirit of the position. AGK 13:02, 14 October 2009 (UTC)

I'd favor giving GS per consensus and not voting. See Polling is evil. Setting such a percentage will transform it to a vote, rather than a !vote. Pmlineditor ∞ 16:15, 14 October 2009 (UTC)

I take slight issue with the language that a steward may "remove" a global sysop's privileges. I think it should be termed "suspend" a global sysop's privileges. This implies that a large group may reinstate the global sysop's privileges in the event a steward took unwarranted action. It also properly informs stewards of the action they are about to take. 206.80.3.5 17:06, 8 January 2010 (UTC)

User rights

I have a few questions about the current list of proposed user rights.

1. It's my understanding that the primary purpose of global sysops is to do non-controversial maintenance on small projects. Why would global sysops need centralnotice-admin and centralnotice-translate. Both of these rights seem completely out of the remit of global sysops.
2. editusercssjs — what's the purpose of global sysops having this right? I can't see much good coming from them having it.
3. upload, upload_by_url, import — global sysops won't be creating content....
4. createaccount — don't see the need for this one either.

In general, I'm in favor of global sysops having as few rights as necessary. I'm also curious what the procedure for adding new rights will be. Presumably people will vote to support or oppose this proposal based (at least partially) on the current proposed user rights. If new rights become available in the future, who will determine whether they should be added to the global group? --MZMcBride 17:48, 11 October 2009 (UTC)

Remove them from what I see... none of them are useful. And new rights will be added by discussion here I guess. Pmlineditor ∞ 17:50, 11 October 2009 (UTC)

editusercssjs is included because people use scripts to vandalize - as well, they'll likely deal with requests from users for help with scripts.

upload will be useful for opening new wikis (& is it needed to revert upload vandalism? or is that reupload?)

For the rest, they are only included because they appear for sysops at Special:ListGroupRights & can likely be removed. I'll do so now.  — Mike.lifeguard | ^@en.wb 16:13, 12 October 2009 (UTC)

Will global sysops be helping out with the setup of new wikis? Not trying to be argumentative, but I was under the impression that this role would be strictly janitorial.

I would also like to see at least some mention in the policy about the addition of new rights, even if it is something like "stewards can do it whenever by discretion." --MZMcBride 07:06, 13 October 2009 (UTC)

Probably yes. I consider that to be in the same "janitorial" category as uncontroversial maintenance like non-urgent speedy deletions. I don't see why adding new userrights needs to be mentioned - presumably it'd be a discussion & consensus-building on this talk page, as in the past.  — Mike.lifeguard | ^@en.wb 21:39, 15 October 2009 (UTC)

correct me if i am wrong but from what i read on the proposal page it is only to be given to small wikis with only a few administrators, surely if there are a few administrators then you dont need to have global ones to patrol them as you have Stewards who can just go onto the wiki and delete anything that may be counted as vandalism and what not? Corruptcopper 18:36, 13 October 2009 (UTC)

Well, you are wrong ;) Not in what you read, but in your conclusion. The point of this proposal is to enable a new user group who can assist the stewards at these small projects with low activity and few active local sysops. For the same reason we have global rollback and projects like swmt. There's a lot work to be done, more than the stewards can handle without help. Regards, Finn Rindahl 20:33, 13 October 2009 (UTC)

language restriction

It could be a little bit harder technically to apply, but i think the proposal for a global sysops will make more sense and will be more efficient if it was based on the languages the sysop master. I still can not figure out how should an admin that can not understand some language to delete pages in a wiki of that language? Stewards have been doing the work in small wikis of deleting speedy pages, but even though it is still uncertain because that deletion is; in the most cases, based on the user who nominated the page for speedy.

In short, If such a glabal sysops is to be granted i would strongly ask for being restricted to language domains that the nominee can understand if not on a native level, at least on a skillful level. --Ciphers 10:34, 14 October 2009 (UTC)

Remember, what you ask is a great deal since it is not possible to master hundreds of languages. And GSes will only use the tools in clear cases of vandalism. Remember, even stewards perform actions; but they do not know all the languages. And, I repeat, GSes won't do maintenance work. They are for emergencies only. Pmlineditor ∞ 10:37, 14 October 2009 (UTC)

Indeed, all of this is "asking a great deal since it's not possible to master hundreds of languages." The show/hide list above includes many languages of smaller wikis with 3-4 active and fluent admins, and several good and fluent editors, that need no further admins who aren't literate in their language, and don't even know about this proposal to opt out of it, since a notice of the proposal has not yet been translated into any language other than English. If these medium-active wikis are included by default, then the scope is far too encompassing and the default level needs to be tightened. The wikis that are seldom ever used by speakers at all, are really the ones where vandalism accumulates. Otherwise, I do not see the real need for this much extra power just to deal with that stewardship problem. 141.152.31.39 16:22, 14 October 2009 (UTC)

They can opt out on their choice. I think a notice for these wikis will be useful though. Regards, Pmlineditor ∞ 16:24, 14 October 2009 (UTC)

Yeah, people are currently working on translating notices to be placed on wikis of other languages. Tiptoety ^talk 16:29, 14 October 2009 (UTC)

The wikis with 3 active sysops are the ones that I feel ought to be dropped from the default. Surely 3 active local sysops can handle a wiki and know what is going on, without need for a global one. 141.152.31.39 16:36, 14 October 2009 (UTC)

That's there decision. I've edited on few small projects with about 3 admins which are constantly in need of more. So I'm not in favor of this idea. Pmlineditor ∞ 16:38, 14 October 2009 (UTC)

<-The only real goal of the group is vandalism and to be totally honest while an understanding that your dealing with languages you don't understand is very important actually understanding those languages is much less so for many reasons:

• An enormous portion of the actual vandalism is IN English.
• An enormous portion of the vandalism that isn't in English is fairly obvious: lots of 1 word articles, replacing large articles with just random letters (such as aslkjasioupdh) or with SHOUTING text for example.
• The advent of computer assisted translation can be huge, I have a button on my toolbar for example that can translate the whole page of most wikis for example, or you can switch to another tab and find a translator. I know when doing anti-vandalism patrol myself I know that I would never think of tagging or reverting a page unless I was sure it should be done, and everyone I've seen does the same. If that means that you have to pause to ask someone who knows the lanaguage or to figure more out then so be it. Sometimes we probably let things slide but thats better then hurting a small wiki by some unseen hand removing things.

In the end they need to have a "clue" and be able to understand how to interact with smaller wikis, not necessarily to be able to write/speak the language that is being worked on. About the size limit. I personally think the current default rules are pretty good. If they have 7-8 active admins they have enough that once we get the word out they can opt out if they want to just like any can, but even just looking at the smaller simple english projects for example that have 4-5 admin who are all fairly active AND a largish group of people who see edits there as they patrol the seWiki and you still have large vandalism attacks with no admin whatsoever around.Jamesofur 18:39, 14 October 2009 (UTC)

Please be aware that even enwiki has had steward intervention in emergencies in the past when no locals were available. I think the guidelines for where this will apply by default make sense in that light. It is entirely possible that 3 sysops is plenty for a wiki's day-to-day maintenance, but when something urgent happens, the likelihood one of them will be available is quite low. It is that gap that global sysops are meant to fill.  — Mike.lifeguard | ^@en.wb 22:51, 15 October 2009 (UTC)

CentralNotice/Global sysops

I've started a CentralNotice, given that we all seem to agree it's the most logical step from here. I've not made a template in the CentralNotice admin yet; in fact, it'd probably be better if someone else did that, because my CSS is quite weak. —Anonymous Dissident^Talk 23:21, 14 October 2009 (UTC)

Oh, and I just assumed that we would end up conducting a vote – I don't see any other way of doing it. My feeling is that we don't need to make it a software vote. What do people think about making a Global sysops/Vote page and just having people sign their names? —Anonymous Dissident^Talk 23:25, 14 October 2009 (UTC)

Works for me. ++Lar: t/c 16:33, 15 October 2009 (UTC)

Works for me as well. Barras 16:50, 15 October 2009 (UTC)

Sounds good. –Juliancolton | ^Talk 21:43, 15 October 2009 (UTC)

• No problems. Pmlineditor ∞ 16:52, 15 October 2009 (UTC)

Sounds good to me. Razorflame 00:21, 16 October 2009 (UTC)

Go for it. Tiptoety ^talk 00:51, 16 October 2009 (UTC)

For the /vote page, do we want a comments section or just oppose/support sections with a link to here for comments? I was thinking I (or anyone else who's bored) should make a page header so that it can start being translated. Jamesofur 01:41, 16 October 2009 (UTC)

I think that the !vote should have just a comments section where the people who are !voting have to give a reason for the way they !vote. That way, it is more about consensus than just a straight up vote. Razorflame 04:18, 17 October 2009 (UTC)

If the people have to give comments, so not many people will participate. Remember, that this vote will be multilingual and many people with different language skills want to participate. For most people it will be easier just to vote instead of writing different/long comment via a google translation that no one can understand. Barras 09:02, 17 October 2009 (UTC)

No need - let people specify the reason in their !vote itself. That'll be easier and the result will be the same. Pmlineditor ∞ 09:07, 17 October 2009 (UTC)

(<-) And anyway, I think most people state their reasons when they vote. Barras 09:50, 17 October 2009 (UTC)

Explaining why you support or oppose makes it a !vote rather than a vote. In a !vote, one can't simply say  Support or  Oppose Pmlineditor ∞ 10:13, 17 October 2009 (UTC)

There is no need for comments under vote. It´s voting and not a discussion. The discussion can be maded here. In case of comment possibility, there will be a discussion of pro and contra on the voting page. Fix all here, make central notice for discussion before voting and than let vote, or make a subpage for comments and questions like steward ellection. --Seha 10:20, 17 October 2009 (UTC)

• There will be too many participants from too many projects to do anything for which consensus-based evaluation is an option. This is a vote: support, or oppose. That's the way most Wikimedia-wide surveys and requests for input are conducted. —Anonymous Dissident^Talk 12:05, 17 October 2009 (UTC)

  Either way, I believe there should be a comments section, or will they put comments here? Pmlineditor ∞ 12:08, 17 October 2009 (UTC)

Sure why not. Central notice with Make a comment about implementation and election rules of global sysops user group for 14 days will be enough. If someone want to comment, so he can comment, if not then start election. In other way, if someone wants to ask a candidate about something, then we can make a candidate subpage for questions like on steward elections. After answering (if someone is not sure how to vote) the voter can vote and it´s done. --Seha 12:35, 17 October 2009 (UTC)

• If anyone likes to make comments, they can use the discussion page (talk page) to do so. Barras (talk) 12:36, 17 October 2009 (UTC)

regular-local

This is the list of permissions with explanations which global sysops have. The permissions are nearly identical to those of regular administrators, however, these permissions apply to any Wikimedia Foundation project that has not opted-out of global sysops' access list. Global sysops also have access to Special:GlobalBlock, which regular administrators do not have access to.

I think that local will be better. All of them are regular :)--Seha 10:23, 17 October 2009 (UTC)

Not really. Global Sysop group is different from the so-called regular group. Not that it matters though. Pmlineditor ∞ 10:26, 17 October 2009 (UTC)

Yes, but there is a translation problem. In de/bs/hr/sr (and other languages) regular can be only translated as normal, and it seems that the other ar not "normal" :). In this case the only different is global and local, so I think we can put local in. --Seha 10:32, 17 October 2009 (UTC)

I agree with Seha. Global sysops are a kind of regular admins, just with other rights. The word 'local' fits better, I think. Barras 10:37, 17 October 2009 (UTC)

I see Seha's point. Pmlineditor ∞ 10:43, 17 October 2009 (UTC)

I gonna change it in bs and de, but en should be changed by some native speaker. --Seha 10:52, 17 October 2009 (UTC)

Done Pmlineditor ∞ 10:54, 17 October 2009 (UTC)

en need to be published again, so all other need to be changed to local. --Seha 11:01, 17 October 2009 (UTC)

Steward upgrade

Shouldn´t stewards be upgraded, encouraged or requested to intervene in small projects instead?
As far as I understood (if I´m not wrong), global sysops are needed for workshop in small projects maybe due the lack of intervention of stewards (maybe they actually can´t, but I can not tell that). So, instead of creating global sysops, why not improving current or new stewards to act in little projects? - ☩Damërung ☩. -- 21:11, 17 October 2009 (UTC)

Unfortunately, while there may be about 35 stewards, many of them are inactive. SDs wait for weeks and even months. Even if we elect stewards, there will always be a need for Global sysops to assist them. Pmlineditor ∞ 09:31, 18 October 2009 (UTC)

Also look at the top of the page. Pmlineditor ∞ 11:29, 18 October 2009 (UTC)

Reducing the number of automatically included wikis

I suggest to not automatically include wikis with 6 or more admins, nonwithstanding that those may opt in. I suggest to keep the number of active admins, which is the more important figure anyways. --Purodha Blissenbach 00:26, 23 October 2009 (UTC)

Yeah, I don't see why we should include some wikis that are fairly decent in size, such as ones with more than 6 active administrators....otherwise, global sysops might start to get into conflicts more and more often with those Wikis that are >6 active administrators. Razorflame 04:19, 24 October 2009 (UTC)

Personally I think it's better set at 10, active admins may not be a problem (and they can opt if they prefer) but looking over the wikis it isn't rare at all that a wiki with 7-10 administrators still has at most 1-2 active ones (if that) and even if they are very active they are usually still vulnerable for a good portion of the day because the administrators aren't around all of the time. If they only have a couple administrators but they are all active and they don't want our help then it is likely they will have the organization and drive to opt out. On the other hand if a wiki has 8 admins and with 7 who haven't been on since 2007 and 1 who comes on ever couple weeks it's going to be hard for them to come to the conclusion to opt in. Jamesofur 16:40, 27 October 2009 (UTC)

I'm perfectly fine with 10 admins. If projects have to opt out, they do by their choice. If the project is large enough, it won't take much time to get enough activity on opt-in/out proposals anyways. Pmlineditor ∞ 16:59, 27 October 2009 (UTC)

Vote Page

Since we're moving at herd of turtles pace I thought I would try to get the vote page set up. My biggest question is if it would be enough to just have the two sections (support/oppose) and a link to here or should we have a more in-depth header that gets translated. As a quick idea for a (probably translated) header:

Thank you for coming to vote on the proposal for Global Sysops. If you have any questions you are invited to join the discussion currently being held at Talk:Global sysops. To vote in support please press here, to vote to oppose please press here.

We would probably want to set up an automatic template with # {{support}} or explain it, either that or just have people go in when they get a chance to make sure it gets formated in an easy to read meathod.

The other question that would arise would be the requirements to vote, should we just say any named, SUL account? We could Even just any named account or have a bit more indepth requirements like elections. Jamesofur 16:28, 27 October 2009 (UTC)

For the requirements, I'd like to propose:

• 1 month of activity on any WMF projects.
• Minimum of 50 edits.

I believe this will minimize the risk of sockpuppets !voting. Regards, Pmlineditor ∞ 17:19, 28 October 2009 (UTC)

To minimize the votes of newbies, i would say that we can put a limit with 500 edits on any project. 50 edits are done in few minutes. --WizardOfOz 21:52, 29 October 2009 (UTC)

I agree, 50 edits sounds too less. I think 250 as a minimum or better more. But 50 is clearly not enough. Barras 21:56, 29 October 2009 (UTC)

Or perhaps 250 in main space. Thats where the user know what a sysop do. 50 edits can be maded on talkpage too. --WizardOfOz 22:06, 29 October 2009 (UTC)

Vote

I've started up Global sysops/Vote. We will now need to discuss the dates and the user requirements. I've proposed 50 edits on at least one project and three months' registration, a threshold I'm confident will flush out all sockpuppeting and will ensure participants have enough familiarity with the workings of Wikimedia to form an intelligent opinion on the proposal. Translations will be required at Global sysops/Vote/Introduction. Hopefully the green plus symbol and red oppose symbol will be as functional on the main vote page as they were during the 2009 steward election, and we won't require translations of "Yes" and "No". Please tell me what you think, put forth dates, and discuss the requirements. —Anonymous Dissident^Talk 13:29, 29 October 2009 (UTC)

Oh, and we'll need to determine the support:oppose ratio needed to pass the proposal. 80% sounds good to me. —Anonymous Dissident^Talk 13:33, 29 October 2009 (UTC)

Looks good to me... and 80% seems fine. I'm not sure about a date; but it should be sometime soon. Pmlineditor ∞ 17:43, 29 October 2009 (UTC)

Sounds reasonable to me. –Juliancolton | ^Talk 17:52, 29 October 2009 (UTC)

Sounds reasonable to me as well. I would like to recommend a voting time of maybe 3-4 months (6 months maximum) to allow for as many people to voice their opinions on this process as possible. Good idea? Razorflame 21:07, 29 October 2009 (UTC)

3 months would be ok for me, but 6 months is too long imo. Barras 21:11, 29 October 2009 (UTC)

3–4 months? Far too long. I don't think we've ever staged a vote that long. I think one month is more reasonable, and even then it's a stretch. We got massive participation in the 2009 steward election with just three weeks. —Anonymous Dissident^Talk 21:23, 29 October 2009 (UTC)

Yeah, it should be less than one month in my opinion. Three weeks sounds good, since we really don't want this to drag on. –Juliancolton | ^Talk 21:34, 29 October 2009 (UTC)

Yep, ok. Three weeks sounds good to me. Razorflame 21:43, 29 October 2009 (UTC)

I think three or four weeks are enough. --WizardOfOz 22:07, 29 October 2009 (UTC)

I propose that the vote begin either tomorrow or on the first of November? Everyone or anyone agree with this? Razorflame 23:17, 29 October 2009 (UTC)

Let us make the rules for voting first and than start voting. Take a look on the section above. --WizardOfOz 23:20, 29 October 2009 (UTC)

Agreed. I think December 1 might be a better idea, actually, so we can work out the details and finish translations. –Juliancolton | ^Talk 23:56, 29 October 2009 (UTC)

December 1st sounds like a great idea. Cheers, Razorflame 00:48, 30 October 2009 (UTC)

OK, so:

• Voters must have 50 or more edits on any WMF project, and must have had an account for three months before the start of the voting period.
• Voting will start on December 1, 2009 and end on December 22, 2009.
• 80% in support is needed for the proposal to be considered "successful".

Sound good? –Juliancolton | ^Talk 00:56, 30 October 2009 (UTC)

Ok, but please clarify what you mean by "end on December 22" - 23:59, 21 December or 23:59, 22 December? After last stewards election I know that is understood differently... vide. LeinaD (t) 01:12, 30 October 2009 (UTC)

I think December 21st at 23:59 is best. Razorflame 03:55, 30 October 2009 (UTC)

• I've gone ahead and posted the times 00:00, 1 December 2009 (UTC) and 23:59, 21 December 2009 (UTC) on the vote page. We've a month to translate that message and the CentralNotice. —Anonymous Dissident^Talk 06:51, 30 October 2009 (UTC)

  I'm only es-2, but I would be willing to try to translate some of it to Spanish, although most likely, I won't be able to translate the entire message. Razorflame 13:02, 30 October 2009 (UTC)

  es has already been done. —Anonymous Dissident^Talk 13:31, 30 October 2009 (UTC)

Do we think 50 is enough edits? It just seems like a very very low number. 150 or 250 may be a better one, 150 sounds good I believe thats what they use for CU/OS elections on En.Jamesofur 21:46, 30 October 2009 (UTC)

I tend to agree here. 50 edits are too low in my oppinion. I think that 150/200 edits are OK. Thoughts? —Dferg|^disputatio 21:04, 30 October 2009 (UTC)

Eh, maybe 150 at most. I think we should try to achieve maximum levels of participation with this vote. –Juliancolton | ^Talk 22:38, 30 October 2009 (UTC)

150 implemented. —Anonymous Dissident^Talk 06:13, 31 October 2009 (UTC)

I'm wondering about using the following rules from steward's elections:

• either have an account on Meta with userpage linked to your homewiki, and a link to your meta account from your homewiki userpage
• or have a linked SUL account;
• not be a bot.

IMO It could be practical to conduct the voting. LeinaD (t) 12:53, 31 October 2009 (UTC)

I´m still for more than 500 edits or 250 in main space on any project, unified account, metapage, not a bot. 250 Main space edits will show that the user know what he vote about. 50 Edits on a talk page can be done by sockpuppet. Or we can take the same rules like for steward elections. --WizardOfOz 16:15, 31 October 2009 (UTC)

Mainspace? Try to think outside Wikipedia, plz. -- Lavallen 17:39, 31 October 2009 (UTC)

Thats what 500 edits are for. --WizardOfOz 18:37, 31 October 2009 (UTC)

<--I don't think we need that many edits for this to be honest, This is mostly about much smaller projects overall which includes ALOT of non-wikipedia projects (I believe the majority will be). Someone who has been involved in a small Wiktionary wiki and created say... 75 entry's should most definitely be allowed and encouraged to vote for/against this because they generally have had time to see how their project work. There is no way they would have gotten 500 edits and likely would not have 250 mainspace edits. Jamesofur 06:52, 1 November 2009 (UTC)

Also side note, Pathoschild said he would set up his tool so that people can verify they are eligable once we have the requirements set up, do we want to put a line to get translated similar to the Steward elections? (You can click here to find out if you are eligible, or similar) We could also just copy that particular line FROM the steward election I would imagine,Jamesofur 07:00, 1 November 2009 (UTC)

What is the current status of this? I would really like to see the ball get rolling here. Is there anything I or others can do? Tiptoety ^talk 20:08, 14 November 2009 (UTC)

For some reason, we are waiting until December 1 before voting here. NW (Talk) 21:13, 14 November 2009 (UTC)

Main issue with edit counts are, 50 quality edits are better than 500 low quality edits. For example, WP:REVERT, anti-WP:SPAM, WP:TALK etc. shouldn't be counted in edit count in the first place. Wikipedia has high number of lazy editors, who WP:AFD, WP:POV WP:REVERT etc. all the time to raise edit count, but actually doesn't contribute to the project at all while bullying the new or IP editors who try to contribute. Kasaalan 21:08, 8 January 2010 (UTC)

future

What is next needs to be planned as this will be vague

Can you explain what you mean? If the vote is successful, this will be implemented in the wikis which meet the criteria for inclusion. Regards, Pmlineditor ∞ 15:04, 30 October 2009 (UTC)

Well the next step would be to have the first set of global sysop elections, after the first ones are in it would be implemented like Pmlineditor said. Jamesofur 21:46, 30 October 2009 (UTC)

Global sysops

 I agree to all terms. at this point! Ebfrz

A last question

Could someone explain better what does it mean Projects may opt-in or opt-out at their own discretion if they obtain local consensus ?

I understand that project could "opt" or not for global sysops. But that seems in contrast with the first two points. Thank you, --Dragonòt 21:36, 6 November 2009 (UTC)

You can held a local vote if you will allow or not the global sysop group on your wiki. If your project is not automatically in the system that global sysops can perform admin action, so you cn with local agreement decide to enable this on your project and the global sysops can help on your wiki. If your are automatically on the list of the wikis where global sysops could be helpful and you don't wish that they act on the wiki, so you can make a vote (locally) to opt out. This means the global sysops have no admin right on this wiki. I hope you understand this now better. Barras 21:41, 6 November 2009 (UTC)

Thank you, now it's clear to me. --Dragonòt 17:16, 7 November 2009 (UTC)

Project criteria:

I hope You are not following this list when You are going to find out which projects fits the criteria:

• fewer than ten administrators exist; or
• fewer than three administrators have made a logged action within the past two months.

On that list, I found that we (svws) has 4 active sysops. (We do not, User:Kapten Kaos has been inactive for almost three years.) No big issue for us, but it looked even worse with svwq. They have 10 local sysops, but only one is active. Some of them have never done any sysop-action at all. You can't see that on the above list. (Most of them are to some extent active on svwp.) You find vandalism on svwq almost every week.

Exactly what is a logged action? Is it an edit or a sysop-action. (Delete/protect/block). There can be two months on svws, when I don't need the sysop-tools, except for the suppressredirect. It was for the suppressredirect I asked for he sysop-tools on svws. -- Lavallen 09:33, 8 November 2009 (UTC)

--Ptw007 06:36, 9 November 2009 (UTC)I am ptw007 and affinanti--Ptw007 06:36, 9 November 2009 (UTC)

Hi Lavallen, I apologize for no one responding to you for so long, I keep meaning to and then end up doing something else before I finish. I know that list was basically thrown together as a rough overview and won't be what we use when we're setting up the actual list, I have a feeling that we'll end up actually having to check the data one by one to make sure (and possibly put a notice up on each wiki so that they know it is happening). As to what is a logged action I think that the general term is used for Delete/protect/block and I don't think suppressredirect counts as you say (though I could be wrong I'll have to look). I know I personally would call an admin active if he's still editing at all it may have to be a little bit of a judgement call and I would say we should ask the community, in the end if they say yes or no we'll follow that decision regardless of the amount of sysops there. ps. I'm going to leave a note on your talk page since this took so long. James (T|C) 03:47, 11 December 2009 (UTC)

concerned, reserved and do oppose

Hi every body ,frankly I am not pleased with this proposal, Feels concerned and reserved about this proposal.

I have been supporting small language wikis(languges that I know) for last few years,Present support level about stopping interwiki spamsters (How it is working I do not know) but has been quite effective. I have seen, observed and studied interventions many times SWMT teams , while their intentions are good ; First of all I am always against outside intervetion in specific languge wiki unless called for by community from concerned wiki.For an example languges like Sanskrit and Pali are classical languges Indian and asian wikipedian keep visiting them once in a while ,some thing is written in local script and how do you make decisions about its relevance and contents sitting at meta.

Secondly may be wikipedians from small wikis are less educated about wiki syntax but unlike big wikis (and interwiki spamsters) usually percentage of local level deliberate vandalism and spamming is almost null and ignorable.

I feel wikimedians need to work more on the level of increasing more reach and participation from concerned communities find and invest more time on that rather than clipping the wings of small

This proposal is to send big birds to wipe out nests of small birds if they create their nest at wrong place in their woods.Please let these birds learn on their own ,Please Please avoid proposals of sending big birds may be thier intentions are good,first of all they will freighten small birds and turn them away from woods of wikimedia.

Mahitgar (He who knows ,wants to know and and loves to keep others informed) 06:34, 23 November 2009 (UTC)

I love your bird nests analogy. Thank you. John Vandenberg 13:40, 8 January 2010 (UTC)

January 1

We can forget about it for December 1. Not nearly enough translations have come through. —Anonymous Dissident^Talk 04:50, 28 November 2009 (UTC)

So we don't have to retranslate (December -> January), we could opt to start the vote on 31 December. That would require only a numerical alteration of the translations. —Anonymous Dissident^Talk 14:30, 30 November 2009 (UTC)

We could just use a dictionary for that, shouldn't be a problem. I don't think it really makes a difference, but I'd just start it 1 January. I guess there won't be many votes on either 31 December or 1 January, but the vote will run for three weeks, right? --Erwin 19:00, 30 November 2009 (UTC)

I'll submit Finnish translation of this content page by 5 December 2009. –Ejs-80 19:36, 30 November 2009 (UTC)

Done. –Ejs-80 21:30, 30 November 2009 (UTC)

Do we really need 3 weeks? Given past experience both in terms of running the election and attracting voters, wouldn't 2 weeks be sufficient?  — Mike.lifeguard | ^@en.wb 02:34, 1 December 2009 (UTC)

I'd think so but I think people had concerns that 2 weeks was to short to get enough people from small wiki to know what we were doing? Jamesofur 02:39, 1 December 2009 (UTC)

We chose three weeks because it seemed to work well for the Steward election. In reality, the implications of this proposal are approximately as far-reaching. —Anonymous Dissident^Talk 02:57, 1 December 2009 (UTC)

I know it is nowhere near as good as human translation, but if there really is a need, would machine translation (babelfish/google) be better than nothing? -- Avi 16:36, 1 December 2009 (UTC)

Yes, we can not keep delaying this because of the lack of translations. We either need to find mutable users to perform the translations or do the best with the resources we have. Tiptoety ^talk 06:27, 2 December 2009 (UTC)

By the way, time period “from 00:00, 1 December 2009 (UTC) to 23:59, 21 December 2009 (UTC)” mentioned in Global sysops/Vote/Introduction has been translated to several languages, so those translations should be updated if the vote will be postponed. –Ejs-80 07:13, 2 December 2009 (UTC)

Can we change the main page (Global sysops)'s English translation status to published? We have no "set" source text to translate from. GrooveDog 21:17, 4 December 2009 (UTC)

Done Jamesofur 02:24, 7 December 2009 (UTC)

Any progress?

Seems like this has lost momentum... –Juliancolton | ^Talk 16:05, 10 December 2009 (UTC)

As you see above I think we were trying to get more translations, It doesn't look like a ton are forthcoming sadly and I think we need to start it in the next couple weeks sort of regardless. I don't know if we want to do the machine translation root? Personally I almost would say leave it at English since the Machine translations are hated by so many small projects but I also want to make sure as many people as possible can read it. James (T|C) 03:48, 11 December 2009 (UTC)

On the other hand, at least machine translations will deliver the main message; having just English will disenfranchise many of the smaller wikis, I would think. -- Avi 16:53, 14 December 2009 (UTC)

December 23rd

So it's fairly late now, I know that the plan was to start this on January 1st (and that i what we currently have in the translations for the vote) everyone ok with that? The other question is do we have enough translations? The question has come up if we want to do some machine translations to give additional options for smaller wikis when we haven't been able to get a hand done translation yet.

Currently for each page we need translations of:

• Global Sysops (main policy page):
  • 8 fully translated and published translations
    • bs,en,fi,it,ms,pl,pt,ru
  • 8 translations that are in need of proofreading before they can be published:
    • de /Deutsch
    • es /Español
    • fr /Français
    • ja /日本語
    • ko /한국어
    • sv /Svenska
    • zh /中文
  • 4 requested but not started translations:
    • ar/العربية
    • id/Bahasa Indonesia
    • no/‪Norsk (bokmål)‬
    • vi/Tiếng Việt

• CentralNotice/Global sysops (notice to bring people here)
  • 22 fully translated and published translations
    • ar,bs,ca,de,de-formal,en,es,fi,fr,ga,gl,id,it,ja,ms,nl,pl,csb,szl,pt,pt-br,ru
  • 2 translations in need of proofreading before they can be published:
    • sr/Српски / Srpski (translated with machine)
    • sv/Svenska (translated with machine)

• Global_sysops/Vote/Introduction (notice for the top of the voting page)
  • 11 translated and published
    • de,el,en,es,fl,gl,id,oc,pl,pt,ru
  • 1 translated and in need of proofreading
    • sv/Svenska (translated with machine)

As you can see we have a couple that Anonymous Dissident machine translated, if we can get someone who knows the language to take a look that would be great. Are there any other languages we want? Is there anything else that we need to do as we get close to the starting date? James (T|C) 04:17, 23 December 2009 (UTC)