Wikimedia Forum

←Discussion pages

Metapub

Archives→

<translate> The Wikimedia Forum is a central place for questions, announcements and other discussions about the [[<tvar|wmf>Special:MyLanguage/Wikimedia Foundation</>|Wikimedia Foundation]] and its projects. (For discussion about the Meta wiki, see [[<tvar|meta-babel>Special:MyLanguage/Meta:Babel</>|Meta:Babel]].)
This is not the place to make technical queries regarding the [[<tvar|mediawiki>Special:MyLanguage/MediaWiki</>|MediaWiki software]]; please ask such questions at the [[<tvar|mw-support-desk>mw:Project:Support desk</>|MediaWiki support desk]]; technical questions about Wikimedia wikis, however, can be placed on [[<tvar|tech>Special:MyLanguage/Tech</>|Tech]] page.</translate>

<translate> You can reply to a topic by clicking the "<tvar|editsection>[edit]</>" link beside that section, or you can [<tvar|newsection>//meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&action=edit&section=new</> start a new discussion].</translate>

You can reply to a topic by clicking the '[edit]' link beside that section, or start a new discussion

Wikimedia Meta-Wiki

• About Meta
• Discussion pages
• Request pages
• Policies and guidelines
• Information and statistics
• Categories
• Help pages

Participate:

• How to edit a page
• Meta-Wiki discussion page

This page experimentally allows language localisation.

Usurpation policy

IMPORTANT! This vote is intended to reflect the consensus for an old version of the proposed policy (see the initiator's comment below). In the meanwhile, the proposal has changed significantly (changes which made most of the original objections obsolete, but which also made the policy a lot weaker than originally intended). I'm not sure how this should be handled, but it's obvious to me that continuing the voting when its object has changed so radically during voting can't produce any meaningful results. --Gutza 10:55, 5 June 2008 (UTC)
Update: A new vote has been opened for the new version of the policy, please vote here. --Gutza 11:47, 5 June 2008 (UTC)

---

I propose eveybody to vote for new usurpation policy (discussed version), which will be used on all projects which don't opt-out. Vote will finish at 15:00, 30 June 2008 (UTC) — VasilievV ² 14:18, 2 June 2008 (UTC)

I expanded the duration of the vote to one month — VasilievV ² 18:43, 4 June 2008 (UTC)

•  Support — VasilievV ² 14:18, 2 June 2008 (UTC)
•  Support (disclaimer: see the history for my involvement in editing this proposed policy). Daniel (talk) 14:20, 2 June 2008 (UTC)
•  Support I don't see any GFDL problems. We still have a renaming log, so we can say, who has made an edit. --Obersachse 16:11, 2 June 2008 (UTC)
•  Support --Chaos 17:57, 2 June 2008 (UTC)
•  Support iAlex 17:59, 2 June 2008 (UTC)
•  Oppose, see talk page. Furthermore, I believe this matter is not simply a technical, procedural issue, but rather it affects the way we interpret the GFDL license; as such, I strongly believe this is a matter of decision for the WMF, not something the community can decide. We have a renaming log, and we can say who has made an edit -- we're on the inside looking out. How about I change your legal name of my own accord and without your knowledge -- but make sure to write that down somewhere? That's what's being proposed here. Please see the talk page I indicated for a more extensive analysis. --Gutza 14:52, 2 June 2008 (UTC)
• I oppose it as is. The communities should at least be notified and have a chance to opt out before anything be done. I can think of zh-classical: which is very active but has no active bureaucrat. Hillgentleman 16:42, 2 June 2008 (UTC)

  Of course we will notify local communities. That's not a point — VasilievV ² 16:44, 2 June 2008 (UTC)

  Then please state it explicitly on the proposal. Stewards should ask the community before any usurpation. You may think that it is obvious now, but there is no guarentee that new stewards who simply look up the policy would not forget this point. Hillgentleman 00:56, 3 June 2008 (UTC)

• Neutral Gutza played a important point. We can decide about this here? Alex Pereira ^falaê 18:45, 2 June 2008 (UTC)
•  Support  – Mike.lifeguard | ^@en.wb 21:37, 2 June 2008 (UTC)
• Neutral The policy is too unclear in some areas for example when we are saying "Doesn't have any edits in the last year and has fewer then 25 edits total" are we talking globally or just within the particular project? What if a user with username "ExampleUser" (without a SUL) has made 26 edits in Japan Wikipedia within one year and 1 edit in English Wikitionary? Would a "ExampleUser" (with SUL) from another project be able to usurp both usernames or just the one in English Wikitionary? --Sin Harvest 03:07, 3 June 2008 (UTC)

  Particular project. Global cannot work because obviously this user doesn't have a gloabl account linked to this username, as the person trying to usurp owns it. As said on the proposal, common sense will be used. Daniel (talk) 03:14, 3 June 2008 (UTC)

  Wouldn't be better to be clear on the outset and have it set in policy? I just have the suspicion that in a few years time this is going to explode out of hand somehow. With people on one hand arguing that this policy grants particular powers and on the other hand other people saying that it doesn't.--Sin Harvest 03:42, 3 June 2008 (UTC)

•  Support It's a good and useful proposal (although the point that people must have an SUL account is quite superfluous). --Thogo (talk) 08:18, 3 June 2008 (UTC)
•  Support --Church of emacs 08:33, 3 June 2008 (UTC)
•  Support --Jón 09:10, 3 June 2008 (UTC)
•  Support --Mordan ( talk - de - de-talk ) 09:39, 3 June 2008 (UTC)
•  Support --Kiensvay 15:23, 3 June 2008 (UTC)
•  Support PDD 16:15, 3 June 2008 (UTC)
• under these conditions  Oppose, although I support it in fact. But. First, just by a chance I saw this voting section, on the usurpation page there is no remark about this voting. Secondly, the wording "which will be used on all projects which don't opt-out" can be understood wrong - when I do not opt out (how and where can I do it???), must I follow it? If you wish so please start a regular voting. -jkb- (cs.source) 18:29, 3 June 2008 (UTC)
•  Support --Roosa _(Talk) 19:05, 3 June 2008 (UTC)
•  Support Very reasonable and commonsense version. Миша13 19:10, 3 June 2008 (UTC)
•  Support -- ※   JéRRy   ┼   雨雨   ※  19:45, 3 June 2008 (UTC)
•  Support Helios 20:31, 3 June 2008 (UTC)
•  Support, Nakon 20:34, 3 June 2008 (UTC)
•  Support seems sane --Werdan7^{T @} 21:53, 3 June 2008 (UTC)
•  Support —YourEyesOnly 04:41, 4 June 2008 (UTC)
•  Support --Euku 09:14, 4 June 2008 (UTC)
•  Oppose (25 edits/year, 50 edits/2years, ... can delete relatively active users, which is not acceptable. It would be OK, if these numbers were more like 2edits/year, 4 edits/2years) --Yyy 09:17, 4 June 2008 (UTC)
•  Support; it may be better after changing the duration of point 5 from one week to two weeks. -✉Hello World! 09:19, 4 June 2008 (UTC)
• support, although I'd affect less contributions. —DerHexer (Talk) 14:20, 4 June 2008 (UTC)
•  Support Jordan Busson 14:54, 4 June 2008 (UTC)
•  Support --Wuzur 16:32, 4 June 2008 (UTC)
•  Support James F. (talk) 17:13, 4 June 2008 (UTC)
•  Oppose I think the duration of the vote is far too short... and unclear to be made into a policy. There are enough ambiguities in this it cause issues. The scope of this is far too broad to be jumping into it. Bastique ^demandez 18:21, 4 June 2008 (UTC)
•  Oppose, while I think something like this is badly needed, imho this should not be decided by a few people. At least all projects mailinglists should have been informed and more time should be given to discuss it. --birdy geimfyglið _(:> )=| ∇ 18:41, 4 June 2008 (UTC)
•  Oppose per Cary & birdy, sorry - not just a Meta issue --Herby ^{talk thyme} 18:54, 4 June 2008 (UTC)

  Note that I already extended the duraion of the voting and made a post to foundation-l — VasilievV ² 19:04, 4 June 2008 (UTC)

•  Oppose section 4 isn't allowed under the GFDL. If an account has edits you cannot rename it without it's agreeement or deleteing said edits and any derivatives of them (which if there are say 100 of them and they are 4 years old is unlikely to be practical).Geni 19:05, 4 June 2008 (UTC)
•  Oppose I'm with Geni on that one. This argument is also going on in foundation-l about usurps on commons. --ShakataGaNai ^Talk 19:14, 4 June 2008 (UTC)
•  Oppose I belive this needs to be discussed more before we do these kind of updates. --Kanonkas 19:23, 4 June 2008 (UTC)
•  Support This is a good policy and appropriate for all projects. Bstone 20:16, 4 June 2008 (UTC)
•  Oppose as per Cary, Spacebirdy, Geni and others. - Kaare 20:19, 4 June 2008 (UTC)
•  Support As it will globally help. --Cream 20:21, 4 June 2008 (UTC)
•  Support I agree this is a good idea. Per cream and bstone e.t.c ·Add§hore· ^Talk/_Cont 20:23, 4 June 2008 (UTC)
•  Support - Makes sense. Sunderland06 20:25, 4 June 2008 (UTC)
•  Support - a good solution. -- (cypsy) 20:50, 4 June 2008 (UTC)

Um the GFDL is not subject to the democratic process. The policy as it standands cannot be adopted.Geni 21:14, 4 June 2008 (UTC)

Finally -- I've been trying to push this since voting began, but nobody seems to listen. --Gutza 21:26, 4 June 2008 (UTC)

•  Support -- but does this mean we need to fork the GFDL? Andre (talk) 21:27, 4 June 2008 (UTC)

No, actually we need to break it. --Gutza 21:31, 4 June 2008 (UTC)

I am not a lawyer. I don't know if you are (are you?) but it seems to me you might not be. I suggest we let the legal question be answered by the WMF's legal guy- Mike. Whatever he says is the official position of the WMF and we should follow his opinion. So, who wants to ask? Bstone 21:34, 4 June 2008 (UTC)

message inserted post-factumNo, I am indeed not a lawyer -- but I have been advocating for forwarding this to the WMF forever (see the first Oppose above) and nobody listened (see all of the "Aye, seems nice" below that). By all means, do stop this process and forward it to WMF! If the legal teams validates it (which I highly doubt), then we can resume this process. --Gutza 22:04, 4 June 2008 (UTC)

Nah it's a standard derivative type question that we deal with all the time. The only franctional complication is that the proposal as it stood would have violated moral rights as well which creates further issues.Geni 21:42, 4 June 2008 (UTC)

There are no mainstreme free licenses that would allow this (well other than releaseing work into the public domain).Geni 21:39, 4 June 2008 (UTC)

• Comment - I am in favor of a policy. This one seems fairly well thought out. But I'm not sure this vote at this time is the best vehicle to get it implemented, there might still be loose ends. ++Lar: t/c 22:36, 4 June 2008 (UTC)
•  Support MBisanz 23:31, 4 June 2008 (UTC)
•  Oppose - per Bastique, it needs more ideas and more input from other wikimedians from the 730 wikis we have since it will affect them the most...--Cometstyles 00:21, 5 June 2008 (UTC)

  IMHO, wikis that don't have bcrat won't have much to say. DarkoNeko 10:22, 5 June 2008 (UTC)

  Wikis, that have a bureaucrat, are not affected by this policy (because usurpation requests there will be handled by local bureaucrat). -Yyy 07:03, 6 June 2008 (UTC)

• neutral. This would be helpful, but, even tho it's a bit more complicated, I'd rather see something among the line of "asking each big wiki (aka thoses with active bcrats) to define the limit they'd allow us to act within". DarkoNeko 09:17, 5 June 2008 (UTC)
•  Support but it doesn't solved any problem with account having bigger edits total... like some account I doesn't want to tell... --Gdgourou 10:47, 5 June 2008 (UTC)
•  Oppose 150 edits is very much. Something around the 5 would be more appropriate. I'm also concerned by the GFDL issues. 83.81.5.126 08:46, 7 June 2008 (UTC)
• Neutral HyperBroad 22:11, 7 June 2008 (UTC) Gostaria de sabre como vai ser em Português.
•  Support Seems reasonable, the SUL needs to move on. Guérin Nicolas     16:03, 9 June 2008 (UTC)
•  Oppose - Too dangerous, see for example the attack of italians against the Wiki-LMO [[1]]. A big wiki can destroy a little wiki: we can look at this message, for example [[2]] : "Mi pare che pms voglia finire come lmo" = "it seems that PMS would be terminated as LMO". Too dangerous. -- Bobig 14:02, 13 June 2008 (UTC)

  Who are you? Maybe a sockpuppet used only to vote? Anyway, you need to study Italian or English. See here: «finire male (fig [=in a figurative sense]) to *come to a bad/a sticky end, to *come to grief, to turn out badly, to *go sour, to end in tears». --Nemo 10:30, 14 June 2008 (UTC)

  And mi pare means it seems to me, IMHO (note for non italian-readers.) --Elitre 12:29, 14 June 2008 (UTC)

  Moreover, that is irrelevant: this policy does not involve any contrib deletion, so your attack is unintelligible and unfair (just trolling). --Nemo 12:45, 14 June 2008 (UTC)

•  Oppose Not sure what I am voting on: this version is clearly illegal. This version is not so bad, but assumes that edits that were reverted quickly thereby are vandalism? That is not a workable definition. - Brya 13:25, 17 June 2008 (UTC)
•  Support --buecherwuermlein 13:40, 18 June 2008 (UTC)

Updated version

[3] — here's another version of usurpation policy. Note that the previous version of the policy is illegal since it doesn't match GFDL requirements (see the talk page; I still want someone from Foundation to clarify this). Thanks — VasilievV ² 11:42, 5 June 2008 (UTC)

• I have a concern... we need to get to a version and then have an up and down comment period, all the comments above I think are not quite valid any more as they are commenting on an earlier version. Let's slow down, get a version that most folk think is right, and THEN put it up for approval. ++Lar: t/c 11:51, 5 June 2008 (UTC)
•  Wait

Absolutely support for this (Lar). As I sated above, the voting is not quite regular if A. it was not announced properly and B. there is no discussed proposal to be voted for. -jkb-  (cs.source) 12:21, 5 June 2008 (UTC)

•  Wait

I support the updated version, if proposed for vote according to voting policies (some discussion and a new announcement). Jérôme 12:36, 5 June 2008 (UTC)

• I am also against this version. See #Notification of the local community below. Hillgentleman 03:50, 6 June 2008 (UTC)

•  Wait

All discussion about the legality of the proposals should only be directed at the WMF legal counsel. We are not qualified to discuss the legality of this and it is unethical for people to opine on the legality without the appropriate credentials. Bstone 20:41, 8 June 2008 (UTC)

•  Wait

WMF legal staff should get the final call on this. -- Da Punk '95 21:50, 14 June 2008 (UTC)

•  Wait

per Lar.--Cato 22:30, 14 June 2008 (UTC)

•  Wait

Lar puts it well. -- Avi 04:41, 17 June 2008 (UTC)

• Well the local community advert got me here, but it's not clear whether there's something concrete to vote on yet. The current version sounds OK to me, but if it's still being discussed shouldn't this vote be closed until things are more resolved. As it is people have continued to vote above after this new section was created, so it's no longer clear what they were voting for. Is legal advice being sought? Really this is a bit of a mess and I vote for closing the vote and starting again! ☸ Moilleadóir ☎ 10:33, 21 June 2008 (UTC)
•  Support We have a more restrictive version of the policy that surely met the legal requirements. It is certainly better than no policy. We need any policy yesterday(then SULs were adopted). Lets adopt the changed version. If the less restrictive policy would be rendered legal then we can vote the less restricted policy but at least we would have some policy meanwhile Alex Bakharev 04:30, 25 June 2008 (UTC)

Notification of the local community

I added that to the proposal. Any objections or comments? — VasilievV ² 07:14, 3 June 2008 (UTC)

It is not clear enough. More than being informed of a usurpation request, the communities should be informed that they can opt out entirely.([4]) Hillgentleman 07:28, 3 June 2008 (UTC)

notifications of this vote to local communities

one of the oppose's reason is that communities are not informed of the current proposal. So, I propose everybody go spread the word about this on their respectives wikis.

Below, add the wikis your spread the info to to the list.

DarkoNeko 09:12, 5 June 2008 (UTC)

• frwiki : fr:Wikipédia:Le_Bistro/5_juin_2008#meta:Metapub.23Usurpation_policy, done by DarkoNeko 09:12, 5 June 2008 (UTC)
• cs.source, 3th June, [5], -jkb- (cs.source) 09:23, 5 June 2008 (UTC)
• pt projects: pt:wp and pt:wn. Alex Pereira ^falaê 14:46, 5 June 2008 (UTC)
• viwiki: [6], done by Avia 04:45, 6 June 2008 (UTC)
• nlwiki: nl:WP:K#Usurpation_policy. --Erwin(85) 14:34, 7 June 2008 (UTC)
• cawiki, done. --Vriullop 18:16, 7 June 2008 (UTC)
• ro.wiki: ro:MediaWiki:Sitenotice. --Gutza 18:49, 7 June 2008 (UTC)
• Simple English Wikipedia (simple.wikipedia) - done -- Da Punk '95 05:37, 14 June 2008 (UTC)
• ga.wiki: ga:MediaWiki:Sitenotice - ga.wikti: wikt:ga:MediaWiki:Sitenotice - Alison ^❤ 08:16, 21 June 2008 (UTC)

GFDL concerns

I think the raised concerned about GFDL violation by just renaming the username should be solved by Experts opinion about copyrights licences .. would anybody who has contact channel with some wikimedia person especially if he is lawyer expert in copyrights to ask him for his opinion ?? --Chaos 21:39, 5 June 2008 (UTC)

Wolof wiktionary

The Wolof Wiktionary is up and running alright. Could somebody please leave a message in this bug: bugzilla:14428 invalidating it? The staus of this should be changed as well.

Please see bugzilla:11512, sorry for not update WM:PCP --Johannes Rohr 11:42, 6 June 2008 (UTC)

Thank you, Johannes Rohr :) Fortunately it took only one day to unlock it. I'll move the last paragraph of my previous message to a new section. --81.39.199.80 13:04, 6 June 2008 (UTC)

I am a bit confused. I see the progress from bugzilla:10707 to bugzilla:11512. As the situation is solved, would not be safer to clearly state it in bugzilla:14428 as well? Or maybe it gets automatically cancelled for the sysops there (sorry if this is a stupid question [I am not totally sure it is not] but I do not know much about the inner cogs and bolts of Bugzilla) in some way I fail to detect? Regards. --81.39.199.80 13:25, 6 June 2008 (UTC)

Why no links to bugzilla with projects already requested to be closed?

I originally left the following comment in the previous section but I am moving it here so that people knowing about it can answer to it. --81.39.199.80 13:04, 6 June 2008 (UTC)

Why information about the request for closure of the project in bugzilla is never (or, at least, almost never) attached in the pages of "Proposals for closing projects" once a closure has been decided? Often it is really hard to properly track the history of this kind of cases. Failing to do it keeps information fragmentary, partial and/or unreachable for many. It becomes hermetic or too much for users who are not meta- or bugzilla-savvy. --81.39.199.80 10:40, 6 June 2008 (UTC)

Save the Siberian Wikipedia!

Please have a look at Save the Siberian Wikipedia. Your comments there will be much appreciated. --SiberianHuskyRyder 21:23, 7 June 2008 (UTC)

Uma reclamação a fazer

Depois que eu fiz a usurpação de contas eu consigo entrar logado em quase todos os Projetos Wikimedia com exceção do Wikispecies e do Wikimania. Alguém pode consertar isso? Pois outros Projetos pode ter o mesmo problema. HyperBroad 16:45, 9 June 2008 (UTC)

Translation: "After I make the SUL, I can login in almost all Wikimedia projects, with excepition Wikispecies and Wikimania. Somebody can fix this? For other projects may have the same problem" —translated by Alex Pereira ^falaê 17:41, 9 June 2008 (UTC).

This is intentional, see bug 14407. Cbrown1023 talk 21:25, 9 June 2008 (UTC)

Só mais uma coisa: Os usuários do Internet Explorer têm o mesmo problema mas resolveram apenas no Firefox. Esse problema tem conserto? HyperBroad 19:30, 13 June 2008 (UTC)

Translation: "One more thing: Internet Explorer users have the same problems but it is only resolved in FireFox. Does the problem have a solution?" —translated by Monobi (talk) 22:04, 15 June 2008 (UTC).

Globally hidden usernames should be hidden locally too, and local hiding of usernames should be possible

Dear all,
hiding global accountnames from the global userlist is possible and makes much sense for very insulting accountnames. (eg. containing realnames or accountnames of respected users and living or dead people)
Renaming them only moves the problem to the renamelog (of course better than the userlist).

In bugzilla:14476 the hiding of accountnames had been requested as feature for local projects too. Imho the local hiding should be assigned to local bureaucrats. Also if an accountname is hidden globally it should be hidden in both userlists, not only in the global one.

Please express Your opinion here.

• I do support such a feature. --birdy geimfyglið _(:> )=| ∇ 13:58, 13 June 2008 (UTC)
• I totally agree with birdy :) ..--Cometstyles 14:03, 13 June 2008 (UTC)
• I agree completely with both these fine people above :) --Herby ^{talk thyme} 14:08, 13 June 2008 (UTC)
• Yes. Cbrown1023 talk 14:09, 13 June 2008 (UTC)
• Agreed, seems like an excellent suggestion. --MiCkE^d_b 17:25, 13 June 2008 (UTC)
• Agree. —DerHexer (Talk) 18:04, 13 June 2008 (UTC)
• fully support, -jkb- (cs.source) 18:39, 13 June 2008 (UTC)
• Yes, absolutely. WjBscribe 19:41, 13 June 2008 (UTC)
• Good and agree --Mardetanha ^talk 19:43, 13 June 2008 (UTC)
•  Support good idea! --Kanonkas 21:23, 13 June 2008 (UTC)
• I also agree Huji 21:56, 13 June 2008 (UTC)
•  Support -Jorunn 22:15, 13 June 2008 (UTC)
•  Support  – Mike.lifeguard | ^@en.wb 00:52, 14 June 2008 (UTC)
• Would be very welcome. On nlwiki we often have to rename users stalking German sysops. Hiding the names would be better. --Erwin(85) 09:18, 14 June 2008 (UTC)
• Yes please. giggy _(:O) 09:28, 14 June 2008 (UTC)
•  Support - no doubt about it. --FiliP × 13:41, 14 June 2008 (UTC)
•  Support Absolutely no reason to oppose this. Majorly ^talk 14:19, 14 June 2008 (UTC)
•  Support — VasilievV ² 17:51, 14 June 2008 (UTC)
•  Support ++Lar: t/c 18:05, 14 June 2008 (UTC)
•  Support it makes a sense. --Aphaia 18:44, 14 June 2008 (UTC)
•  Support Would be useful on EN:WQ.--Cato 22:32, 14 June 2008 (UTC)
•  Support Sounds good. Soxred93 22:57, 14 June 2008 (UTC)
•  Support --Meno25 11:52, 15 June 2008 (UTC)
•  Support --Millosh 12:11, 15 June 2008 (UTC)
•  Support I have a list handy :) -- lucasbfr ^talk 06:56, 16 June 2008 (UTC)
•  Support Good idea. Cenarium (talk) 12:08, 16 June 2008 (UTC)
•  Support common sense--Werdan7^{T @} 23:46, 16 June 2008 (UTC)
•  Support MBisanz ^talk 01:05, 17 June 2008 (UTC)
•  Support Monobi (talk) 01:06, 17 June 2008 (UTC)
•  Support Very useful. Firefoxman 01:07, 17 June 2008 (UTC)
•  Support Nakon 01:22, 17 June 2008 (UTC)
•  Oppose This implementation, at least. Hiding accounts, especially ones that have contributions, is deceptive and unnecessary. If there's an issue with the account names, they shouldn't simply be swept under the rug, they should be dealt with -- permanently. --MZMcBride 03:10, 17 June 2008 (UTC)

  "Dealt with permanently" how? I fail to see how this is sweeping anything under the rug, or how it is not desirable, but I'm sure you can clarify.  – Mike.lifeguard | ^@en.wb 03:31, 17 June 2008 (UTC)

  By reassigning the edits and deleting the account entirely. Currently, two people have the power to do this. Bureaucrats can essentially do this using the RenameUser extension. And sysadmins can do this using their magic powers (a maintenance script, I believe). "Sweeping them under the rug" refers to simply hiding them, which makes the problem go away, in a sense, but doesn't really do so cleanly, and doesn't truly resolve the issue (the accounts still exist). --MZMcBride 03:35, 17 June 2008 (UTC)

  The problem with renaming them is that it simply moves the problem content from the list of users to the rename log. A developer would still be needed to completely remove the data. I think you will find most such accounts have no contributions (or at least only deleted ones). Given that the issue is to some extent a cosmetic one - people unhappy with having insulting names in publicly accessible logs (some are BLP vios in their own right) - "hiding" the names seems to actually resolve the problem without needing developers to deal with every instance. WjBscribe 03:55, 17 June 2008 (UTC)

  As I understand it, hiding the accounts would still leave a log entry. (At least, hiding global accounts currently does.) So, really these bad entries would be moving from one Special: page to another. ; - ) While I understand and sympathize with those wanting to remove the unsightly names from the list, the reality is that this part of the software (Special:ListUsers) functions to list all users in the database, not just certain ones. If the accounts exist, they should be listed (in my personal view, of course). Otherwise, it's revisionistic, in a sense. And yes, while the logs are publicly accessible, they are not indexed by search engines (no Special: pages are). If we want to avoid developer intervention, an extension or some other type of software feature could be written / implemented. There's an extension currently called mw:Extension:User Merge and Delete that could be used, I suppose. Though it also has a log. --MZMcBride 04:05, 17 June 2008 (UTC)

  The comment about logs is a good one. The utility of this feature is considerably lessened if the action is logged unless access to the log is restricted, say to admins only. WjBscribe 23:54, 18 June 2008 (UTC)

  If the devs can device this to work similar to the "oversight logs" or "checkuser logs", it will be better so only crats can remove from userlist, and will only be available for them..--Cometstyles 04:11, 17 June 2008 (UTC)

•  Support Makes sense to me, tools rock. Until(1 == 2) 03:26, 17 June 2008 (UTC)
•  Support Ayuh. -- Avi 04:42, 17 June 2008 (UTC)
•  Support SynergeticMaggot 09:03, 17 June 2008 (UTC)
• Support and I have a list, too; many on my various watchlists and user/talk page histories.
  Cheers, Jack Merridew 11:27, 19 June 2008 (UTC)

  I've struck my support; tentatively. If another solution such as outright deleting abusive accounts can work with the edits reasigned somehow and all licensing issues addressed, then great. The trolls have created a great many accounts that should be put out of the sunshine. Cheers, Jack Merridew 12:31, 20 June 2008 (UTC)

•  Support User names may be offensive ("Johnsmith stinks") and may release personal information ("Anoneditor is John Smith and lives in London"); such names should be hidden.--Poetlister 11:45, 19 June 2008 (UTC)
• Good idea. Acalamari 17:00, 19 June 2008 (UTC)
•  Oppose Hiding doesn't solve the problem, and for accounts with contribs just makes the WP data confusing. MZMcBride's position above is good. Listen to him. --Gmaxwell 23:11, 19 June 2008 (UTC)
•  Oppose per MZMcBride. I'm not sure what simply hiding them solves. Can active accounts be hidden? Accounts with contribs that aren't deleted? I don't think that's a very good idea. What would happen to file histories? Can you even do that without violating the GFDL? I agree those user lists need a good cleaning but this does not sound like the way to do it. What about just restricting the list to admins? Or better yet, deleteaccount. Rocket000 08:34, 20 June 2008 (UTC)

  Hello, please take a look at this and read the introduction of the page, where it says, 'very insulting accountnames', before talking about GFDL and contributions, thanks, --birdy geimfyglið _(:> )=| ∇ 09:17, 20 June 2008 (UTC)

  That doesn't mention what happens to accounts with contribs. People with "very insulting" accountnames can edit constructively too. The GFDL can apply to people with any kind of name. "Very insulting" varies from person to person, language to language, culture to culture, etc. (Even if it's underlined.) How does hiding certain contributers names help anything? It's simply deceptive, non transparent, and unfair. For what benefit? Rocket000 10:26, 20 June 2008 (UTC)

  Nothing happens to them, the ones with contributions should be renamed because of the history. Please have a look at that list I gave You, it is real names, usernames and then You get a idea about what is very insulting and why those can't contribute normally, it has nothing to do with useful contributions. The aibility to hide accountnames already is technically implemented, but only for global ones. If there is something better than that, please go for it, but until then, this should be done. The deletion of accounts will be implementet, uhm, let me guess... never? --birdy geimfyglið _(:> )=| ∇ 10:31, 20 June 2008 (UTC)

  P.S. It is really frustrating that it even has to be discussed that we need the aibility to protect people from such. Talking about useful contributions in that context, to me, sorry to say, sounds rather ridiculous. On some projects they had to modify the MediaWiki messages to hide the old name when they renamed to protect the people, that can't be the solution. --birdy geimfyglið _(:> )=| ∇ 10:40, 20 June 2008 (UTC)

  Ok then, as long as accounts with contribs are not hidden, I support. Looking at the names in that log, would this be considered "very insulting": User:Persian Poet Gal blocks innocent n00bs for no reason!@global. I would hope not. But should it be hidden? If anything is, yes. This doesn't address stuff like that. Or am I missing something? This just seems like censorship for the sake of it rather than doing something useful like cleaning out the user lists. Rocket000 10:43, 20 June 2008 (UTC)

  All right, this is sounding better. Should all accounts that are hidden also be indefinitely blocked? What happens when a non-global accountname is hidden locally and then someone creates the global account elsewhere? Rocket000 10:50, 20 June 2008 (UTC)

  It can't be censorship because it would not affect the version history (so no need to fear license issues), because of that it is unfortunately not a solution for accounts with edits at all. Now there is sul for all, but nothing to prevent those with mailicous intention to bypass local protections. Happy to hear other, better, realizable, ideas, suggestions and solutions, best regards, --birdy geimfyglið _(:> )=| ∇ 12:20, 20 June 2008 (UTC)

  That addresses my all concerns then.  Support. The only suggestion I would make is to have broader definition of what names should be hidden (like I pointed out above it would serve us well to hide some non-offensive names too). Rocket000 12:29, 20 June 2008 (UTC)

• Support --Michail 11:58, 22 June 2008 (UTC)
•  Support if you have a look at these nick's i'll think my support for at least hiding could be unterstood.

The list with 4 offending NOT-nicknames has been commented out and can be seen in the history

--Joergens.mi 20:31, 22 June 2008 (UTC) --Joergens.mi 04:59, 23 June 2008 (UTC)

•  Support Masterpiece2000 09:23, 23 June 2008 (UTC)
•  Support That's a very good idea. --Thogo (talk) 10:13, 23 June 2008 (UTC)
•  Support Definitely needed in certain situations. →Spiritia 22:10, 23 June 2008 (UTC)
•  Support It would be very useful. --Kaaveh Ahangar 02:04, 29 June 2008 (UTC)

Globalização de navegadores web

Os usuários do Internet Explorer, Safari, Opera e outros têm o mesmo problema mas resolveram apenas no Firefox. Esse problema tem conserto? --HyperBroad 00:14, 15 June 2008 (UTC)

Translation: "Internet Explorer, Safari, and Opera users have the same problems but it is only solved in FireFox? Does this problem have a solution?" —translated by Monobi (talk) 22:06, 15 June 2008 (UTC).

Do we know what problem this is referring to?  – Mike.lifeguard | ^@en.wb 03:32, 17 June 2008 (UTC)

See Metapub#Uma reclamação a fazer -- Avi 14:48, 17 June 2008 (UTC)

SUL Question

I successfully created a unified account on the English Wikipedia a week or two ago. I had one concern, however, that I decided to put off until later; that is, my account at wikimania2007.wikimedia.org was not and is not listed in the "automatically identified"/"automatically merged" accounts. I am quite certain that I my password there is the same (I recall logging into every account to ensure that) - anyways, is there a plan to make accounts from old Wikimania sites merge-able? Or I am I missing something and they are merge-able? Any advice would be appreciated. Thanks, Iamunknown 05:54, 15 June 2008 (UTC)

wikimania2007 has the SUL extension not installed, thus You can't merge the account there, it is also not possible to create a new account there, best regards, --geimfyglið :^╡ 06:37, 15 June 2008 (UTC)

Ah, I see - Special:Version lists the extensions, and Central Auth is not enabled at Wikimedia2007. I guess that makes sense, because otherwise new accounts would have to be created there when people with a unified account visit the site. Okay, thanks for the advice! Cheers, --Iamunknown 06:49, 15 June 2008 (UTC)

Global sysops (poll) (closed)

The poll is closed and no further votes will be accepted.
The results of the poll are yet to be announced.

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. For the extensive discussion about the policy proposal, see Talk:Global sysops.

For successful adoption of this policy the following conditions are necessary:

• at least 30 votes in favor;
• at least 80% overall votes in favor, with neutral votes not counting toward the overall total;

Any Wikimedian with at least 500 edits (across all projects) total, and at least 100 edits (across all projects) between January 1 - May 31, 2008 may vote. Voters should have an existing user page at meta with a link to at least one content project. Comments are welcome from all, but votes from those who do not meet the requirements as stated will be discounted.

Support

1.  Support. Additional measures to combat vandalism on smaller wikis would be quite helpful, and I see no serious wikisovereignty issues for the bigger projects. This will provide a large net benefit to Wikimedia. --Rory096 01:42, 16 June 2008 (UTC)
2.  Support. Potentially useful policy. As per Rory096. Yamakiri 01:48, 16 June 2008 (UTC)
3.  Support - Big wikis may not like this, but wikimedia has 700+ wikis interest in hand and this will benefit them a lot..--Cometstyles 01:49, 16 June 2008 (UTC)
4.  Support - it will help the small wikis, and I'm sure it can be disabled on some larger wikis... Monobi (talk) 02:13, 16 June 2008 (UTC)
5.  Support This would help the SWMT and other vandal fighters incredibly and I find the opposes (both below and on the talk page) to not have a strong enough reason (if any) for an oppose. Cbrown1023 talk 04:25, 16 June 2008 (UTC)
6.  Support Definitely. This would really benefit the SWMT and lessen the amount of work that is put on stewards. --Az1568 04:43, 16 June 2008 (UTC)
7.  Support The smaller wikis can really use the help Dbiel 06:37, 16 June 2008 (UTC)
8. --Nemo 06:11, 16 June 2008 (UTC)
9.  Support Beau (talk) 06:26, 16 June 2008 (UTC)
10.  Support Thunderhead 06:27, 16 June 2008 (UTC)
11.  Support SatuSuro 06:32, 16 June 2008 (UTC)
12. Support - I agree that there should be a technical opt-out for the wikis that wish it (simply because I believe in choice) but I also believe this position is of greater importance to the smaller wikis than to let the larger wikis' fears prevent it from adoption. These sysops will have the trust of two communities before they are even eligible for global sysop and I am certain that the voters participating in these nominations will be extremely discerning when choosing global sysops. No single wiki should fear that someone is going to use global sysop-ship to gain access to deleted contributions for the purpose disseminating them because it would be far easier for any individual with such intent to just go through adminship at the local wiki level than through the global sysop process. This project will always be susceptible to abuse, but fear of that shouldn't prevent better operation across the whole of the project. --DeadEyeArrow 07:31, 16 June 2008 (UTC)
13. This is something that would be a very important benefit to smaller wikis & non quite so small wikis. It would help some of the active cross wiki folk to deal with vandalism in a far more efficient way. I realise with the might of en wp getting peeved (most of whom have little idea about smaller wikis, SWMT etc etc) this may not get through without an opt out. However we are talking about a right for people who are already well skilled with the tools & tasks necessary. --Herby ^{talk thyme} 07:45, 16 June 2008 (UTC)
14. Support - Magalhães 09:20, 16 June 2008 (UTC)
15.  Support. I was originally skeptic of this proposal, but if stewards are trigger-happy in removing those users who abuse global privileges in larger wikis, that suffices for me. If a particular wiki doesn't want them, there's the Global sysops/Wikis subpage where individual communities can post "Do not disturb" signs for global sysops. Titoxd^(?!?) 09:24, 16 June 2008 (UTC)
16.  Support. I have passing experience with almost overwhelming problems encountered by a small wiki from spammers and just plain confused users. I understand this to be a measure for those users that specialize in administrating small wikis, per Small Wiki Monitoring Team, and the requirement for Meta participation thus makes sense. I trust prospective global sysops realize the consequences if you try to run roughshod over an established community or violate the terms at Global sysops/Wikis. - BanyanTree 09:38, 16 June 2008 (UTC)
17.  Support - Keeping with the objections raised below, I think it's still a good idea. As pointed out above, there should be mechanisms to prevent global sysop intervention when specifically denied by a project and of course all global sysops should consider the rules of the wiki they are interfering with --SoWhy 10:06, 16 June 2008 (UTC)
18.  Support - as a wikimedia commons admin, this would make my job a hell of a lot easier as we would be able to see deleted images to see whether they ever had useful information which wasn't transferred across. Yes, big wikis won't like this, but big wikis don't like anything because there are enough people that there is always someone willing to be very vocal opposing an idea. Mattbuck 10:16, 16 June 2008 (UTC)
19.  Support (as a proposer) --Millosh 10:25, 16 June 2008 (UTC)
20.  Support --Cradel 10:54, 16 June 2008 (UTC)
21.  Support --GerardM 12:09, 16 June 2008 (UTC)
22.  Support iAlex 12:33, 16 June 2008 (UTC)
23.  Support --Yaroslav Blanter 13:11, 16 June 2008 (UTC)
24.  Support --MF-W 14:34, 16 June 2008 (UTC)
25.  Support after bug 14556 has been submitted, there is no objection, -jkb- (cs.source) 14:45, 16 June 2008 (UTC)
26.  Support Why not simplify the whole system. Interwiki collaboration is in terrific state now.--Kozuch 14:48, 16 June 2008 (UTC)
27.  Support --Fabexplosive The archive man 15:30, 16 June 2008 (UTC)
28.  Support Without this system, a lot of wikis will be under-patrolled. OhanaUnited^{Talk page} 15:38, 16 June 2008 (UTC)
29.  Support Excellent idea - Icairns 15:40, 16 June 2008 (UTC)
30.  Support - this is clearly a sensible way to manage the maintenance of small projects. Use on a large project would lead to suspension of the right so I don't think a technical opt out is needed. I am disappointed that small projects may miss out on the benefits of this right due to opposition mainly from one large project - I don't think this aids inter-project relations or does much for the global perception of enwiki. WjBscribe 15:43, 16 June 2008 (UTC)
31.  Support - Trevor MacInnis 15:51, 16 June 2008 (UTC)
32.  Support - only high quality admins would be able to survive the nomination process. We already trust these people for other major projects, so why not trust them at a global level? Royalbroil 16:03, 16 June 2008 (UTC)
33. Great idea: it will help clean-up and reduce unnoticed vandalism on the smaller Wikis. Acalamari 16:10, 16 June 2008 (UTC)
34.  Support upon the condition that large wikis with enough local admins be allowed to opt out. My opinion is similar to Messedrocker's in the Oppose section, but I recognize that this feature will be developed. Until then, local policies like w:en:Wikipedia:Global rights usage should govern the use of their rights on those wikis. Nihiltres^(t.u) 17:45, 16 June 2008 (UTC)
35. No one will use their rights on the big 'pedias, and if they do, they'll quickly lose them. A technical opt-out method might be nice, but there'll be no trouble either way, methinks. --Conti 18:25, 16 June 2008 (UTC)
36.  Support with the understanding that larger wikis with a sufficient number of sysops will not be affected. Vandalism and spam can be a problem on smaller wikis, and I have wished I or someone else could do something about it without involving bureaucracy. Grandmasterka 18:26, 16 June 2008 (UTC)
37.  Support with the obvious get-outs per wiki as necessary. James F. (talk) 18:42, 16 June 2008 (UTC)
38. Contingent on the opt-out implementations, which have been committed to. —Signed, your friendly neighborhood MessedRocker. 19:08, 16 June 2008 (UTC)

    Thanks! :) --Millosh 19:15, 16 June 2008 (UTC)

39.  Support per many of the above comments; plenty of the smaller wikis do need help, and this seems to be a pretty good way to provide it. The members of those wikis can of course decide for themselves to what degree the global sysops can act (rollback only, protect and block, etc.). My only concern is that global sysops should be monitored to ensure they're following consensus on each wiki. Parsecboy 19:18, 16 June 2008 (UTC)
40.  Support - This should help out some of the smaller wikis. NuclearWarfare 19:22, 16 June 2008 (UTC)
41.  Support - Agree w/ Cometstyles. Cirt 19:33, 16 June 2008 (UTC)
42.  Support - Necessary to address cross-wiki harassment in a timely manner. Durova 19:39, 16 June 2008 (UTC)
43.  Support - I encourage lots of folks to monitor activity (especially early on) to ensure that the program is what we really want. --141.174.97.231 19:51, 16 June 2008 (UTC) gah, logged in to vote. --Rocksanddirt 19:52, 16 June 2008 (UTC)
44.  Support - I have every reason to believe the opt out would be implemented before this was put into practice. ++Lar: t/c 21:44, 16 June 2008 (UTC)
45.  Support I have seen many smaller wikis destroyed because of vandalism. This will help stop it. Mm40 21:59, 16 June 2008 (UTC)
46.  Support Big time - David Gerard 22:01, 16 June 2008 (UTC)
47.  Support, assuming that they will not have any sysop rights on those wikis that don't want them. (I don't believe this actually requires any changes to the software: AFAIK, the devs can already configure the rights assigned to each user group on a per-wiki basis.) --Ilmari Karonen 22:56, 16 June 2008 (UTC)
48. Support Absolutely. EVula // talk // ☯ // 23:05, 16 June 2008 (UTC)

     Support - No doubt. 75.183.127.68 23:07, 16 June 2008 (UTC) Only registered users can vote. Nemo 14:34, 19 June 2008 (UTC)

49. Support - looks ok.   jj137 ^♠ 23:36, 16 June 2008 (UTC)
50.  Support Very useful. --Werdan7^{T @} 23:39, 16 June 2008 (UTC)
51.  Support I do see potentials for abuse, however I have enough trust in the admin selection process that I doubt such abuse will occur. Nar Matteru 00:04, 17 June 2008 (UTC)
52.  Support Support and yes it's an excellent idea. Bstone 00:05, 17 June 2008 (UTC)
53.  Support This would be a boon to small wikis. Firefoxman 00:06, 17 June 2008 (UTC)

     Support I was reassured by the restrictions. 87.194.39.154 01:25, 17 June 2008 (UTC) Only registered users can vote. Nemo 14:34, 19 June 2008 (UTC)

54.  Support: restrictions can be added later, fear of possible "abuse" is unfounded. -AlexSm 02:04, 17 June 2008 (UTC)
55.  Support, with the caveat that I would prefer a longer approval period (two weeks or a month perhaps) rather than a week. Would also like a way to make these kinds of nominations higher profile so they could receive added scrutiny by all projects. —Locke Cole • t • c 02:27, 17 June 2008 (UTC)
56.  Support--_~Innv^s: 03:47, 17 June 2008 (UTC)
57.  Support, with some reservations. I think the policy could still use some work; I worry that this is being pushed through very aggressively by a single user; and I think we need to get increased cross-wiki input (though we do have already the opinions of those who do this work, which are most valuable). With that much said, this policy does have some shortcomings (I am not particularly happy with the editcountitis requirements, for example), but is in an acceptable state. The principle is fine; the idea is great(!) but the proposal is not as good as it could be. In determining any outcome from this, we need to take into account what amounts to canvassing - on the other hand, I think we do need cross-wiki input, especially from non-WP and non-en projects (Is this not what the global sitenotice is for?). Lastly, while defining groups of wikis for which you can define user groups with certain permissions to which you can add global users might be all the rage, social policies should be the primary method of enforcing these things. There's no need to be paranoid about a cross-wiki rampage; we're all acutely aware that this is a serious undertaking, and I have no doubt that the first RFP will set the bar higher than is strictly necessary deliberately to counter this. So while this may be implemented in the future, I see it as quite a misunderstanding of the issues to focus on technical implementation as a check on behaviour.  – Mike.lifeguard | ^@en.wb 03:54, 17 June 2008 (UTC)
58.  Support. Grandmaster 07:11, 17 June 2008 (UTC)
59. Support — This is a fine idea and about 2 years overdue. I don't expect that there will be serious issues with abuse of this (and any cases will be dealt with). Nakal cross-wiki shite is on the rise;^{[7] [8] [9]}. Cheers, Jack Merridew 08:45, 17 June 2008 (UTC)
60.  Support SynergeticMaggot 09:05, 17 June 2008 (UTC)
61. support —DerHexer (Talk) 10:17, 17 June 2008 (UTC)
62. --Euku 10:24, 17 June 2008 (UTC)
63. Less maintenance work for the stewards. Yay. DarkoNeko 10:31, 17 June 2008 (UTC)
64. JacobH 10:42, 17 June 2008 (UTC) Good for the vulnerable small wiki's.
65. Kusma 11:10, 17 June 2008 (UTC)
66. Willemo 11:19, 17 June 2008 (UTC)
67.  Support necessary and useful --Gdgourou 12:06, 17 June 2008 (UTC)

     Support 89.243.255.205 21:35, 17 June 2008 (UTC) Only registered users can vote. Nemo 14:34, 19 June 2008 (UTC)

68.  Support - from neutral, since opt-out will be a technical function (hopefully). --Anonymous Dissident^Talk 12:10, 17 June 2008 (UTC)
69.  Support Finnrind 12:33, 17 June 2008 (UTC)
70.  Support - I don't understand the 80%-rule. So we never can change things, we ever will have a block minority. Marcus Cyron 12:58, 17 June 2008 (UTC)

     Support - This would actually work. I fully support this. 116.71.34.72 13:28, 17 June 2008 (UTC) Only registered users can vote. Nemo 14:34, 19 June 2008 (UTC)

71.  Support --Alex S.H. Lin 13:44, 17 June 2008 (UTC)
72.  Support - it seems that a lot of user do not understand the purpose of this functionality: it is there to be able to respond on mass-vandalism on small projects where no sysops are present to respond to. Romaine 14:26, 17 June 2008 (UTC)
73.  Support - Needed for smaller projects. Impact on the larger projects is minimal anyways. Prashanthns 14:32, 17 June 2008 (UTC)
74. Ucucha 14:28, 17 June 2008 (UTC) Opt-out would be preferable, but I think the advantages of improving vandalism fighting on smaller wikis outweigh the risks that a global sysop will use his privileges on a large wiki.
75.  Support: From the point of view of a Commons admin who cares about image duplicates a global adminship makes a lot of sense. Imagelinks could be fixed even on protected pages, and the version histories of transfered and already deleted images could be checked fast and easy. --32X 14:42, 17 June 2008 (UTC)

    Those tasks are not related to vandalism fighting, so I don't think that would be allowed according to the policy? /Ö 15:42, 17 June 2008 (UTC)

    Some people have the opinion, that deleting still used images is a kind of vandalism. --32X 13:48, 18 June 2008 (UTC)

76.  Support: - Robotje 15:30, 17 June 2008 (UTC)
77.  Support - JoJan 15:36, 17 June 2008 (UTC)
78. Support There are serious issues with inactive admins on the smaller, more obscure projects (chr: is a case in point). The bar for global admins should be set sufficiently high that they are qualified, i.e., they will respect local policy and local consensus, if existent. --Wikiacc | (talk) (en.w | en.w.t) 16:21, 17 June 2008 (UTC)
79.  Support - Wammes Waggel 16:56, 17 June 2008 (UTC)
80.  SupportDendodge 21:05, 17 June 2008 (UTC)
81.  Support As i saw below most of the oposser had a conditional vote which opt-out .so i think after the bug fixed they will take back their vote.--Mardetanha ^talk 21:10, 17 June 2008 (UTC)
82.  Support --Dodo von den Bergen 23:21, 17 June 2008 (UTC)
83.  Support ~XarBioGeek ^(talk) 01:45, 18 June 2008 (UTC)
84.  Support - I can see some potential for problems but it's probably worth the trouble, all said. Shereth 02:23, 18 June 2008 (UTC)
85.  Support MoiraMoira 07:10, 18 June 2008 (UTC)
86.  Support Lycaon 07:12, 18 June 2008 (UTC)
87.  Support - but I really want to see an opt-out policy for small wikis, in the interests of fairness and choice - Alison ^❤ 08:52, 18 June 2008 (UTC)

    Everybody will be happy to see that one small wiki became a mature one. Until that, they are under stewards' patronage, and global sysops should be here to help to stewards. --Millosh 17:59, 18 June 2008 (UTC)

    "under stewards' patronage" — That indeed is something new to me, --birdy geimfyglið _(:> )=| ∇ 18:30, 18 June 2008 (UTC)

    Just to mention that we (Spacebirdy and I) are talking now about this issue at IRC :) --Millosh 19:28, 18 June 2008 (UTC)

88.  Support --alexscho 13:55, 18 June 2008 (UTC)
89.  Support --·Add§hore· ^Talk/_Cont 16:25, 18 June 2008 (UTC)
90.  Support - if you are not fit to be an admin on all wikis, you aren't fit to be an admin on any wiki. ugen64 20:49, 18 June 2008 (UTC)
91.  Support We are OK on EN:WQ now but at one time we had to keep calling in stewards to deal with vandals. This proposal would have been very helpful to us then.--Cato 21:24, 18 June 2008 (UTC)
92.  Support Responsible admins can be of assistance on more than merely that Wiki on which they usually edit. Irresponsible admins will be, I think, rare and easily noticed, in any case. Perhaps a tag on a user name exercising such a privilege to make its global context use easier to see?. When away from the wiki on which one has the most edits? Good idea. Ww 02:48, 19 June 2008 (UTC)
93.  Support as an opt-in/opt-out option with automatic opt-in after a reasonable period of time if there is no decision, and opt-out anytime - Since this only affects smaller wikis, I see no problem with implementing it. I do think it should be opt-in, but with an automatic opt-in on projects that do not make a conscious decision about opting. In other words, each project should make a decision at the local level to opt-in or opt-out within a reasonable time (say a month). If the project is apathetic or too argumentative to reach any decision, then the decision is made automatically for them after the time expires. Later in the project's life, they should be able to rescind that decision and opt-out if they have grown to a point where they can responsibly maintain their own project. Regardless, I support this change. (And, yes, I'm very active on the English Wikipedia--some of us actually read things instead of freaking out and opposing good changes.) --Willscrlt (Talk) 07:04, 19 June 2008 (UTC)
94.  Support with or without technical opt-out. Global sysops can be trusted not to mess with the larger wikis even if it does remain technically possible. Angela 16:20, 19 June 2008 (UTC)
95.  Support Alex Pereira ^falaê 17:47, 19 June 2008 (UTC)
96.  Support Chris 19:01, 19 June 2008 (UTC)
97.  Support As an admin on en:W, i understand that this is usefull and does not apply to the English WP. --Bduke 06:55, 20 June 2008 (UTC)
98.  Support ken123 16:20, 20 June 2008 (UTC)
99.  Support Kameraad Pjotr 09:59, 20 June 2008 (UTC)
100.  Support, opt-in preferred, but it's hard to imagine someone ascending to such a post who would not be trusted to be an admin on most any individual project. BD2412 T 00:40, 22 June 2008 (UTC)
101.  Support VIGNERON * ^discut. 12:16, 22 June 2008 (UTC)
102.  Support. Opt-out would be preferred for the larger wikis with a sufficient amount of admins. bibliomaniac15 22:52, 22 June 2008 (UTC)
103.  Support Give the proper tools to those needing them Platonides 22:59, 22 June 2008 (UTC)
104.  Support --Pietrodn · talk with me 15:15, 23 June 2008 (UTC)
105.  Support Should be useful to patrol and help smaller wikis. Some centralisation will improve efficiency. --Oldak Quill 17:57, 23 June 2008 (UTC)
106.  Support--penubag 23:50, 23 June 2008 (UTC)
107.  Support — E ^talk 11:16, 24 June 2008 (UTC)
108.  Support, Seems like a sensible way to help combat vandalism on smaller wikis. Craig Franklin 10:34, 26 June 2008 (UTC).
109.  Support, of course. This mechanism seems to be a good way to free stewards from some routine work. Kv75 18:39, 26 June 2008 (UTC)
110.  Support as per above. -- Aka 19:56, 26 June 2008 (UTC)
111.  Support - I know this vote is never going to go through, but I support it nonetheless. A lot of comment I have heard are along the lines of "Elect local admins. If there isn't anybody worth enough, there is no point of the wiki existing." Is that even a serious comment? So basically we are going to destroy communities and make them essentially nonfunctional, just because they do not have any worthy admins? Does anybody see how ridiculous that is? Communities may not have possible admins at a given time if they have just started out. We cannot expect every community to instantly have enough people worthy of adminship. We have to give each community time to develop. But until that point, the community has absolutely nothing, except help from stewards, and sometimes temporary admins. This policy would help to distribute power better, instead of forcing a small team of stewards to take on everything. Of course, if this means increasing the requirement, go ahead. Because at a certain point, a user who meets really high standards would not be "power-hungry" or anything I have heard in the oppose section. Parent5446 21:56, 26 June 2008 (UTC)
112.  Support - It can be very useful. Xenus 15:25, 27 June 2008 (UTC)
113.  Support as per above. --Kaaveh Ahangar 02:06, 29 June 2008 (UTC)

Oppose

I cannot support this until there is a technical implementation to restrict privilege use to wikis with few-to-none administrators only. —Signed, your friendly neighborhood MessedRocker. 01:44, 16 June 2008 (UTC)

(This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)

1. Toes will be trodden on, there's no way of knowing how large a community is until you're part of it - at which point you can get a local sysop-hood anyway. Conrad.Irwin 01:54, 16 June 2008 (UTC)

   Er, isn't that why that list of wikis sorted by size and number of admins, etc. was created? I'd expect that any projects that explicitly chose not to have global sysop interference would also be put in a special section on that list, so global sysops shouldn't screw up and use their tools on a project where they're not allowed (and the fact that they'll be autodeglobalsysopped if they do seems like a pretty good incentive to keep them from doing so). --Rory096 01:59, 16 June 2008 (UTC)

   Is this exclusion-from-interference list extant? —Signed, your friendly neighborhood MessedRocker. 02:08, 16 June 2008 (UTC)

   Global sysops/Wikis and Global sysops/Small and large wikis. They're not designed to be quite as black and white as I'd like, but I would expect that to improve as projects pass policies regarding global sysops. --Rory096 02:39, 16 June 2008 (UTC)

2.  Oppose Until Wikis can opt out at a technical level from Global Sysops being able to perform an action and until viewing deleted contribs is separated from restoring accidentally deleted pages. MBisanz ^talk 04:06, 16 June 2008 (UTC)

   Toes may be trodden on in a larger community; I see this as mainly for websites not big enough to have an active community with a sufficient amount of administrators. —Signed, your friendly neighborhood MessedRocker. 05:03, 16 June 2008 (UTC)

   They will never be able to opt out technically, that is not something that we'd want them to be able to... we do not want to restrict any global group. Also, tbh, I think the whole worrying about deleted contributions to be a little crazy... it's not that big of deal, these people are going to be trusted as is. Cbrown1023 talk 04:25, 16 June 2008 (UTC)

3. At a minimum until wikis are able to opt out. I think the general issue of allowing any editor to "patrol" for vandalism in a language they don't understand is problematic. Perhaps a rewritten proposal with more attention to limiting the opportunity for error and abuse, in addition to a clearer definition of the role of these global sysops, would be something I could support. Avruch 04:29, 16 June 2008 (UTC)

   Do you realize that we already patrol wikis for vandalism in languages we do not understand? See SWMT and #cvn-sw... this will just make our lives easier. Wikis can already opt out, see Global sysops/Wikis and Global sysops/Small and large wikis. Cbrown1023 talk 04:35, 16 June 2008 (UTC)

   Sorry if I wasn't clear - I was referring to a technical opt-out, which you say above will never happen. I'm aware that folks patrol for vandalism, but the potential damage from an error is limited to what any editor (and vandal) can accomplish. The characteristics of a small wiki that make a global sysop seem necessary also make it unlikely that errors and other problems from global sysops will be noted in a timely manner. Large wikis will notice a global sysop screwup right away, but at the same time they have no need for global sysops in the first place. I'd like to see a global log of all actions by global sysops, and I'd like to see them technically limited to wikis below a certain threshold of activity, and I think limiting them to rollback and delete should be considered. Once SUL is universal the need for the ability to block on each project could be obviated - a clear vandal could simply be globally blocked by one meta admin. Just some thoughts. I think the poll on this proposal is probably premature - why does it need to go from proposed to voted upon in barely more than two weeks? Avruch 04:45, 16 June 2008 (UTC)

   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
4. Certainly not. The above users, especially Conrad Irwin, have said it well. — Dan | talk 04:57, 16 June 2008 (UTC)
5. I will oppose this until there is a software mechanism to opt-out large wikis. Any claim that this is not 'technically possible' is pure hogwash. --MZMcBride 05:11, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)

   Until opt-out is technically available. giggy _(:O) 05:13, 16 June 2008 (UTC)

   (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)

   OK, I'm happy to indent my vote until that bug is resolved... please ping my talk page when something happens there and I'll take another look. giggy _(:O) 04:38, 19 June 2008 (UTC)

6. There is no real way I can see justifying global privileges like that. It's too much risk of abuse of power, let alone other concerns. --Neskaya 05:22, 16 June 2008 (UTC)
7. The opt out capability (at the software level) for established communities is mandatory. And I mean opt out in advance of the first grant of global sysop privileges. Anywhere that there is an editing community, that community has autonomy over the shape and content of their work, and there is absolutely no guarantee that someone from another project will understand or abide by local policy; if that person is given sysop privileges witout having had any previous interaction with that community, this simply exacerbates the situation. And it's not just a matter of local policy; it's a matter of the community dynamic, which may be wildly different from that of the sysop's home project(s). As someone involed in several non-wikipedia projects in two languages, I'm speaking from direct observation. Assume good faith, all well and good; but many people do *not* wait to learn what the local community is like before leaping in and making decisions (and yes, some of those hasty folks have been sysops elsewhere). -- ArielGlenn 05:26, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
8. Oppose The points made above about the lack of a mechanism to opt-out a wiki make this a deal-breaker as is. OverlordQ 05:43, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
9. Opppose. Badagnani 02:49, 20 June 2008 (UTC)
10. I really like the idea, but like others, I would also like to see an opt-out option. -- Ned Scott 05:48, 16 June 2008 (UTC)
11. Oppose as premature. This can happen only after: 1) The technical infrastructure is in place, 2) Individual wikis have opted in. Personally, I would prefer that the big wikis with enough administrators explicitly stay out of such a scheme for at least 6 months after it starts in earnest. Let those small Wikis who need such a service come up with a policy that works for them and let them have a few months to tweak it. Counterproposal - pick a small number of smallish Wikis to run a common sysop scheme as an experiment for 3 months. If it works, gradually invite other smallish Wikis in. After that is stable, revisit inviting larger Wikis in. Davidwr 05:56, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)

    • Nope. Premature. Show me the money. Or rather the code in action. I will say that I am in favor of allowing two or more wikis, or even "all but one wiki," giving cross-permissions if it is the will of all the wikis concerned. To put it another way: I'm voting no on the proposal, but not because I'm absolutely against the idea. Davidwr 23:34, 17 June 2008 (UTC)
      • Whould you support the policy if its implemenation would delayed until the technical implementation of opting-out? --Millosh 18:04, 18 June 2008 (UTC)
        • Not without a pilot test between at least two wikis that agreed to share "global within the group" sysops. Ask me again after the pilot is over. Davidwr 03:53, 19 June 2008 (UTC)

12. Oppose per ArielGlenn. The points he brings up are quite valid.--Rockfang 06:22, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
      • I will not change my vote just because developers "show intention" to possibly implement something that may happen someday.--Rockfang 00:26, 17 June 2008 (UTC)
        • So, would you support the policy if its use would be delayed until the technical implementation of opting-out? --Millosh 18:04, 18 June 2008 (UTC)
13. Not just because of the ability for wikis to opt-out (which I think is essential) but because I also feel the process is unnecessarily bureaucratic. Just look at the requirements to attain global sysop status: 6 months at Meta and two other content projects, 5,000 total edits, 1,000 edits at one content wiki, 100 edits at a second content wiki, 100 edits at Meta, 50 edits at Meta in 2 months, 50 edits on two different projects within the last month, and administrator, bureaucrat or checkuser status on at least two projects, with one a content project. Frankly, that part of the policy is ludicrous -- if there's going to be voting on the candidates anyway, what's the need to introduce so many complicated rules when voters can weed out candidates themselves? I cannot and will not support a policy that introduces unnecessary bureaucracy, and can be easily gamed. To a lesser extent, I also feel that the process is becoming "steward-lite". Ral315 (talk) 07:25, 16 June 2008 (UTC)
14. Oppose (in the current form), IMHO, this is a function which does need to be fully global, on all wikis. There are types of vandalism here which tread beyond only one wiki, and which may appear minor on single wikipedia. Certain forms of vandalism are vandalism on all wikis. With the backlog which (even on the English wikipedia on en:WP:AIV!) occurs every now and then, and with vandalism (with all the recent changes patrollers, also even on the English wikipedia) which does not get reverted and stays for some time (and not only minutes), and where blatant vandalism with only a few edits would not be stopable as it may not have recurred often enough on a single wiki to result in blocks, the people that do watch the cross-wiki aspects of vandalism should have the possibility to revert and stop such edits when they occur, even on the large wikipedia, and preferably fast so the 'vandal' notices that his edits are of concern! People who get this bit should have a broad support from quite a number of wikis, but also have the possibility to use their powers on all wikis. Abuse should result in their bit being withdrawn, but people seem more concerned about the possible abuse than about advantages. --Dirk Beetstra ^{T C} (en: U, T) 11:01, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
      • (I am quite close to going on a short trip, so I don't have too much time.) Funny that you give me the generic ask as well, you could have noticed that I vote against the proposal for different reasons, so:

        Reply. No, I am not voting oppose because I want the capability to have an opt-out/opt-in system. I do believe that the task 'global sysop' should be global. That is, no opt-out! I know I am the odd one out here, but I believe that the current state of the proposal indeed forces the large wikis to request opt-out. With the opt-out it is just as easy for the stewards to just give some trusted meta-admins with some experience (temp) sysop status to catch the obvious stuff, and it would solve a part of the problem (vandalism to small wikis), but it does not solve the complete problem that we have here.

        What the majority of the oppose votes here want is to remove the global status of the global sysop. Still, the large wikis have to live with cross-wiki vandalism as well. Cross wiki external link 'spammers' perform only a small number of edits on wiki, and would probably not get blocked for that, but if one looks at the total number of edits performed on the project, they would well be over the limit. Now those editors active on such cross-wiki aspects would have to revert using undo (tedious!!!), and go to WP:AIV (where they might get a slow or no response, 'only n (n<5) edits, not a reason to block yet!'). The global sysop should be able to perform actions on such cases, when there is a clear global aspect to the vandalism (including spamming). So:

        • Total global sysop, no opt-out, but,
        • Only allowed to use the global sysop tools when there is a clear global form of vandalism.
        • Voting, only admins (on whatever project) votes are counted (all users allowed to comment), they need a clear majority of granting (80%?), and the group of voters has to contain at least 3 (unique) admins per wiki from at least 15 (?) content wikis. Voting can close after that has been reached, or after 30 days when there is no chance of support.

    So with the opt-out I would still, or maybe even harder, oppose the proposal. Then it is just useless. --Dirk Beetstra ^{T C} (en: U, T) 18:29, 16 June 2008 (UTC)

    Hm. I made a couple of mistakes with putting my generic question and I fixed one of them... I didn't put a generic question because I don't have enough of time for communication, but because the question was same. I could only make different sentences not to make this to look like a generic question :) --Millosh 18:46, 16 June 2008 (UTC)

    You may see that there is a hard opposition to any global permission. While in this moment majority supports the idea, we are very far from the consensus. And I suppose that your idea would have much harder opposition. This may be the first global role. And only when people start to communicate all over the projects much more frequently (cross-wiki cooperation is almost non-existing; with exceptions in the relation *.wp->en.wp (only one way) and some very close languages (but, not all!), like tr and az are). --Millosh 18:46, 16 June 2008 (UTC)

15. Oppose until there is a technical opt-out. —Dark ^talk 11:42, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
16. Oppose until projects can opt out. -- Eugene van der Pijll 12:47, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)

    No. -- Eugene van der Pijll 20:34, 16 June 2008 (UTC)

17. Oppose; same reasons, opt-out option must be implemented first.Ezhiki 13:27, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
18. Oppose; sledgehammer to crack some small nuts, and a dangerous one at that. --Alison Wheeler 14:04, 16 June 2008 (UTC)
19.  Oppose - No thanks, there is nothing all-that-wrong with the current system. If a Wiki has too few administrators then search the current active user list and find suitable candidates to nominate or sysop (depending on the system). If there aren't enough users to do this, i'd question the point of the project in general. This is just a way of increasing power to those who are hungry for it, IMO. Sorry. Cyclonenim 14:15, 16 June 2008 (UTC)

    Do you have ANY real experience to fight vandalism on small wikis to produce such statements? --Yaroslav Blanter 14:26, 16 June 2008 (UTC)

    How is that at all relevant? No, I do not have experience on small wikis but my point was that if you have even a few active, reliable users, nominate them for adminship on your small wiki. If you don't have enough active users then I'd question the point of existence for that wiki. My experience of vandal fighting isn't relevant at all to my point. Regards, CycloneNimrod ^talk?_contribs? 14:35, 16 June 2008 (UTC)

    Well, just looks like you are voicing an opinion on the subject you have no idea of. If things were so simple no vandal fighters would be needed at all. --Yaroslav Blanter 14:38, 16 June 2008 (UTC)

    That is your opinion but may I bring to your attention that this poll is not about the necessity of vandal fighters but about global sysops. I am by no means objective to vandal fighters on smaller wikis, they play a crucial role in reverting vandalism. My point is regarding the necessity of global admins which I see as pointless since you can nominate your own administrators from active users. Regards, CycloneNimrod ^talk?_contribs? 14:55, 16 June 2008 (UTC)

20. Oppose - I cannot support this policy in its current form. My primary grievance is with the stupidly high number of requirements placed on even being elegible - why not let the community decide who is "worthy" of such tools. Also, some communities may wish to opt out of this, and therefore a technical opt-out is necessary, nay, mandatory before this is implemented. --Skenmy 14:17, 16 June 2008 (UTC)
21. Oppose -- atleast not in it's current form. = ) --Camaeron 15:00, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
22. Oppose. I agree that there should be a technical opt-out for the wikis that wish it, standards for this user right are too high in my opinion. Rudget. 15:29, 16 June 2008 (UTC)
    • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:08, 16 June 2008 (UTC)
23.  Oppose as per Davidwr. It's too immature, but there are also other problems:
    1. local sysops usually form a kind of community, that global admins may have probles to participate in;
    2. I think first SUL needs to settle down a little bit and we should gain some wider-scale experience from it;
    3. The needs to introduce that (except for 'let's help small wikis') are too vague and they just not justify introducing a sledgehammer as others pointed;
    4. Even then, the projects should explicitily opt-in to participate in this experiment.

    And please Millosh, do not put your generic placeholder below my vote.  « Saper // @talk »  16:25, 16 June 2008 (UTC)

24. Oppose for the main reason stated above - no way to opt out. I don't think anyone should be given admin access to a wiki without the consent of its community. (Please, no cut-and paste responses, I've read the discussion and will only change my stance once the feature is actually available.) --Explodicle 18:02, 16 June 2008 (UTC)

    Fair enough :) --Millosh 18:21, 16 June 2008 (UTC)

25. I did not think that there was anything wrong with this until I read the comments of MessedRocker and WjBscribe (who is ironically supporting). –thedemonhog talk • edits 18:06, 16 June 2008 (UTC)
26.  Oppose per Saper, bug 14556 and other opposes, I don't think we are ready for it yet. (I'm really getting tired of that generic response, so please DON'T put it beneath this Millosh.) --Chetblong (talk) 18:34, 16 June 2008 (UTC)
27.  Oppose - Londenp 19:34, 16 June 2008 (UTC) I really don't see why it is necessary to arrange for these things on meta. There is no visibility for these kinds of proposals on local projects. Centralizing is NOT a good thing. Each project is independent, with local policies, and it should stay that way: don't change it, especially not outside the view of all the people which don't look on or are interested in meta. I don't like this movement to centralize power at all.
28.  Oppose barring an ability for wikis to opt out on a technical level. And don't spam my comment please Millosh. Prodego ^talk 20:00, 16 June 2008 (UTC)
29.  Oppose We need to focus on getting local sysops for those wikis that need it; this isn't a good solution, in my opinion, for reasons which have been stated above numerous times. - Rjd0060 20:36, 16 June 2008 (UTC)
30.  Oppose Per most of the above. Not until larger wiki's have this opt out ability. KnowledgeOfSelf 21:02, 16 June 2008 (UTC)
31.  Oppose, while I am completely of the same opinion as Ral315 and KnowledgeOfSelf. —αἰτίας •discussion• 21:05, 16 June 2008 (UTC)
32.  Oppose Per KnowledgeOfSekf and Skenmy. GreenJoe 22:25, 16 June 2008 (UTC)
33.  Oppose No need for it at least for the large wikis. Maybe the small ones, but its completely unneccesary for my wiki.--Finalnight 22:29, 16 June 2008 (UTC)
34.  Oppose Bad idea. Sorry. 24.97.138.90 22:30, 16 June 2008 (UTC)
35.  Oppose Needs the trust of the Local community to have rights there. Alexfusco⁵ 23:31, 16 June 2008 (UTC)
36.  Oppose, I agree with most of the above. More centralisation is not something we need. --Aqwis 23:39, 16 June 2008 (UTC)
37. Oppose: [[Wonderfool]] would love this... instead of having to build accounts up to adminship on en.wp and en.wt, he could just work for global sysop and bam! delete the main pages of hundreds of projects. - Amgine 02:16, 17 June 2008 (UTC)

    That is an argument against wikis, not against this proposal.  – Mike.lifeguard | ^@en.wb 03:35, 17 June 2008 (UTC)

38. 'Oppose Unless larger wikis have optout ability. SirFozzie 05:04, 17 June 2008 (UTC)
39.  Oppose - Having read both the for and against arguments - I do not support this proposal.--VS ^talk 05:21, 17 June 2008 (UTC)
40.  Oppose - Waerth 07:31, 17 June 2008 (UTC)
41. Zanaq 07:33, 17 June 2008 (UTC) Let the communities decide on what admins they would like. Let's not allow admins with no knowledge of the local policies.
42.  Oppose. There is a considerable risk that this means centralization and standardization, with the English Wikipedia leading. As long as there are areas where out-and-out craziness rules on the English Wikipedia (in defiance of all guidelines) such a centralization is a very bad idea. - Brya 07:34, 17 June 2008 (UTC)
43.  Oppose. People deciding about Wiki's they never go to and probably don't even know the main language @ that Wiki, scary 'wannabe in power syndrom'. JorritH 07:38, 17 June 2008 (UTC)
44. oppose per many of the above. Theo 07:49, 17 June 2008 (UTC)
45.  Oppose - those who do not participate in a community day to day have no business administering it. Blowdart 07:59, 17 June 2008 (UTC)
46. No, please...  Oppose Rubietje88 09:12, 17 June 2008 (UTC)
47.  Oppose Maxwvb 09:16, 17 June 2008 (UTC)
48.  Oppose - CrazyPhunk 09:20, 17 June 2008 (UTC)
49. Oppose—Admins are appointed by the local communities. Period. If projects have no community (and thus no admins), they're essentially dead. —mnh·∇· 10:13, 17 June 2008 (UTC)
50.  Oppose - see the comment made by Zanaq - Silver Spoon 10:21, 17 June 2008 (UTC)
51.  Oppose ---Joep Zander 10:23, 17 June 2008 (UTC)
52.  Oppose - Dutch T-bone 89.146.9.130
53.  Oppose - I agree with above comments by Zanaq, LondenP and JorritH. Mwpnl 12:59, 17 June 2008 (UTC)
54.  Oppose - Mhaesen 13:50, 17 June 2008 (UTC)
55.  Oppose - Far too risky. Guido den Broeder 14:37, 17 June 2008 (UTC)
56.  Oppose - No, this would be going too far. There should be a sense of collaboration between wikis but they and their (administrative) policies should remain independent. -- Mentisock 14:45, 17 June 2008 (UTC)
57.  Strong oppose - I want to talk to a moderator in my own language.--Westermarck 15:33, 17 June 2008 (UTC)
58.  Oppose - Too risky - Erik1980 15:47, 17 June 2008 (UTC)
59.  Oppose - Why give right en be not able to use it. Sterkebak 16:07, 17 June 2008 (UTC)

    This right will have every large project, including nl.wp. --Millosh 16:10, 17 June 2008 (UTC)

     Oppose - Roelzzz 16:29, 17 June 2008 (UTC) this vote has been done by IP 84.80.25.19 anonymously, -jkb- (cs.source) 16:33, 17 June 2008 (UTC)

60.  Oppose - Roelzzz 17:00, 17 June 2008 (UTC) (why do I have to create an account? Everyone can make an account with username Roelzzz!)
61.  Oppose Just what we need, more instruction creep. Pilotguy radar contact 17:23, 17 June 2008 (UTC)
62.  Oppose : technically premature. Hégésippe | ±Θ± 17:32, 17 June 2008 (UTC)
63.  Oppose --Revolus Echo der Stille 18:42, 17 June 2008 (UTC)
64.  Oppose - People should not be sysops on wikis where they are not active. Anonymous101 19:30, 17 June 2008 (UTC)
65.  Oppose - One should be member of the community of which one is an admin. Lexw 20:08, 17 June 2008 (UTC)
66.  Oppose - per dutch colleague Guido den Broeder and Erik 1980 Geograaf 20:38, 17 June 2008 (UTC) (nl:User:Geograaf
67.  Oppose Syrcro 21:14, 17 June 2008 (UTC)
68.  Oppose In order to best use the broom of adminship on a wiki, even just to fight vandalism, one must be familiar with that wiki's workings. A global admin is not the best solution. If good candidates are found, then admin them on a wiki-by-wiki basis. Also, while strong passwords for admins are always recommended, it doesn't take a fortune teller to figure out the havoc that could be caused on multiple wikis. — MrDolomite • Talk 21:35, 17 June 2008 (UTC)
69.  Oppose Fighting vandalism is alright, but I think global admins don't need so many permissions to do this. Anyway: Is there so much vandalism, that does not concern only one project? And if there is, I think it would be better to sysop the people on the several projects instead of giving them global administrator permissions. Most sysops speak about 3 to 4 different languages, so how can they fight vandalism in a lot of languages (how many are there actually?)? --ChrisiPK 21:57, 17 June 2008 (UTC)
70.  Oppose 08-15 23:00, 17 June 2008 (UTC)
71. Noddy93 23:25, 17 June 2008 (UTC)
72.  Oppose Is there a democratic legitimation for global admins? --Gleiberg 00:10, 18 June 2008 (UTC)
73.  Oppose I don't have a problem with someone from one wiki exercising adminship powers on another: my problem with it is language. What if I would go on a wiki other than the English Wikipedia and use my admin powers there, attempting to do well but misunderstanding the language enough that I caused problems? I like this possibility, but what I read here is a proposal to give all admins those abilities, and even the "opt-out" ideas (unless I missed something) don't answer this problem. I'd like to see the technical ability to have this done, but it should only be done if the admin on one project is, say, tested on the language of the other one. Let the English-speaking German administrator help at en:wikipedia, but don't let me be an administrator at de:wikipedia. Nyttend 00:14, 18 June 2008 (UTC)
74. --NoCultureIcons 00:25, 18 June 2008 (UTC)
75.  Oppose--85.180.7.216 01:04, 18 June 2008 (UTC)
76.  Oppose Julius1990 04:55, 18 June 2008 (UTC)
77.  Oppose No, thank you, vandalism is anyway not a big problem, and I can't wait for some of the Serbian and Croatian sysops starting to administrate the Bosnian WP. Fossa 06:39, 18 June 2008 (UTC)
78.  Oppose --Janurah 06:50, 18 June 2008 (UTC)
79.  Oppose In my opinion, this should be an opt-in-option for those projects who wants this. In its currently proposed form and regarding the currently missing support of even opt-out, I cannot support global admins. --AFBorchert 06:53, 18 June 2008 (UTC) P.S. Yes, Millosh, I have read your comments, there is no need to duplicate it once more. Thanks.
80. Nein Danke! --Geher 06:57, 18 June 2008 (UTC)
81.  Oppose - I agree with central appointment of admins for small wiki's according to an opt-in system, but not with this proposal. KKoolstra 07:21, 18 June 2008 (UTC)
82.  Oppose --Gripweed 07:28, 18 June 2008 (UTC)
83.  Oppose Only as Opt-In --Habakuk 07:54, 18 June 2008 (UTC)
84.  Oppose --Uwe Gille 08:07, 18 June 2008 (UTC)
85.  Oppose MADe 08:15, 18 June 2008 (UTC)
86.  Oppose --Large Wikipediae do not depend on global administrators and should keep their current systems for establishing all administrators by their own community. The differences in philosophy e.g. between enwiki and dewiki are so large already that it would cause conflicts. I'd be in favor of global administratorship for small Wikipediae only. -- Arcimboldo 08:19, 18 June 2008 (UTC)
87.  Oppose --85.182.42.252 08:39, 18 June 2008 (UTC) As a German I can only say: Wikipedia ist Ländersache. Cultural and political diversity across the world should be supported by Wikipedia. I see a long term danger for such a diversity if we allow for Global adminship. In the beginning such a system will be 19th Century-History Revisited. any reason why SUL does't work here? --Wuselig
88.  Oppose Too far too dAb: 86.83.155.44 08:54, 18 June 2008 (UTC)
89.  Oppose sebmol ^? 08:57, 18 June 2008 (UTC) not without opt-out option
90.  Oppose See No. 78 and one above, a croatian sysop has just been blocked on de:WP. For small wikis ok, but definitely not for those with large communities. --Sargoth 09:07, 18 June 2008 (UTC)
91.  Oppose as of reasons mentioned above. Van der Hoorn 09:32, 18 June 2008 (UTC)
92. Nein danke, sehe mehr Missbrauchsmöglichkeiten denn als Nutzen. --Chrislb 09:57, 18 June 2008 (UTC)

    Translation - No thanks, I see more possibilities of abuse than use as a utility. Rudget. 13:34, 18 June 2008 (UTC)

93.  Oppose --Ma-Lik 10:02, 18 June 2008 (UTC)
94. No. --Mg [ˈmœçtəˌɡeʁn] 10:16, 18 June 2008 (UTC)
95.  Oppose --Michael Reschke 10:25, 18 June 2008 (UTC)
96.  Oppose --Meisterkoch 10:28, 18 June 2008 (UTC)
97.  Oppose --Björn Bornhöft 10:29, 18 June 2008 (UTC)
98.  Oppose --LKD 10:48, 18 June 2008 (UTC)
99.  Oppose -- smial 10:51, 18 June 2008 (UTC)
100.  Oppose --Poupou l'quourouce 11:48, 18 June 2008 (UTC)
101.  Oppose --Gnu1742 12:48, 18 June 2008 (UTC)
102.  Oppose --Jan eissfeldt 12:56, 18 June 2008 (UTC) hubris
103.  Oppose --141.84.69.20 13:04, 18 June 2008 (UTC) de:Benutzer:Jodo
104.  Oppose --Stefan64 13:24, 18 June 2008 (UTC)
105.  Oppose C-M 13:29, 18 June 2008 (UTC)
106.  Oppose opt-out is necessary --Avatar 13:41, 18 June 2008 (UTC)

      Oppose although I'd consider changing my stance if it was clarified that a global sysop who uses their tools on the English Wikipedia is instantly desysopped without exception (or perhaps an absolutely no exception 3 strikes policy). Otherwise it will quickly become a way to dodge RFA, but still contain all the drama of our admingod system. --JayHenry 13:41, 18 June 2008 (UTC) Oops, i didn't read the proposal closely enough! I see that's already there. Need time to reconsider. --JayHenry 13:44, 18 June 2008 (UTC)

107.  Oppose --Wolfgang H. 13:54, 18 June 2008 (UTC)
108.  Oppose People should need to prove themselves in EVERY wiki they want to sysop. Not every wikipedia sysop should have the same powers globally. Some are barely competent as it is. Now you want to give them global power? I think not! Carter
109. Erik Warmelink 14:35, 18 June 2008 (UTC)
110.  Oppose I don't like the idea of someone having sysop status in a Wiki without being part of the community of that wiki and without being elected by the members of it. -- Discostu 14:43, 18 June 2008 (UTC)
111.  Oppose -- Achim Raschka
112.  Oppose --trm^ger 15:55, 18 June 2008 (UTC)
113.  Oppose --AWI 16:04, 18 June 2008 (UTC)
114.  Oppose --Orci 17:31, 18 June 2008 (UTC)
115.  Oppose, premature; global rollback imho is needed so much more for SWMT and they still don't have it yet, I would like to see rollbacker first, and think it would be a good test for future global additional rights, --birdy geimfyglið _(:> )=| ∇ 17:55, 18 June 2008 (UTC) p.s. also: [10] „If some wiki doesn't have administrators just in some parts of the day (like the night hours in a specific time zone), they should take care of that wiki during the unmonitored times.“ — I don't see why. SWMT and stewards only acted in case of emergencies, e.g. massive page blanking/replacing etc. I don't see what harm a "testpage" does if it dwells overnight, for such things there is a deletion template. --birdy geimfyglið _(:> )=| ∇ 00:20, 19 June 2008 (UTC)
116.  Oppose --Kbdank71 18:13, 18 June 2008 (UTC)
117.  Oppose --Jpp 18:41, 18 June 2008 (UTC)
118.  Oppose No reason for a technical opt-out. If a wiki decides not to allow these people helping them, they can put themselves on an opt-out list on Meta and the global sysops will then not be allowed to help these wikis (unless they are elected sysop there). But: The policy does not clearly enough say that global sysops are *not at all* allowed (except in cases of clear emergencies) to use these rights on wikis with any local sysops. If that is said, an opt-out will still not be necessary. --Thogo (talk) 20:14, 18 June 2008 (UTC)
119.  Oppose -- Seems like an invasion to "liberate" other wikis to me Quistnix 21:05, 18 June 2008 (UTC)
120. --Farino 23:19, 18 June 2008 (UTC) Different languages, different cultures, different rule sets: it's not worth the trouble it will cause
121.  Oppose -- You can't be a sysop/admin in a community you're not really a part of and that hasn't had a chance to vote for you. Channel R 23:49, 18 June 2008 (UTC)
122.  Oppose I support the general idea of giving tools to people who are helping manage vandalism on smaller projects but I cannot support until or unless there is an opt-out. I also agree with Ral's comments in this section about the "pre-requisites" but that's probably easier to resolve and not such a concern to me at this time as the opt-out issues. I do think the general idea is a good one, though and I would support if the concerns about opt-out were resolved. Sarah 00:40, 19 June 2008 (UTC)
123.  Oppose - Too much abuse of admin privileges already. This will only make it worse. Ward3001 02:41, 19 June 2008 (UTC)
124.  Oppose -see birdy —YourEyesOnly 04:20, 19 June 2008 (UTC)
125.  Oppose --Polarlys 11:28, 19 June 2008 (UTC)
126.  Oppose Isn't this what Stewards are for?--Poetlister 11:40, 19 June 2008 (UTC)
127.  Oppose --buecherwuermlein 14:04, 19 June 2008 (UTC) per Poetlister: Why don't vote elect more stewards doing this work?
128.  Oppose --Mordan ( talk - de - de-talk ) 14:24, 19 June 2008 (UTC)
129.  Oppose Too much of a temptation for privilege abuse. Ironholds 14:42, 19 June 2008 (UTC)
130.  Oppose. From the "RfGS" procedure proposals, the obtaining of global sysop rights promises to be easier than obtaining sysop privileges on individual wikis. Contributors who have the language knowledge and expertise to wield adminship on a project should be requesting those rights at SRP. Otherwise, my concerns listed at Talk:Global sysops still stand. haz (talk) 14:56, 19 June 2008 (UTC)
131. strong oppose nice to have for smaller wikis (maybe) but evil for the big communities which have enough manpower and established conventions about who should be an administrator and how to inaugurate them.--Wiggum 16:28, 19 June 2008 (UTC) Add.: an opt-in solution seems worth to support to me

     Hello Wiggum, just a note: it is not meant for wikis with enough manpower though. --birdy geimfyglið _(:> )=| ∇ 09:22, 20 June 2008 (UTC)

     it is not about what it was meant for by intention, but what it may cause by practics .. W!B: 21:51, 20 June 2008 (UTC)

     Sorry, but if they would dare to do so, they would loose their status immediately, this is what the policy demands. I am not defending the policy as a whole as I have opposed it too but for other reasons, but this concern is addressed, just wanted to point that out. --birdy geimfyglið _(:> )=| ∇ 22:01, 20 June 2008 (UTC)

132.  Oppose Agree with Conrad and others above. miranda 17:52, 19 June 2008 (UTC)
133.  Oppose I totally agree with the comments above --Hufi 18:52, 19 June 2008 (UTC)
134.  Oppose Only as opt-in. --Oxymoron⁸³ 22:34, 19 June 2008 (UTC)
135.  Oppose --AT 03:04, 20 June 2008 (UTC)
136.  Oppose a sysop should really understand the insides of a wiki, only to understand the language won't do. And this requires a more or less daily involvement. --Geos 07:06, 20 June 2008 (UTC)
137.  Oppose Balko 08:10, 20 June 2008 (UTC)
138.  Oppose --Norro 09:33, 20 June 2008 (UTC)
139.  Oppose --UW 10:01, 20 June 2008 (UTC)
140.  Oppose --Ureinwohner 10:56, 20 June 2008 (UTC) Thx, cu
141.  Oppose --Zinnmann 11:04, 20 June 2008 (UTC)
142.  Oppose—Zhaladshar ^(Talk) 14:40, 20 June 2008 (UTC)
143.  Oppose--Bunnyfrosch 15:22, 20 June 2008 (UTC) murks
144.  Oppose --Art Unbound 19:11, 20 June 2008 (UTC)
145.  Oppose -- LeeGer 20:08, 20 June 2008 (UTC)
146.  Oppose W!B: 21:51, 20 June 2008 (UTC) (can't see any reason, why small wikis should't "adobt" an sysop from anywhere as a guest worker by intern election)
147.  Oppose --Lecartia 08:59, 21 June 2008 (UTC)
148.  Oppose --Marbot 14:19, 21 June 2008 (UTC)
149.  Oppose --Sozi 18:44, 21 June 2008 (UTC)
150.  Oppose --STBR – !? 19:58, 21 June 2008 (UTC) Why is terrorism vandalism abused to justify features not wanted by the community?
151.  Oppose as per ArielGlenn, Geos and so on. I might be tempted to change my vote to neutral if the opt-out function was already in place (not just in the pipeline), but I do not think this proposal will be good for smaller communities at all. --Wytukaze 22:35, 21 June 2008 (UTC)
152.  Oppose --Nolispanmo 19:57, 22 June 2008 (UTC)
153.  Oppose --EivindJ 23:23, 22 June 2008 (UTC)
154.  Oppose the language issue pretty much cuts it. --O (谈 • висчвын) 02:04, 23 June 2008 (GMT)
155.  Oppose due to language problems and lack of an opt-out. I am aware of Millosh's general reply and do not wish to change this vote. Stifle 09:58, 23 June 2008 (UTC)
156.  Oppose To much trouble might be caused then. Denis Barthel 10:27, 23 June 2008 (UTC)
157.  Oppose All projects need to retain their soverignty. Opt-in or opt-out through technical means is a must before this can be seriously entertained. WilyD 14:09, 23 June 2008 (UTC)
158. Byra, Spacebirdy, PilotGuy and Ral315 raise concerns that seem reasonable to me. Opt-in is essential and how will this work with the good people at the SWMT? Angus McLellan (enwiki talk) 14:52, 23 June 2008 (UTC)
159. Horrible idea. What's the need for it? Also, Ral315 makes some good points. Moreschi 15:14, 23 June 2008 (UTC)
160.  Oppose Sounds frightening Varina 18:54, 23 June 2008 (UTC)
161.  Oppose Kamil Filip Ulryk 18:50, 24 June 2008 (UTC) after Ral315's lecture
162.  Oppose IMO, bad idea. More centralization would damage cultural and political diversity across communities. Maybe for smallest wikis till they have enough admins. Avia 03:30, 26 June 2008 (UTC)

     That is exactly what we are proposing.  — Mike.lifeguard | ^@en.wb 21:36, 26 June 2008 (UTC)

163.  Oppose ThomasV 05:14, 26 June 2008 (UTC)
164.  Oppose Svens Welt 14:27, 26 June 2008 (UTC)
165.  Oppose I could see a huge problem with trustworthy users on small wikis, gaining global sysop and abusing it. Also I think the opt out needs to be implmented before I am willing to support this type of policy. Mww113 12:12, 27 June 2008 (UTC)
166.  Oppose I that someone should be familiar with a wiki before gaining administrator powers on that wiki. Captain panda 14:04, 27 June 2008 (UTC)
167.  Oppose we need a technical opt-out for larger wikis. We've had cases of stewards giving themselves bureaucrat rights on the English Wikipedia (even when they are explicitly not allowed to do so) and this feature is bound to get abused. Hut 8.5 14:50, 27 June 2008 (UTC)
168.  Oppose Tönjes 12:26, 30 June 2008 (UTC)
169.  Oppose Honestly, I don't see a need for this as larger wikis will have more than a sufficient number of admins to deal with issues and the steward position was created specifically to address this problem for smaller wikis. In addition, I have personally made a few procedural errors on wikis that I am not familiar with despite my experience on the English Wikipedia and I think letting admins exercise their powers across wikis would carry a significant potential for problems and potentially conflict. Finally, if the user in question really desires or needs sysop powers on another wiki, they are free to stand for an RfA (or the comparable procedure) on the other wiki. Thingg^⊕⊗ 13:45, 30 June 2008 (UTC)
170.  Oppose Minderbinder 16:00, 30 June 2008 (UTC)

Neutral

1. I would greatly prefer to see technical opt-out. Daniel (talk) 05:26, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:10, 16 June 2008 (UTC)
     • I will not support until it is implemented. Daniel (talk) 00:12, 23 June 2008 (UTC)
2. While I understand there is a need, I think the proposal has turned more from "anti-vandalism" to "steward-lite." I also think there needs to be a technical opt-out system. Right now we seem to be allowing projects to set their own policy regarding this. Are global sysops going to have to consult/memorize a list of wikis with local policies before taking any action on a project? I also don't like that small wikis don't seem to be able to opt-out. I think if a small wiki can get enough people (more than a handful) to vote and decide that they don't want global sysops, then they should be able to opt-out. Mr.Z-man 06:01, 16 June 2008 (UTC)
3. I too would like a technical opt-out system. Mr.Z-man has left a good comment above. --MiCkE^d_b 08:25, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:11, 16 June 2008 (UTC)
     • I understand that large wikis will have a chance to opt-out even if there is no technical solution to the bug request. However I see the main reason for a technical opt-out system to be the chance for small wikis to opt-out. No one will go against the wishes of en.wiki no matter what, but I am conserned for for a reasonably active, but small, wiki such as e.g. sv.wiktionary if no technical opt-out sytem is impemented. When/if the bug is resolved I will change my vote. MiCkE 08:33, 18 June 2008 (UTC)
       • As I said above, everybody will be happy to see that one small wiki became a mature one. Until that time, they are under patronage of the stewards and global sysops should be here to help to stewards. But, if you are a contributor of one small wiki, I have the question for you: are you sure that you are not willing stewards and global sysops to help you in maintaining your project? --Millosh 18:09, 18 June 2008 (UTC)
         • I'm sure that I want to be able to say no, should the need to do so arise. I wan't a technical opportunity to opt-out, I'm not sure that I would advocate an opt-out on any specific project I'm active on though (at this time). MiCkE 18:38, 18 June 2008 (UTC)
4. I don't think the requirement of being an administrator on at least one content project is good: if someone is such an administrator, he must be busy at his project and hardly have time to supervise other small projects, so such a person will hardly be useful as a global sysop.--Imz 08:50, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:10, 16 June 2008 (UTC)
5. Enjoy the idea, but opt-out should be a technical functionality before this new class can be considered for mainstream integration. --Anonymous Dissident^Talk 10:59, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:11, 16 June 2008 (UTC)
     • Have changed per new information. --Anonymous Dissident^Talk 12:09, 17 June 2008 (UTC)
6. While a nice idea in essence, there are some parts of the proposal that I don't quite like (SUL administration right, Undeletions [they can always ask a steward to undelete; I doubt there'd be emergencies], future global block right, to mention a few). Also, the mentioned technical limitation regarding project opt-out is quite a hindrance, IMHO. Other than that, the proposal has some merits and I acknowledge that the global sysop group would tremendously help in maintaining small wikis. --FiliP × 15:22, 16 June 2008 (UTC)
7. Neutral. I support it for some reasons (cf. comments by Rory096, DeadEyeArrow, Titoxd, and others) and oppose it for others (cf. comments by Messedrocker, Avruch, OverlordQ, and others). I concur with the comments below about the present limited visibility of the watchlist announcement: global sysop is proposed for smaller wikis, yet it is on the smaller wikis that it hasn't been announced in a highly visible way with watchlist messages. — Athaenara (contribs) 16:00, 16 June 2008 (UTC)
8. I am sysop at enwiki, and have been temporary sysop five, six or seven times in smaller wikis. I agree that there is a need for global sysops. However, it is also true there are wikis with election processes that should be able to opt-out from this feature. I don't believe it is strong enough a reason to object: if the feature is implemented, it should be used. -- ReyBrujo 16:19, 16 June 2008 (UTC)
   • (This is a generic ask.) Bug 14556 is submitted and developers showed intention to work on that (in both ways, it would be possible to exclude any large wiki). As it is in process, it is reasonable to suppose that it will be implemented. If you change your vote, it would save a lot of time related to preparation for the next discussion and poll. Thanks in advance. --Millosh 16:20, 16 June 2008 (UTC)
9. Per bug 14556 will support once global groups can be defined on a subset or wikis, or wikis can opt-out in some other way. --Rainman 16:50, 16 June 2008 (UTC)
10. I think it's a fine idea, but I'm opposed to the qualifications as currently laid out. I also believe there should be a technical opt out. And yes, Millosh, I know about Bug 14556. Philippe 21:04, 16 June 2008 (UTC)
11. I think that the deletion/undeletion powers should generally only apply to edits from users whose home wiki is the same as the global sysop's home wiki. I can see making an exception for projects small enough that timely attention from a local admin might be a problem, but if for example, I were to for some strange inexplicable reason ever become a global sysop I doubt I'd be able to judge non-English edits properly. Caerwine 23:41, 16 June 2008 (UTC)
12. I don't know enough of the goings-on at the smaller wikis to oppose confidently. However, I have a few reservations about it. The whole opt-out issue would be good to be taken care of, but it seems like that is in the works. I am more worried about the effects it would have on the smaller wikis, especially since a number of them (I believe) are in languages that not many people know. It seems unlikely that global administrators would be able to use their tools effectively in these cases. (how can one know if something is vandalism if one can't read the edits?) It may be that I'm putting too much emphasis on smaller, other language wikipedias, but that's how I see it for now. -- Natalya 02:03, 17 June 2008 (UTC)

    I don't speak Latin, but it's not hard to tell that this is vandalism. Spamming and test edits are also pretty easy to identify.--Werdan7^{T @} 02:08, 17 June 2008 (UTC)

    That's fair. As I think about it, that same rational could even apply to languages in different scripts. I'll have to think about it. -- Natalya 02:11, 17 June 2008 (UTC)

13. The opt-out needs to be a reality before this is implemented. -- Avi 04:40, 17 June 2008 (UTC)
14. Comment below. --Kale 19:16, 18 June 2008 (UTC)
15. Waiting for a version with opt-out or opt-in features to be offered. Jeepday 12:52, 28 June 2008 (UTC)

Comments

1. Considering this poll is posted as a watchlist message on en-wiki, and might not get similar visibility in other projects, I don't know how useful the results are. It's pretty obvious that the users on en-wiki would oppose the proposal, since global sysops aren't needed there, and could conceivably harm the project. - Bobet 08:34, 16 June 2008 (UTC)

   I agree, adding this to the watchlist notice was not a good idea. -- lucasbfr ^talk 11:29, 16 June 2008 (UTC)

   Any way we can communicate this to small wiki teams (who do not speak English in many cases)?--Yaroslav Blanter 14:27, 16 June 2008 (UTC)

   How's the Wikimedia Embassy these days? If ambassadors are still doing their jobs, we might be able to get them to translate a notice for that project's {{watchlist-notice}} (presuming they have such a thing) as well. Is that a good idea? --Tiny plastic Grey Knight 16:26, 17 June 2008 (UTC)

2. This seems to be a general problem: a kind of chaos. Just short time ago there was another voting, on Usurpation policy, that has not been anounced properly, and where there were some three versions of it while the voting went on (first version, updated version, discussed version at least). Might be that meta should provide some kind how to bring something to a poll. And, how to announce it in other projects if the matter does not concern meta only. Otherwise even good ideas will be opposed because not because of the matter but because of the kind of voting. -jkb- (cs.source) 09:06, 16 June 2008 (UTC)

   We could announce these things quite easily if meta had a low-volume page on which important project-affecting announcements owere made, and had a bot to distribute the changes to any local communities that had signed up to it. It might require a bit of work translating all the announcements, but in some ways that is good as it ensures the announcement page will only be used for important things. Conrad.Irwin 10:14, 16 June 2008 (UTC)

   Well, sorry for the delay, but: it is not necessary to have sufficient translations. I announce on the Czech Wikisource many votings here and elsewehere - like this one - without having any translations. Anybody on a domain should spek English, and he can answer the questions. Mote important is that the domain is informed about a poll that have impact on the domain. And this does not work yet. -jkb- (cs.source) 17:35, 17 June 2008 (UTC)

3. I submitted bug 14556 for making technical opting-out possible. --Millosh 12:15, 16 June 2008 (UTC)

   Why are you spamming every possible place on this page with your bug link?  « Saper // @talk »  16:28, 16 June 2008 (UTC)

   I asked only contributors who declared that they are voting against because of a lack of possibility for technical opting-out. It was targeted question; which means that it is not a spam. --Millosh 16:34, 16 June 2008 (UTC)

   How about posting it once at the top of each section where it would apply, rather than posting duplicates below many individual posts in those sections?
   The duplicate postings are distracting and increase the difficulty of simply reading the editor comments. — Athaenara (contribs) 16:55, 16 June 2008 (UTC)

   I don't think that it would be appropriate: (1) it is a question to particular voters, not to all of them and (2) this is the place for comments (not the sections above) (and I see that a lot of voters don't read them). --Millosh 17:15, 16 June 2008 (UTC)

   Do whatever, but its irritating. Not putting it here (in its appropriate place) because 'a lot of voters don't read them' mirrors the mentality of internet spammers.24.242.76.192 11:33, 17 June 2008 (UTC)

4. I am concerned that the bulk of opposition to this proposal is from enwiki editors (who will be little affected by this user right). If someone with global rights used them on enwiki, they would lose them - it is clearly a project with plenty of local sysops. I think the prominent advertising of this poll on enwiki is leading to a distorted view of the consensus across Wikimedia projects, to the detriment of the small projects who would really benefit from this right. WjBscribe 15:40, 16 June 2008 (UTC)

   This poll is skewed in any case. The majority of the wikis which would benifit the most from this (the small wikis with no or few admins) have in some cases only a few thousand articles, and hence probably also only a couple of thousand edits, editors solely active on that project are very unlikely to have enough edits to be allowed to vote here. --Dirk Beetstra ^{T C} (en: U, T) 15:51, 16 June 2008 (UTC)

   I was actually expecting a revolt from the enwikipedians, and it has happened..I'm not sure why these people are not realising that this proposal is only for the benefit of smaller wikis and larger wikis will NOT be affected..and yes the "global sysops" will have the ability to use Special:Undelete and could delete and block users on those 'bigger' wikis, but they will be forbidden from doing so, and since millosh has already filed a bug on this, it will be better if the people from bigger wikis avoid voting for now and await the outcome of the bug, and if this never eventuates, then sysops and/or crats will be appointed from big wikis to "stalk" the contributions of the global sysops on their wikis and if they do anything out of line, report to the appropriate page here on Meta and they will be dealt with swiftly....but the enwikipedians/large wikipedians should remember a major advantage they have, they can choose who gets the right, since most of them qualify to vote or request the right themselves..if you vote for someone you trust, then all those oppose above will mean nothing....and if not...hope for the tech opt-out to be resolved..--Cometstyles 22:17, 16 June 2008 (UTC)

   And when has being forbidden stopped an admin from doing something they shouldn't? And now they're supposed to get a global bit? OverlordQ 22:44, 16 June 2008 (UTC)

   I fully agree. Looks like they really think that a project with less than 100K articles is not worth anything and should be closed, and the only think they care about is their independence. Some of them even registered just to vote here. May be we should have two foundations: one for ewn.wp and one for everybody else.--Yaroslav Blanter 07:10, 17 June 2008 (UTC)

   Maybe not two foundation, but the policy with doesn't cover en.wp and which doesn't allow to people from en.wp to vote about the policy. --Millosh 08:53, 17 June 2008 (UTC)

   I also agree with your findings. Population of small wikis are under-represented, yet this affects them much more than big wikis like en.wp (and I observed that some IP or newly registered user came here just to vote oppose) OhanaUnited^{Talk page} 05:20, 20 June 2008 (UTC)

5. Ironically, on this very same page we have [11]. I find much of the discussion above to be nonsense. Firstly, about the matter of stringent requirements: a poll at Wikipedia for creating an op is always in large part a popularity contest, and the quantitative requirements can be both side-stepped and gamed. Secondly, about the matter of technical-opt-out, if these projects can't get together and bless someone to admin then what is the precedent for believing they can have a coherent poll to oust an ignorant or abusive global sysop? The fantasy is that once some critical mass is achieved they'll be able to opt-out, but in reality it will become an accepted part of the status-quo with its benefits and drawbacks. More obsession with centralization that 2% of editors have and the rest get drummed up to vote about. If a valuable discussion can't come from this, I hope all these same ops salivating over this poll take the opportunity to volunteer for temporary op positions on a case-per-case basis, which already has much precedent and low incident of complaint.24.242.76.192 11:59, 17 June 2008 (UTC)
6. Opt-in or Opt-out. What I experience as the biggest problem here is the Opt-in or Opt-out solution. I have no problems giving members of SWMT admin-rights on par exemple nl-Wikibooks *if they ask for it*. I have no problem to opt-in on a meta-policy, but only after the policy is discussed at the local community and the community accepts this. I do have a problem with the way policies are imposed on people and communities, who have 1) no knowledge about the discussion, 2) might not understand english enough to discuss on meta 3) are only focussed on the local community. I will oppose any changes and any policies which affects local communities, when it is not reviewed and accepted by the local community. This is not the way to go!! You can all develop policies how many you like, but opt-in and do it the hard way. Policies which are valuable will be adopted, and if not: something must be wrong with the policy. Londenp 13:51, 17 June 2008 (UTC)

   I totally agree with this comment. Make it opt-in and we'll see how many communities will adopt it. Silver Spoon 14:33, 17 June 2008 (UTC)

   Not many. Because the large wikis don't need it and the small wikis that will be benefit from this have no real communities that can adopt this. --MF-W 14:43, 17 June 2008 (UTC)

7. Based on some of the comments, I’m not sure how many people actually read the proposal. The `large-wiki-skepticism` should be the least of our concerns since these wikis will never have to deal with global sysops, especially with the introduction of a technical opt-out for them (assuming it will become reality). There are well-intended volunteers out there dealing with small wikis with an extremely limited level of understanding for both the nature of a good number of edits, and for the specifics of any given project. With this in mind, it seems that introducing yet more tools to the conundrum might not be the best way to promote small wiki stability/prosperity. If the intention is to help the smaller projects, there is a good deal of ways in which SMWT could be improved, all requiring willing participants and dedication to establishing better communication with the smaller wikis, even if their communities amount to no more than a handful of editors. But motivating potential volunteers by means of enabling the usage of shiny global tools (global rollback aside) might not be the best way to go; IMHO, anyway. The centralization concerns should not be slighted either. This poll fairly depicts that adequate representation of the global community at Meta is missing. Electing GSs in the proposed way would not assure they are, in fact, globally trusted... A more gradual introduction, perhaps (as someone suggested) by means of trial on smaller groups of wikis (adjusting to their feedback) could be a better way to go. --Kale 19:16, 18 June 2008 (UTC)
8. I strongly recommend to omit any opt out - a community can't work on stepping aside, but only on a willing to share - which means, if I have to say „no“ to working together, instead of saying „yes“, there's a bug in it: we could do an opt-in for any wiki, which means, it's a ask for support (not a refusal) W!B: 22:06, 20 June 2008 (UTC)
9. Has anybody noticed that about half, if not more, of the oppose votes have absolutely no explanation. Parent5446 21:58, 26 June 2008 (UTC)

The name

I don't think the name "global sysop" is sitting well with most users. Oppose voters are talking about en: and de:wikipedia, never mind that the global sysops according to the proposal has never been meant to use their tools on either of those wikis. I think the name "global sysop" is misleading. --Jorunn 10:07, 18 June 2008 (UTC)

it is very misleading, but when the voting was taking place for a suitable name, most that opposed based on the name (above) didn't add their input of the name they wished it should be, we can't blame the stewards for choosing this name, since the community itself supported the name, though there were a few other names which could have been chosen and which sounded more appropriate and less bureaucratic...--Cometstyles 10:12, 18 June 2008 (UTC)

The stewards are of course not to blame for this name. I do not want to blame anyone, except myself for not seeing this clearly and saying so before the poll on the name was over.

The name global sysop for this role is really not helping this proposal along. I don't think that a proposal for something called global sysop will ever pass the vote here, no matter what the actual content of the proposal is. --Jorunn 10:51, 18 June 2008 (UTC)

I don't think that whitewashing is fair. There are plenty of valid concerns among those opposing.24.242.76.192 14:46, 18 June 2008 (UTC)

Actually, I do not see any valid concerns. It has been stated that the proposal concerns smaller wikis with no or little community, and the global sysops or whatever they will be called will not be allowed to use this option on big wikis. Even the opt-out bug has been submitted. The concerns are still that the big wikis will be affected (even though is is explicit in the proposal they will be not), and of course people from en.wp do not care about small wiki vandalism, this is very much understandable. I must say that I am a meta regular and all people I have eve heard of, with the only exception - that of Alison Wheeler - supported the proposal. I assume most of these voting against did not actually read the proposal, even less the discussion on the proposal, but have heard of it at IRC channel and came to vote even though they have no idea of meta issues. All really serious concerns have been addressed in the course of the discussion and at the early stages of the voting.--Yaroslav Blanter 16:20, 18 June 2008 (UTC)

The proposal is Their role is global on all Wikimedia projects. They have permissions on all Wikimedia projects, comparable with administrator permissions on individual projects, and is not Their role is limited to small Wikimedia projects. They have permissions only on small Wikimedia projects, comparable with administrator permissions on individual projects,. --Sargoth 00:09, 19 June 2008 (UTC)

The name was chosen after a week of straw polling. To argue about it now will not be productive. --Anonymous Dissident^Talk 12:53, 19 June 2008 (UTC)

This proposal was announced on the Dutch Wikipedia pub by a sysop reading Meta stuff on a regular basis. His main concern was the opt-out issue, while many Dutch Wikipedians were concerned with proposals coming from "above" (Meta that is), without due announcement of a "global" measure like this. As a result, Dutch Wikipedians voted 5-35 against the proposal. I guess this is a clear sign. If you want a proposal accepted "globally" make sure you announce it properly in advance, have it translated with a summary of the arguments, and make it very clear up to which point local Wikis are affected. Politics may be far more important than you think. - Art Unbound 19:40, 20 June 2008 (UTC)

ja, thats it: until meta is a sheer english platform, there always will be caveats by national projects (there are resentiments against beeing constrained to argue in foreign language) - we learned a lot about that in the way how the European Union works - so, if tasks like that ought to be prepared lets say in about a dozen main "official" languages, they would work better: we could do arguing and voting in our languages, and count together.. --W!B: 21:47, 20 June 2008 (UTC)

Closing up

This poll is now closed, and it seems clear that this proposal should be rejected. Are we ready to archive up and undertake the necessary housekeeping that follows such a rejection. Who is responsible for this, and for formally rejecting the poll? --Anonymous Dissident^Talk 08:23, 1 July 2008 (UTC)

Trouble at the Persian Wikipedia

I have moved it to Requests for comments/Trouble at the Persian Wikipedia--Mardetanha ^talk 21:42, 18 June 2008 (UTC)

Image:Bookshelf-40x20.png

This GFDL image is used on the wikipedia.org main page (and all the equivalents for other projects) without any form of attribution or mention of the GFDL. Is this a GFDL violation or am I missing something? Anonymous101 19:27, 17 June 2008 (UTC)

You appear to be. I can see a GFDL template.--Cato 21:36, 18 June 2008 (UTC)

http://wikipedia.org does not mention GFDL and has no link to the image description with the GFDL template. /Ö 15:43, 19 June 2008 (UTC)

I created the original (somewhat simple and crude) image while designing the current wikipedia.org layout, and I confirm that it is GFDL (and am fine releasing to public domain or placing under Wikimedia copyright if desired). I also don't have any issue if someone would like to design a more refined "bookshelf" type image in its place -- the original considerations were fast loading, having a visual shorthand for the size of the wikis without the need for translations, and recognizability as "books" or "pages". I tried it with books of all the same size, to look more like a shelf of encyclopedias, but for most viewers it was less recognizable as books and not as an abstract rectangle. Catherine 16:03, 23 June 2008 (UTC)

data mining in Special:Recent changes

Hi, I'd like to aggregate the data in Special:RecentChanges and do a data-mining on it. For example, it may show the hottest topics(like what wikirage is doing), new articles with most edits, users that contribute most contents, etc.

It seems possible to write a small php program to fetch the Special:RecentChanges into SQL, but there's over 240,000 changes in English wikipedia per day, the page can be extremely big[12]. Before I start to do this, I'm wondering if there's a wise way to aggregate these data. Thanks a lot! --Dulldull 07:56, 20 June 2008 (UTC)

Any sort of aggregation will lose some information. If you know that what you lose is irrelevant, then it is safe to aggregate; otherwise, it isn't. For your purposes, you would need to retain the distinction between different editors and different articles, which allows very little scope for compression. You could convert multiple edits of the same article by the same editor to one line, but that would probably not give you a vast saving.--Poetlister 12:03, 20 June 2008 (UTC)

In any case you should use the API (recentchanges) and not Special:Recentchanges. Check the list=recentchanges (rc) section on api.php for documentation. --Erwin(85) 14:59, 20 June 2008 (UTC)

Luckily I can hear this before i fetched the Special:RecentChange page. It's a great source to explore. Thanks for all the advices. --Dulldull 20:12, 20 June 2008 (UTC)

Global userpage

I was thinking today that a global userpage function would be really handy for global users. Based here on Meta, one could design a "global" userpage that would appear as a kind of default userpage on every project that a given global user has not specifically logged in to, has edited, or has previously created a userpage on. For instance, if I were to create a global userpage, I'd make mine a redirect to my meta userpage:

"[[m:User:Anonymous Dissident]]"

I think this could be very handy; personally, I'd make all of my user pages on projects I don't edit on much be simply a redirect to my meta userpage anyway, but I'd have to do it manually, so this would be a very useful functionality for anyone in the same state of mind. Thoughts? --Anonymous Dissident^Talk 10:35, 21 June 2008 (UTC)

Support, if it is a default page, which appears on accounts that are merged (auto or manual, not on all 745 ones), and that I can simly change them. For redirecting it would be great (I am sure, many users would use them for 50 KB selfpromotion, but you can not avoid this...), -jkb- (cs.source) 11:13, 21 June 2008 (UTC)

This is interesting. I have userpages on something like three dozen projects and they are mostly very similar.; I'd have more if creating them were a bit less tedious. I use subpages for different chunks of the page and pull them all together with with transclusion in the userpage proper. I think what this proposal basically entails is cross-wiki transclusion. Enabling that would be a truly great feature. I can think of several possible issues, so limits may be appropriate. Please, please, please, allow user-subpages, too. Cheers, Jack Merridew 12:24, 21 June 2008 (UTC)

I strongly support this idea, although how about the choice to choose what page is mirrored? I have some different content on my enwiki and meta userpages but would definitely create one in a meta user subpage e.g. a box in Preferences which says 'Mirrored userpage: User:E/mirroruser'. It's worth looking into and would be very helpful. — E ^talk 12:50, 21 June 2008 (UTC)

I don't think this is an appropriate use of resources, though I agree that user pages should by default have a soft-redirect to the home wiki of the global editor (as that is what most people do). Though that would require the ability to choose one's home wiki I suppose. Conrad.Irwin 22:42, 21 June 2008 (UTC)

"appropriate use of resources"? Care to expound on that? --Anonymous Dissident^Talk 00:08, 22 June 2008 (UTC)

Interesting, and good idea. Support: Assuming it is, as said above, only the default, which can be changed simply by editing the local userpage. - Rjd0060 23:13, 22 June 2008 (UTC)

I have similar thoughts. I think this is quite easy as long as the function of global redirection is enabled. People can choose which wikis they like to host their usepages. Most wikipedians contribute on the wikipedia by default. --Phlyming 02:59, 23 June 2008 (UTC)

Be warned that MANY user pages uses a lot of templates that are speciic to one site and will not work on another; don't forget also the case of links that don't work identically (different namlespaces, collisions and disambiguation pages); in addition, they also use interwikis to another project where the same user page will not make the interwiki link work as expected (due to something I consider a bug, e.g. "w:en:apple" would work on French wikipedia to link to the English fruit, but not on English WP, and "w:apple" on EN.WP would not work correctly on FR.WP where it would give the page for the computer manufacturer. Having common pages and templates is really too much tricky.

Some more ideas:

• On the opposite, having common preferences set automatically from the global account would allow reimporting automatically a few things like the user preferences, until the user starts creating content, where the preferences will be set locally and registered, then modifiable locally on each project.
• In addition, there could exist an option in the User preferences that will explicitly reimport and overwrite these items.
• Finally, user preferences are currently edited using only the configuration panel in the special page. However these preferences should have an history that can be ret by the user itself, to possibly revert a temporary change.
• Another thing to add in the user preferences profile: the babel wikicodes and levels (that are sharable). When using {{#babel:...}} the list would be prefilled with items from the global user preferences, and will appear at the top, then other items can be used only to override some levels when they are of the form "<recognized-language-code>-<number>", or to add other items specific to the local wiki.
• Note another related bug: the <languageslist/> is currently not sorted at all! This combobox is almost unusable: too hard to find any language in it!!! See for example the home page of Betawiki...

90.45.93.218 06:42, 23 June 2008 (UTC)

I think a page managed from meta as a default (and modifiable) userpage for a global userpage is a good idea. seresin (¡?) 06:40, 28 June 2008 (UTC)

Alternative: The WikiEditors Wiki

(Or some such name)

Personally, (and especially with all the new global permissions and such), I think that it would be far better to have all userpages on a separate wiki.

This would deal with quite a few issues.

Consider Wikipedia: en:wp:Wikipedia:Wikipedia is an encyclopedia. (Or Wiktionary, or any of the other sister projects)

Any page that doesn't directly serve each project can thus be removed/transwikied from each project. (This also deals with the google question concerning userpages and all other "non-project-specific" pages.)

And on the converse, this removes the need to have to keep an eye on over a dozen user talk pages. (user and user talk namespaces would be disabled on all wikimedia projects)

And implementation for linking? No problem, just set the wiki shortcut to be User: - thus, no need to change any pages to update links, they'd still automatically point to the users' page or talk page. (And User talk: to point to user:talk:).

And it also removes the "appearance" or "feeling" of separate projects. I would presume editors would be more likely to help out at other projects if this seeming wall which highlights too concretely the differences between them. When in truth, they are all wikis.

One thing this would likely eventually cause (however) is global behavioral guidelines/policies.

Content inclusion/disinclusion and naming and other style guidelines may be determined "locally", but editor behavior (such as civility and socking) will likely need to be drawn up globally. (And in some ways it has already I believe?)

And note, just to dispel any possible confusion, this proposal is not suggesting a change to anyone's wiki preferences, edits, watchlists, contrib history, or anything else tied to the user's username. This is merely proposing moving pages to this proposed wiki.

All-in-all, I think that having an editor wiki would be not just a "good thing", but a great thing.

(And for all I know, they may be working towards this already.)

Thoughts and/or concerns are welcome. - Jc37 02:37, 24 June 2008 (UTC)

Statistics

I finished the basic variant of the set of programs which deal with Wikimedia statistics. You may see the first results at Template:Wikipedia statistics, Template:Wiktionary statistics, Template:Wikibooks statistics, Template:Wikinews statistics, Template:Wikisource statistics, Template:Wikiversity statistics, Template:Wikiquote statistics and Template:Wikimedia statistics. --Millosh 13:08, 22 June 2008 (UTC)

Here is the short description of the programs (I'll upload the code at Meta in the next couple of days): --Millosh 13:08, 22 June 2008 (UTC)

• Program "projs.py" is updating projects list once per week:
  • The main purpose of that program is to dump data with codes (and languages) and language names of the main content projects. It is testing every week do we have some new language at the projects other than Wikipedia. Wikipedia codes and language names are taken from Language names page. --Millosh 13:08, 22 June 2008 (UTC)
  • It can't guess new languages or the names of multilingual projects (Meta, Commons, Labs...), so I should be poked when some of such projects become to exist (or I should find a way how to inform myself about that). Optionally, I may get all codes from Incubator (as I have some of them). --Millosh 13:08, 22 June 2008 (UTC)
• Program "getdata.py" is getting data at 00 and 30 minutes every hour (which means something like 5 and 30 minutes in reality). It is using raw statistics page (like http://meta.wikimedia.org/wiki/Special:Statistics?action=raw). All statistics, with date and time information is stored (I'll find a way how to put those data somewhere online). So, from yesterday, it is possible to make hourly statistics. --Millosh 13:08, 22 June 2008 (UTC)
• Program "stats.py" and its modules are generating statistics and, run by cron, it updates statistics at 02:20 CET/CEST (which means 0:20 or 1:20 UTC). --Millosh 13:08, 22 June 2008 (UTC)
• Output is localized (User:Millbot/translations.py is the main page for bot-specific issues; Language names is the main page for language names translations). It may include multilingual templates, too. Actually, Meta "language" code is "multi", so there is the place for multilingual templates. --Millosh 13:08, 22 June 2008 (UTC)

As I mentioned, it is possible to make very detailed statistics: average edits per hour, changes at the daily level and so on. I am asking here for ideas and help in statistics implementation. I may make some SVG images from time to time. Also, in the future it would be possible to merge those data with not so precise statistics and generate long-term statistics; as well as it is possible to make queries at Toolsever and get precise data from the past (I hope so). --Millosh 13:08, 22 June 2008 (UTC)

Global deleted image review

There is a new proposal, Global deleted image review which will grant commons admins the ability to view deleted image and image talk pages on all projects, no other namespaces or sysop rights will be granted by this proposal. Please see the proposal for details.

This proposal has had extensive discussion on the lists, commons admin noticeboard, and elsewhere. It is believed that the current proposal addresses the needs of commons and the interests of our member projects.

The vote will be conducted for two weeks and end on July 6th 2008. If additional time is required to advertise this poll to other major wikis the poll may be extended. All active participants on commons using Wikimedia projects are welcome to vote, no meta activity is required but voters should link back to their home wiki userpages. This proposal will only be approved if it shows substantial support from users at many projects.

If the proposal is approved the actual implementation may need to wait until the version of mediawiki for support for this behavior becomes live on the Wikimedia sites.

Support

1.  Support w:User:Gmaxwell commons:User:Gmaxwell --Gmaxwell 21:46, 22 June 2008 (UTC)
2.  Support --ShakataGaNai ^{^_^} 21:47, 22 June 2008 (UTC)
3.  Support -mattbuck (Talk) 21:49, 22 June 2008 (UTC)
4.  Support - As it has the namespace restrictor I was concerned about, it passes my criteria. MBisanz ^talk 21:53, 22 June 2008 (UTC)
5.  Support - Multichill 21:55, 22 June 2008 (UTC)
6.  Support --ChrisiPK 21:57, 22 June 2008 (UTC)
7. --MZMcBride 21:59, 22 June 2008 (UTC)
8.  Support Greeves ^{(talk • contribs)} 22:00, 22 June 2008 (UTC)
9. Finally, a useful application of global rights. — Dan | talk 22:02, 22 June 2008 (UTC)
10.  Support Luckily somebody was bold enough to pick up my proposal :) This proposal will hopefully make it easier for Commons admins to weed out the bad files and will thus benefit the whole Wikimedia community. -- Bryan (talk|commons) 22:02, 22 June 2008 (UTC)
11.  Support a perfectly reasonable example of how global userrights can be properly and usefully assigned. Prodego ^talk 22:10, 22 June 2008 (UTC)
12.  Support, would be handy for Commons admins — VasilievV ² 22:12, 22 June 2008 (UTC)
13.  Support Would be very useful yes, I am a Wikimedia Commons administrators with unified and global account, and as this is "read only" it expect it will not be controversial at the various other projects. Finn Rindahl 22:13, 22 June 2008 (UTC)
14.  Support – this proposal seems perfectly reasonable. Commons admins are already trusted to deal with images which are globally available, and a read-only permission for only the Image and Image talk namespaces seems like it could be useful while causing no harm. Nihiltres^(t.u) 22:23, 22 June 2008 (UTC)
15. support —DerHexer (Talk) 22:45, 22 June 2008 (UTC)
16.  Support Definitely useful for Commons admins, will also save us having to constantly search out admins on numerous other wikis just to look at a deleted file for us. No risks and lots of benefit. -- Editor at Large • talk 22:51, 22 June 2008 (UTC)
17.  Support Emesee 22:53, 22 June 2008 (UTC)
18.  Support — Platonides 22:55, 22 June 2008 (UTC)
19.  Support — H92 (t · c · no) 22:55, 22 June 2008 (UTC)
20.  Support ken123 22:57, 22 June 2008 (UTC)
21.  Support Mr.Z-man 22:59, 22 June 2008 (UTC)
22.  Support, as a moderately active Commons admin, I find situations where this would be useful at least once a week (today being the latest) —LX (talk, contribs) 23:05, 22 June 2008 (UTC)
23.  Support Hardscarf 23:06, 22 June 2008 (UTC)
24.  Support --Revolus Echo der Stille 23:07, 22 June 2008 (UTC)
25.  Support, seems that it will make things lots easier for Commons admins. I wouldn't mind the considerations Effeietsanders brought up to be addressed, though. -- Natalya 23:09, 22 June 2008 (UTC)
26.  Support -- Marcus Cyron 23:18, 22 June 2008 (UTC)
27.  Support, of course. The positive aspects clearly outdo the negative aspects. --EivindJ 23:19, 22 June 2008 (UTC)
28.  Support This would solve so many problems. Rocket000 23:51, 22 June 2008 (UTC)
29. Yep. --Conti 23:57, 22 June 2008 (UTC)
30.  Support Less work for local admins, potensially more images on commons. Kagee 23:59, 22 June 2008 (UTC)
31.  Support. I see the need for this and I think it is a very sensible solution. I am unconvinced by the oppose comments. --Bduke 00:06, 23 June 2008 (UTC)
32.  Support --Walter Siegmund (talk) 00:07, 23 June 2008 (UTC)
33.  Support Benefits will be vast. Potential for misuse is small. --pfctdayelise 00:10, 23 June 2008 (UTC)
34.  Support Certainly, this will help Commons admins determine deleted images status on other wikis that were moved to the Commons. Gizmo II 00:16, 23 June 2008 (UTC)
35.  Support --Harrywad 00:31, 23 June 2008 (UTC)
36.  Support, this will assist Commons admins do a better job of assisting the projects which use the media on Commons. John Vandenberg 00:35, 23 June 2008 (UTC)
37.  Support. As a sysop on the English Wikipedia I've had to field requests for information that this proposal would have made directly available, streamlining this process, and I don't see much of a downside. —David Eppstein 00:37, 23 June 2008 (UTC)
38.  Support auburnpilot (en.wiki) 00:38, 23 June 2008 (UTC)
39.  Support It would be nice if any admin could browse deleted images on commons too (moving images to local wiki etc.). Beau (talk) 00:46, 23 June 2008 (UTC)
40.  Support --Szczepan talk  00:49, 23 June 2008 (UTC)
41.  Support Ala z 00:58, 23 June 2008 (UTC)
42. GRBerry 00:57, 23 June 2008 (UTC)
43. per Prodego. giggy _(:O) 01:04, 23 June 2008 (UTC)
44.  Support 555 01:07, 23 June 2008 (UTC)
45.  Support Unlike the global sysops proposal above, which do make changes to wiki databases, this proposal's goals do not make changes to any one wiki's database. Furthermore, this proposal's goals can eliminate communication problems with unsuspecting users on other wikis. --O (谈 • висчвын) 02:18, 23 June 2008 (GMT)
46.  Support The proposal would greatly improve the ability of the Commons admins to do their job, and I see no downside in simply allowing them to view (note: not restore) deleted images and image pages. --jonny-mt ^{en me!} 02:27, 23 June 2008 (UTC)
47.  Support I've fielded quite a few of these requests, over the past two years, so I know it could potentially save the commons people quite a lot of hassle to streamline the process. I do share the concerns about image oversight, but that's something we should be working on, regardless, no? Luna Santin 03:18, 23 June 2008 (UTC)
48.  Support --CComMack 04:01, 23 June 2008 (UTC)
49.  Support --Carnildo 04:05, 23 June 2008 (UTC)
50.  Support - Robotje 04:13, 23 June 2008 (UTC)
51.  Support -- BJ^Talk 04:29, 23 June 2008 (UTC)
52.  Support --Florian Adler 04:38, 23 June 2008 (UTC)
53.  Support --Joergens.mi 05:00, 23 June 2008 (UTC)
54. Support --Willscrlt (Talk) 04:52, 23 June 2008 (UTC)
55. Support. Wenn sie im Müll wühlen wollen, warum nicht. Syrcro 05:01, 23 June 2008 (UTC)
56.  Support because that might really ease an often occuring problem with images moved from wp to Commons. --Túrelio 06:05, 23 June 2008 (UTC)
57.  Support --MichaelMaggs 06:31, 23 June 2008 (UTC)
58.  Support --Geiserich77 06:53, 23 June 2008 (UTC)
59.  Support --Stormie 06:56, 23 June 2008 (UTC)
60.  Support --habakuk 08:06, 23 June 2008 (UTC)
61.  Support --Nolispanmo 08:07, 23 June 2008 (UTC)
62.  Support --Millosh 08:55, 23 June 2008 (UTC)
63.  Support Saves time and media. Siebrand 09:12, 23 June 2008 (UTC)
64.  Support I know what trouble they can have with deleted licensing etc etc. Viridae^Talk 09:15, 23 June 2008 (UTC)
65.  Support - give commons admins the tools they need. Angela 09:16, 23 June 2008 (UTC)
66.  Support – reason: [13] --32X 09:30, 23 June 2008 (UTC)
67.  Support as per jonny-mt. I understand the concerns about image oversight, but I agree with Mattbuck and Gregory. --Jastrow 09:41, 23 June 2008 (UTC)
68. --Noddy93 10:06, 23 June 2008 (UTC)
69. support - and I suggest reciprocity, as it would be tremendously helpful if admins on the other projects could review content, deleted on Commons without having to bother their admins. --h-stt !? 10:08, 23 June 2008 (UTC)

    I've thought about reciprocity but I think the permission which would make most sense for the local->commons direction is the ability to protect image pages. ... though flagged revisions may ultimately make that moot. --Gmaxwell 14:56, 23 June 2008 (UTC)

70.  Support - In my experience it's too difficult and time consuming to get hold of an admin who is willing to verify if the source and licensing shown in the history of a deleted local image match Commons standards. Most often this leads to the deletion of the image on Commons as unknown, which is a loss not just for the original wiki and Commons, but to all Wikimedia projects. This proposal solves the problem when the people verifying these things can actually do their work. --Para 10:37, 23 June 2008 (UTC)
71.  Support --Ecemaml 10:42, 23 June 2008 (UTC)
72.  Support --Aqwis 10:51, 23 June 2008 (UTC)
73.  Support, Btd 10:53, 23 June 2008 (UTC)
74.  Support This will make the work of any commons-sysop easyer. abf /talk to me/ 10:56, 23 June 2008 (UTC)
75.  Support Kameraad Pjotr 11:00, 23 June 2008 (UTC)
76.  Support -- Discostu 11:08, 23 June 2008 (UTC)
77.  Support --HAL Neuntausend 11:09, 23 June 2008 (UTC)
78. --Nemo 11:32, 23 June 2008 (UTC)
79.  Support I am unsure why there should be any particular controversy about being able to view an image. Sure - image oversight is required & I would hope would be here soon, however frequently deletion requests on Commons make reference to deletions on other wikis (I had one today) & it is good to be able to check the fact rather than risk mistakes. --Herby ^{talk thyme} 11:45, 23 June 2008 (UTC)
80.  Support --Kjetil r 11:45, 23 June 2008 (UTC)
81.  Support - With the current proposal I don't see any reason why people would oppose it. Althought it might be necessary to create a new global permissions group, this isn't as much of a hassle as the current system is, and it's only a hassle on the front-side rather than a hassle throughout. With only the ability to see deleted pages and revisions, and only in the Image: and Image talk: namespaces, there shouldn't be anything controversial about this. Lifebaka 11:59, 23 June 2008 (UTC)
82. Zanaq 12:06, 23 June 2008 (UTC) Seems like an excellent opportunity to improve the service of commons to the other projects.
83.  Support ZorroIII 12:15, 23 June 2008 (UTC)
84.  Support - definitely an important thing. →Christian.И 12:27, 23 June 2008 (UTC)
85.  Support --Jón 12:32, 23 June 2008 (UTC)
86.  Support --Guandalug 12:34, 23 June 2008 (UTC)
87.  Support --::Slomox:: >< 12:37, 23 June 2008 (UTC)
88.  Support --Tinz 12:53, 23 June 2008 (UTC)
89. Ucucha 13:08, 23 June 2008 (UTC)
90.  Support, while noting that oversight is a problem, but not a big enough one to stop this from going ahead, IMO. rev_deleted may well be around the corner, but even if it is not, we're talking about only viewdeleted. This is absolutely not a significant risk to other wikis; many/most of the oppose opinions amount to arguments against wikis, not against this proposal. If you're worried about us seeing things which should have been oversighted, then they should have been oversighted (even if it requires developer intervention - annoying them is one way to spur work on rev_deleted).  — Mike.lifeguard | ^@en.wb 13:09, 23 June 2008 (UTC)
91.  Support No ability to take action means projects aren't being externally controlled. Helping to avoid having the foundation sued into oblivion is an overriding factor too. WilyD 14:12, 23 June 2008 (UTC)
92.  Support It will make my job reviewing image with faulty permissions so much more easier. Maxim_(talk) 14:31, 23 June 2008 (UTC)
93.  Support It is needed. Majorly ^talk 14:38, 23 June 2008 (UTC)
94. Seems to be mostly harmless. Angus McLellan (enwiki talk) 14:58, 23 June 2008 (UTC)
95.  Support The risk is overrated, and the benefits are great. -- Atluxity 15:11, 23 June 2008 (UTC)
96.  Support rather common problem. Implementing this policy will greatly speed verifying licences. Rama 15:32, 23 June 2008 (UTC)
97.  Support, should make Commons admins' job easier, with not much of a risk -- Imperator3733 16:03, 23 June 2008 (UTC)
98.  Support --buecherwuermlein 16:32, 23 June 2008 (UTC) per 95.
99.  Support - Silver Spoon 16:47, 23 June 2008 (UTC)
100.  Support Deleting stuff to protect privacy is bad practice, I think the advantages clearly overweight the risks. Note that would this to be implemented, all wikis should be notified so they can take the appropriate measures (eg. oversight, once it is available for images). -- lucasbfr ^talk 17:01, 23 June 2008 (UTC)
101.  Support - As I'm no commons-mod (I'm on nl-wiki) I made a few conversations with commons-moderators and as it seems, there are quite some benefits. As I do not see major risks involved in granting these permissions, I support. Mwpnl 17:39, 23 June 2008 (UTC)
102.  Support Great idea. --Flominator 18:04, 23 June 2008 (UTC)
103. --S^[1] 18:56, 23 June 2008 (UTC)
104.  Support This is an excellent proposal MiCkE 19:11, 23 June 2008 (UTC)
105.  Support - Bemoeial 19:18, 23 June 2008 (UTC)
106.  Support --dapete disputa! 20:32, 23 June 2008 (UTC)
107.  Support Edgar181 20:55, 23 June 2008 (UTC)
108.  Support Herr Kriss 21:39, 23 June 2008 (UTC)
109.  Support Vitally needed feature for the Commons sysops, and it in no way infringes local wikis independence. Fully support. →Spiritia 22:23, 23 June 2008 (UTC)
110.  Support howcheng {chat} 00:27, 24 June 2008 (UTC)
111.  Support Zscout370 01:10, 24 June 2008 (UTC)
112.  Support, Nakon 01:14, 24 June 2008 (UTC)
113. Notwithstanding the (valid) oversight concerns...  Support ++Lar: t/c 03:42, 24 June 2008 (UTC)
114.  Support --alexscho 16:18, 24 June 2008 (UTC)
115.  Support It is useful for Commons' admins.--Ahonc 19:04, 24 June 2008 (UTC)
116.  Support Useful, focused and as restricted as one could reasonably expect. - BanyanTree 22:57, 24 June 2008 (UTC)
117.  Support Useful proposal helping establishing of interproject dependencies. The dangers are greatly overrated. In fact I would make it even less restrictive: any admin on any WMF project can view deleted images on any other WMF project. That way we can simplify handling of cases then one image is referenced to a self-made image on another project and then was consequently deleted. Also many images deleted on Commons could be re-uploaded locally according to the rules of local projects (e.g. EDP). Alex Bakharev 03:41, 25 June 2008 (UTC)
118.  Support Wikimedia Commons admins really do need this. --Kanonkas 07:49, 25 June 2008 (UTC)
119. wtf? there are opposes? --Dodo von den Bergen 16:04, 25 June 2008 (UTC)
120.  Support DGG 19:50, 25 June 2008 (UTC)
121.  Support The amount of times I've had to whine other projects admins to "please have a look at this deleted image" justifies this. We're not asking to sell your soul, it's just to see some deleted content. Patrícia ^msg 20:37, 25 June 2008 (UTC)
122.  Support, by all means. An admin on Commons can delete an image shared among several projects, I can't imagine why one would oppose the same person seeing an image deleted on a local project. My first reaction was identical to Dodo von den Bergen's above ("wtf? there are opposes?"). --Gutza 21:40, 25 June 2008 (UTC)
123.  Support I won't have any use for it, but I know plenty of people who this will greatly benefit. Perhaps the oversight concerns will spur adoption of the enhanced deletion system? ~Kylu (u|t) 05:01, 26 June 2008 (UTC)
124.  Support Forrester 09:32, 26 June 2008 (UTC)
125.  Support good idea. Bapti 20:15, 26 June 2008 (UTC)
126. Seems fine. Acalamari 21:00, 26 June 2008 (UTC)
127.  Support Leonard^Bloom 03:52, 27 June 2008 (UTC)
128.  Support --OosWesThoesBes 04:23, 27 June 2008 (UTC)
129. --Euku 08:59, 27 June 2008 (UTC)
130. I see no valid reasons to oppose this, but many valid reasons to support this, including the utility it will provide, and the need it will fill. --Anonymous Dissident^Talk 09:41, 27 June 2008 (UTC)
131.  Support --Mormegil (cs) 10:12, 27 June 2008 (UTC) The possibility of misuse (including by mistake) is extremely limited, and this feature would help Commons admins a lot.
132.  Support RedCoat 11:44, 27 June 2008 (UTC)
133.  Support - Seems like a very good way to help Commons admins do their job. Parent5446 13:13, 27 June 2008 (UTC)
134.  Support A good and reasonable proposal. Captain panda 14:08, 27 June 2008 (UTC)
135.  Support it would tremendously help Commons admins do their job. A lot of transfers from other Wikipedias hide copyvios. Good proposal. Renata3 14:17, 27 June 2008 (UTC)
136.  Support as a Commons admin; this will make our lives much easier. Angr 15:10, 27 June 2008 (UTC)
137.  Support - in contrary to oppositions below and oppositions to #Global sysops (poll) to my opinion we cant work "in common", if local WPs etsteem their deletions policies (and accordingly what is deleted) as privat affair to be hidden from the international community or other local WPs. restriction to Image: and Image talk: namespaces seems appropriate -- W!B: 15:41, 27 June 2008 (UTC)
138.  Support One use which immediately comes to mind: when an image has been deleted from en.wikipedia, because it duplicates an image on Wikimedia Commons, but the original uploader is not identified in the commons file. If the uploader has not been identified in the deletion log, the only way to retrieve that information is by viewing the deleted page. — Athaenara (contribs) 18:01, 27 June 2008 (UTC)
139.  Support this will help commons and inter project relationships --— The preceding unsigned comment was added by Legoktm (talk) 18:44, 27 June 2008 (UTC)
140.  Support Almost no chance of abuse, and it should be very helpful Alexfusco⁵ 22:11, 27 June 2008 (UTC)
141.  Support We already trust them to delete a Commons image, why not trust them to view any image? They are highly unlikely to abuse this privilege. They need this ability to be able to see the edit history of images transwiki'ed to Commons because sometimes transwiki'ed images don't have all of the necessary information. Royalbroil 05:27, 28 June 2008 (UTC)
142.  Support, occasionally it is extremely helpful see the deleted content when making the decisions that we expect Admins to make. We direct Wiki's to take images off their own servers and place the images on commons, We have transferred the responsibility to Commons admins for images moved globally we need to also grant the resources to allows then to review deleted images globally. Jeepday 13:04, 28 June 2008 (UTC)
143.  Support Commons admins are expected to facilitate the management of all free media files, this feature would assist in doing so. Adambro 13:20, 28 June 2008 (UTC)
144.  Support I find the opposes below that run along the lines of "I don't trust commons admins because..." to be a significant breach of AGF, policy on en.wiki and common sense elsewhere. This proposal will not give commons admins the ability to do anything on other wikis without the RfA support of that community, but will enable them to do their job on commons much more effectively. Much ado about nothing, IMHO. Happy‑melon 17:02, 28 June 2008 (UTC)
145.  Support Commons has a unique role because images there can be picked up from any other site (and indeed, some sites such as EN:WQ have hardly any images of their own but rely on Commons). Thus it is appropriate for Commons admins to have very limited cross-wiki functions.--Cato 12:09, 29 June 2008 (UTC)
146.  Support It would be of great use to Commons Admins in verifying Images Histories. --Mifter 20:21, 29 June 2008 (UTC)
147.  Support, sensible and useful. TimVickers 20:57, 29 June 2008 (UTC)
148.  Support, I have seen many cases where an image was copied to commons from some wikipedia without enough details except from a link to the original file in wikipedia, then deleted from that wikipedia leaving the commons image without any source details or other information (author's name for example). This function will be useful for Commons admins to check an image about copyright problems. Geraki ^T_L 07:15, 30 June 2008 (UTC)
149.  Support. This would save me a lot of time and trouble verifying licenses. --Eleassar ^{my talk} 07:26, 30 June 2008 (UTC)
150.  Support. Useful, will improve Wikimedia. No drawbacks that merit serious concern. Quadell 13:02, 30 June 2008 (UTC)
151.  Support I see no major problems that could result from this and I'm sure it will be very useful for Commons admins. Thingg 13:36, 30 June 2008 (UTC)
152.  Support. Sensible idea with clear cross-wiki benefits. WjBscribe 20:35, 30 June 2008 (UTC)
153.  Support Londenp 08:04, 1 July 2008 (UTC)
154.  Support per WJBscribe.--Chaser away 10:14, 1 July 2008 (UTC)
155.  Support - a great improvement. Xenus 14:01, 1 July 2008 (UTC)

Oppose

1. for now:  Oppose Effeietsanders 22:17, 22 June 2008 (UTC) - This is because oversighting of images is not possible. This feature would give a lot more people access to locally deleted images (well, on most wiki's :) ), which can contain privacy sensitive information. Since there is no better way to remove information like this then to delete them, this feature would make it harder to hide that type of information. I would be supportive if this bug in the oversight function is fixed. Please correct me if this has been done already.

   If you can't hide it from the admins on that project, why would you need to hide it from admins on Commons? --ChrisiPK 22:47, 22 June 2008 (UTC)

   It is about the scale. Not the people. Effeietsanders 22:52, 22 June 2008 (UTC)

   I suppose you could oversight the image page, which is where the privacy sensitive information could be (such as uploaders name and address). What sensitive information do you expect to be on the image itself? Platonides 22:55, 22 June 2008 (UTC)

   En.Wikipedia (where most of the problem images come from) has many many more sysops than commons, commons only has 243, en.wiki has 1,563. It is less than a 10th of the size, so scale doesn't seem applicable. Of course, a commons admin would also have to somehow know on what wiki, what image to look for, with no clue how to find it. Prodego ^talk 22:58, 22 June 2008 (UTC)

   If you oppose because of oversight issues, surely it is also important that if there is an issue which requires oversight on an image, that that image be similarly protected on commons? -mattbuck (Talk) 23:10, 22 June 2008 (UTC)

   If you have an image which needs oversighting you can ask a developer to do it. I've had it done at least a half dozen times for child porn and similar cases. Also, The bitfields for rev_deleted feature in mediawiki (already in the code but not activated on WMF wikis) allows oversighting of images by users. Considering that EnWP and most other large wikis are forcefully directing users to commons the number of cases of private data being leaked only in deleted images on the local Wiki should be very low indeed. Effectively commons can already see your local wiki's privacy deleted images: because most of them are being uploaded to commons. --Gmaxwell 23:25, 22 June 2008 (UTC)

   The information is often on the image itself, oversighting the description page often doesn't suffice.

   Oviously, I am not concerned about enwiki, which indeed has already way too many admins, but about the smaller wiki's, with which this would often mean a huge increase in people with this type of access.

   It sounds nice to have to approach a developer, but this is not something that is easily done. If the image would be on commons as well, this argument of course doesn't apply. And no, not all images are uploaded to commons. Maybe a lot from the larger wiki's, but not all, especially if they are deleted quickly. Effeietsanders 06:33, 23 June 2008 (UTC)

   All WMF wikis (except commons) limit upload to autoconfirmed users now. I'm not sure which class of deleted-quickly image you're thinking of, but most such images are already going to commons. --Gmaxwell 14:58, 23 June 2008 (UTC)

2.  Oppose Waerth 22:28, 22 June 2008 (UTC)
3.  Oppose After reviewing the proposal, I don't think this is necessary. Other people have similar problems (i.e.: OTRS people trying to get deleted images restored) and all it takes is a note on wiki someplace, or a note on IRC. - Rjd0060 23:11, 22 June 2008 (UTC)

   That is true, but it also means wasted time all round - local admins need to search for something that they may well know nothing about, and it stops them dealing with local issues. It also annoys them when commons admins have to continually ask for their assistance - commons admins doing this sort of work may have to deal with over a hundred images in a single day. -mattbuck (Talk) 23:19, 22 June 2008 (UTC)

   It may just be a strange coincidence, but I've never seen any instance that this would solve. I may just be missing it, but...(of course I'm not a commons admin). - Rjd0060 23:22, 22 June 2008 (UTC)

   That is probably because most images that would be solved by this "feature" are currently deleted. It is far too much effort to hunt admins down right now to get information. --ShakataGaNai ^{^_^} 23:35, 22 June 2008 (UTC)

   With all respect, as both a commons admin and and OTRS user, I do not agree that the situation is at all the same. Many OTRS users are primarily active for tickets related to home wiki's where they are already Sysops. The jobs of OTRS involve far more than just viewing deleted. Tickets requiring privileged access for the OTRS user's non-primary wiki are fairly rare except for small wiki issues and for smaller wikis the Global sysop proposal (if it ever passes) will address their needs.

   Commons has hundreds of thousands of images brought from other projects with incomplete information. Every time I attempt to do an orderly review of many images I am constantly frustrated by images from other projects. I live with an enwp admin, and have ready access to people on IRC for at least a couple of other projects... but every time I need to check something off wiki what would be a couple of clicks is converted into minutes of nagging and explaining. The net result of this is that people simply skip doing the work and instead focus on easier activities. As far as need, checkout the comments by the commons admins. :)--Gmaxwell 23:25, 22 June 2008 (UTC)

   I fixed your link gmaxwell. Remember the interwiki! --ShakataGaNai ^{^_^} 23:46, 22 June 2008 (UTC)

   I see your point. Still opposing, for the same reason. - Rjd0060 23:28, 22 June 2008 (UTC)

   It's not really about solving a problem, since as you say a solution already exists. It's about providing a solution which is less tiresome for all involved - commons admins don't have to wait around for days waiting for a reply on low activity projects, and local admins on active projectsdon't get bugged by commons people who just want to know whether a file had a source originally. It takes at least ten times as long to explain to someone what you want than it would to just get in and do it - especially in a foreign language where you need to translate every sentence you type. -mattbuck (Talk) 23:30, 22 June 2008 (UTC)

4. I'm not against this particular proposal, per se, but I am concerned about the issue of global rights proposals in general. I'd like to see this proposal, if it is adopted, modified to specify (irrevocably) that all use of global rights will be done in accordance with local policy governing such use, and I'd like it to be reinforced that global rights (this one, global sysops, whatever else) are subordinate to local rights in all cases. Additionally - once the technical opt out for global sysop is implemented, it should be done so that the same opt out impacts all global rights (including this one). Avruch 00:12, 23 June 2008 (UTC)

   The ability to opt out of every global right is silly. Groups are going to want to opt out of one policy or another, and sooner or later 50% of all wiki's have opted out of all global rights... and global rights are useless. People seem to forget that Commons admins already have pseudo-global rights. We control the pictures you use. --ShakataGaNai ^{^_^} 00:26, 23 June 2008 (UTC)

   The point is to prevent a short discussion and vote on meta from implementing changes on all local wikis, even if those local projects object. Meta proposals that pass should not take precedence over local project policies, and the adoption of new user rights needs to respect that. This policy should specifically require commons admins to adhere to local policies regarding the use of global user rights, and if the devs are going to enable global right opt-outs anyway they might as well include them all (except steward). Avruch 00:36, 23 June 2008 (UTC)

5.  Oppose - admins on individual projects are able to view deleted revisions and files because they have individual community trust. Unfortuantely, as an admin on en.wiki, there's a few admins on commons that I wouldn't personally trust to start viewing deleted images on en.wiki. Whilst overall we are one big project, we do operate as seperate entities - trust on one, does not mean trust on another. Ryan Postlethwaite 00:17, 23 June 2008 (UTC)

   What is it about them being able to see your deleted images don't you trust? They can't undelete them - all they can do is see them. --ShakataGaNai ^{^_^} 00:19, 23 June 2008 (UTC)

   I am also confused about quite what might be wrong with someone seeing a deleted image if they can't do anything with it. When you consider it, commons admins are global anyway - what we do can affect all other wikis. This proposal would allow us to minimise disruption on other projects, and possibly allow us to keep more images. Also, commons admins are already somewhat global - we can delete images which may be used on any number of projects, just for kicks. Yet you don't see any problems - we know our jobs, and we know what is reasonable. Allowing us to view your deleted images costs you nothing, but will make life easier for admins on every project. -mattbuck (Talk) 00:26, 23 June 2008 (UTC)

   People seem to think that the only images uploaded to individual projects are free, fair use, or copyrighted images - that's not true. The reason why we stop all users viewing deleted revisions is because there are many other problems associated with them - harassment, attack revisions, BLP revision e.t.c.. The problems with deleted revisions aren't limited to individual edits, they're within images as well. There are many deleted images on en.wiki that I don't trust in the hands of all the commons admins - trolls use images to harass or attack other editors and I within the en.wiki commiunity at least, there's one or two commons admins that aren't seen as the most constructive and have previously failed to gain the communities trust - I don't trust them with images that aren't the run of the mill. Ryan Postlethwaite 00:38, 23 June 2008 (UTC)

   No, we're aware that some free images are local, and that's fine. However, your problem with us viewing deleted images - first off, in 99.999% of cases the images we want to see were deleted because they were on commons. As for the other ones, we'd have to find them, and why would we bother? You seem to believe that commons admins are somehow untrustworthy because they haven't bothered with RfAs on en.wikipedia. We went through our own RfA process, and if there is a problem, you could always just tell us about it on commons:COM:AN. I still fail to see though just how allowing us to see deleted revisions - and I stress this, be completely unable to do anything with them OTHER than see them - is at all controversial. -mattbuck (Talk) 08:32, 23 June 2008 (UTC)

   By viewing deleted revisions, I presume you'd be able to see deleted revisions of the actual image files - sorry, but as I said, I don't trust some commons admins with some of the deleted images we have on en.wiki - the harassment and attack images could easily be used by them and passed onto other people. If they want to have the trust of a community to view these deleted files, they should become admins on that project. Ryan Postlethwaite 13:12, 23 June 2008 (UTC)

6.  Oppose Projects are independent of each other. Surely all it takes is a note on the talk. I think this is problematic.NonvocalScream 01:29, 23 June 2008 (UTC)

   Well I'd just like to point out that all projects are independent of each other - except for Commons. Commons affects everyone and every project. To my knowledge no projects don't use Commons. In fact many are shutting down local image uploads in favor of forcing users to use Commons instead. As for your "note on the talk" - note on the talk of what? Talk page of the deleted image that more than likely no one is watching any more? What if someone responds? I can't possibly visit every wiki every day... We notify the uploaders (talk page) when an image is nominated for deletion, but what if the user used a bot? The bot isn't going to do anything and the user is more than likely not going to notice. Even when the users do know, most of the time they don't do anything. I've had more than a few users ask me what they can do, I tell them to contact the local admin... and 7 days later the image still isn't fixed and is deleted per our proccess. Local users don't want to bother finding an admin most of the time either. --ShakataGaNai ^{^_^} 03:48, 23 June 2008 (UTC)

7.  Oppose for now. I concur with Effeietsanders' "I would be supportive if this bug in the oversight function is fixed." – The proposal sounds very neat of course (I state this as a Commons admin myself), but privacy issues are important too (I think e.g. of several deleted images on de.wikipedia that show really private stuff that still await permanent "oversight/suppress" deletion, and I'm not very happy with 240+ more users being able to see these images without a good reason). --:Bdk: 02:09, 23 June 2008 (UTC)
8.  Oppose for now, and I am a commons admin as well. In theory, and in practice in the main, this is a good idea. However, the potential privacy abuse due to the current problems with not being able to properly oversight images really worries me. I do not think that the trust issue is as strong here, as the right would not allow any changes to the local wikis, just access to the images, but that is exactly the problem with the images that are and should not be (with apologies to Metallica) If we could enact oversight on the images containing children or other personal information that needs oversight, I would support this gladly. -- Avi 03:32, 23 June 2008 (UTC)
9.  Oppose As an admin on en:wikipedia where we have images awaiting permanent oversight, I am totally in agreement with User:Bdk and User:Ryan Postlethwaite. We don't need more users seeing sensitive material than we already have.--Sandahl 03:41, 23 June 2008 (UTC)

   Commons has more images than en.wp has articles. We have 3.6 times more images than en.wp does (Using en.wp since they are the "biggest" wp). It is safe to say we have our fair share of images that could use over-sighting as well. Why do we (Commons admins) need to go to other Wiki's to find these images? Generally local wiki's find these images - and ban the users.... Then the users come to Commons and repeat the process. --ShakataGaNai ^{^_^} 03:53, 23 June 2008 (UTC)

10.  Oppose per Effeietsanders and Bdk. "You can oversight those images" are not practical, since some community (and in the past almost all) tend to use deletion to hide sensitive information.　Commons has already over 100 admins: too much to allow to handle sensitive information. --Aphaia 03:46, 23 June 2008 (UTC)

    In fact according to Small and large wikis/Statistics, Commons has 241 admins. That being said en.wp has 1554 admins. In total less than 16% what en.wp has. That being said, we're admins, they are admins. Theoretically should it not be an equal level of trust when dealing with "sensitive" material? Not relating to how well they help the community - but just sensitive data. --ShakataGaNai ^{^_^} 04:00, 23 June 2008 (UTC)

    ShakataGaNai, your argument is pointless and illogical. I referred to "small" wikis. You pointed out enwiki would not be the case. Enwiki is the biggest among us and with its own oversight right granted users. You opposed me with what I have never said. Aphaia 11:01, 23 June 2008 (UTC)

    Well, there have been examples of commons admins havinbg RfA's that did not pass on enwiki, for what it is worth. -- Avi 04:02, 23 June 2008 (UTC)

    Furthermore, ShakataGaNai, while I agree that in general terms, as no changes to the local wiki can be made, I think that commons admins should be trusted with this right, if we can get the oversight of images implemented. I think that the small, but real, potential harm to a living, breathing person is something we need to give more weight to than our own personal "ease-of-use" when editing wiki. For us its an annoyance; for the person who is adversely affected by the image, it can be their entire piece-of-mind. One stalker is one stalker too many, and anything we can do to minimize the exposure is beneficial. -- Avi 04:10, 23 June 2008 (UTC)

    (re RFA's - edit conflicted) Um. Yea? I would hope so. I know that if I RFA'd on en.wp I wouldn't pass. Why? Because I don't do enough on en.wp to warrant admin tools (I do have a few thousand edits). There is a major difference between an RFA on en.wp and an RFA on Commons. On en.wp you are being trusted with tools that effect 2.5 million+ pages, and a community to go with it. On Commons you are being trusted with tools that effect 2.9+ million images, and 700+ wiki's. --ShakataGaNai ^{^_^} 04:17, 23 June 2008 (UTC)

    (re oversight). Do you guys maintain a list of what needs oversight? The dev's can do that manually right now? I know one right now willing to do it. Additionally, if we have a stalker in the ranks of Common admins - you tell me - We'll investigate. We're no different from any other group of admins, other than the fact that we have to take care of the images from 700+ projects. --ShakataGaNai ^{^_^} 04:17, 23 June 2008 (UTC)

    No, I was not accusing any commons admin of being a stalker, G-d forbid, but in my opinion, I weigh the small chance of increased risk to people against the large inconvenience, and I find the former more worrisome. You find the opposite, unless you think there is no increased chance at all. So we will agree to cordially disagree, at least until such time that a list that can be sent to the devs, or to rev_deletions authorized users, should that be implemented, can be created, and acted upon. -- Avi 04:21, 23 June 2008 (UTC)

11.  Oppose This will lead to some kind of semistewards on Commons, an I will very strongly advise against this kind of role as such. If any admins on Commons needs extended rights on specific projects they should be voted for at those projects. Jeblad 05:24, 23 June 2008 (UTC) (The proposal will effectively merge parts of the projects and as they ar independent today that will lead to serious problems when it comes to who has rights to do what and why. Likewise it will be very difficult to avoid a question about letting admins on the individual projects have the same rights on Commons. Actually I would say it is necessary to give them this right as a result of this vote alone because of the precedence it creates.)

    I entirely disagree with that Jeblad - commons admins deal with issues affecting every project, local admins (say on en) deal with issues affecting ONE project, and there is no need for them to see deleted contributions on other wikipedias. If we (commons admins) need extended rights, we can get them? That's rubbish. I would never pass an RfA on en, because I don't care to learn the 1000s of pages of rules, and because I was once blocked for violating WP:3RR. And I would certainly never pass an RfA on any other project - I created this meta account less than a week ago, and it is my third most active wiki. I believe I have made one edit to the thai wikipedia, and one to the hebrew. Besides, we don't WANT admin powers on these other projects - you're right, that would be dangerous. We don't want to delete stuff on en, we don't want to be able to block people on de, protect pages on fr.wikibooks - we just want to be able to find out where images came from without getting the local admins annoyed at us for nagging them all the time. It helps us and it helps admins on every other project. -mattbuck (Talk) 08:45, 23 June 2008 (UTC)

12.  Oppose --Sargoth 08:28, 23 June 2008 (UTC) for reasons see above
13.  Oppose This will give more users access to deleted images, which may contain sensitive information. I oppose this proposal. Commons may have fewer admins right now, but the number can increase. Masterpiece2000 09:15, 23 June 2008 (UTC)

    In the last week en.wikipedia approved 5 admins, commons approved one. If you are worried about people having access to sensitive deleted stuff - 1) get it oversighted, 2) stop all RfAs. -mattbuck (Talk) 09:21, 23 June 2008 (UTC)

14.  Oppose, -jkb- (cs.source) 09:19, 23 June 2008 (UTC): I understand the reason, but this privilege should not have all commons sysops; it would be enough that some five or ten of them (elected, trusted, estimated by bureaucrat...) have this right, but really not all. Probably, such a person should/could be confirmed by the lokal wiki. See Effeietsanders, Aphaia etc.

    Requiring the user to be confirmed by the local wiki would just put us right back where we started - waiting for goddo to come and give us the info we want. -mattbuck (Talk) 09:24, 23 June 2008 (UTC)

    It's Godot, not Goddo. Stifle 09:50, 23 June 2008 (UTC)

15.  Oppose per Effeietsanders, Bdk, etc. --Thogo (talk) 09:31, 23 June 2008 (UTC)
16.  Oppose. per above and: What about opt-out for large wikis? They have enough admins which are also Commons admins. And from the small wikis it would happen very rarely that an image is transferred from there to Commons, wouldn't it? Have you ever seen an image transferred from zu: Wikipedia to Commons? Or from ba:? So I see no reason for commons admins having this ability. --MF-W 09:42, 23 June 2008 (UTC)

    Why would there be opt-out for large Wiki's? en.wp is the largest, de.wp is up there too. That being said - they send us the most images that are problematic. We really need this for dealing with the largest wiki's the most, of course. As for the smallest, well, they don't send alot of pictures - but that doesn't mean they are less important. It would be rather sad if Commons had to delete 100% of all images transferred (All 1) from zu.wp to Commons - because it didn't have the necessarily information. Their admins are going to be even harder to find also. --ShakataGaNai ^{^_^} 18:01, 23 June 2008 (UTC)

    This exactly is the reason: The big projects have enough people which are admins there and on Commons to look up the deleted versions. --MF-W 13:49, 24 June 2008 (UTC)

17.  Oppose, not appropriate to extend such a large privilege to Commons sysops — best respect to them, but I do not have such a high level of trust in that particular position. Stifle 09:50, 23 June 2008 (UTC)
18.  Oppose As said before, there is no real need to enlarge the amount of users, which may see private information. Furthermore I do not trust commons-admins, as they are not really watched by a strong community. In such a sensitive field, this means way to less control. Denis Barthel 10:21, 23 June 2008 (UTC)

    not really watched by a strong community? That is just insulting. I'd say there's more community on commons than on en. -mattbuck (Talk) 10:27, 23 June 2008 (UTC)

    I'd say there's more community on commons than on en. Dunno. I am at home in de. en is not the only possible comparison. I have never experienced a lot of community in the commons. Denis Barthel 11:36, 23 June 2008 (UTC)

    Let's not get into "who community is nicest" please. Commons is a strong community & well watched by some. I do not see viewing image files as any threat to other projects, merely helpful in allowing Commons admins to do the job better. Thanks --Herby ^{talk thyme} 11:47, 23 June 2008 (UTC)

19.  Oppose - I don't say any reason for interproject-rights. Commons-Admins may be admins in their homewiki to get the rights discussed here, or should ask admins there -- Achim Raschka 12:08, 23 June 2008 (UTC)

    What if their home wiki is Commons? --O (谈 • висчвын) 16:27, 23 June 2008 (GMT)

    Commons is my Homewiki. I do almost no work anywhere else. I know more than a few of our Admins are the same way. Commons is there home and they spend all of their time there. --ShakataGaNai ^{^_^} 18:03, 23 June 2008 (UTC)

20.  Oppose - I took a long time coming to this decision, but I do not feel that the addition of global rights to view deleted images to Commons admins is a good thing - when collaborating with the local project admins is already a very workable and simple solution to the "problem". The commons noticeboard did not hinder the opposition, either, with members supporting a full "view all deleted items until it's technically possible to just let us see images". This proposal is removing local processes and granting powers that may not be required. --Skenmy 13:08, 23 June 2008 (UTC)

    Also, a technical opt-out needs to be made available for any global group on a per-wiki basis. --Skenmy 13:13, 23 June 2008 (UTC)

21. It should be solved in software, not by granting people more rights. If a media file is both on a local wiki and on commons, it shouldn't be deleted but marked as "on commons". That would not destroy information about the media file. Erik Warmelink 14:29, 23 June 2008 (UTC)

    I don't quite see how that would work, as not all the now-commons images were moved in a bit identical manner, and even if we were to invent something there are still an enormous number of images that were previously moved. Now that all project except commons require autoconfirm for upload (if local upload isn't entirely disabled) it's not a major issue going forward, but for the past activity it still is. I can't see there being a viable proposal which would undelete the several hundred thousand commons moved images on enwp alone. --Gmaxwell 14:31, 23 June 2008 (UTC)

    Please too all. Could you stop to comment all of the others comments? It's an arrogant behaviour and not in in a friendly way. Marcus Cyron 17:11, 23 June 2008 (UTC)

    I do not understand Erik's suggestion enough to see how it would be possible. He may have a great idea, but if I can not understand it I can't help make it happen. --Gmaxwell 17:56, 23 June 2008 (UTC)

    To quote Mattbuck "in 99.999% of cases the images we want to see were deleted because they were on commons". If commons doesn't want images to be deleted, make it so. That's rather easy for commons admins, if the "mother"-wiki of an image (or other media file) had deleted it, it is deleted on commons too; the deletionists will be treated like the vandals they are and 99.99% of the problems of commons admins with deleted images would be solved. That would cost some bandwidth if the servers wouldn't tell clients to reload images (but the servers do tell clients to reload images, so even that problem is moot). As a bonus, the people whose images (and other media files) are used can read the description in their own language. Well, they could protest the use of their images (&c.) in their own language too and that might be a problem. Erik Warmelink 02:42, 26 June 2008 (UTC)

    That's not really a technical issue, local admins would just need to stop deleting images, right? Rocket000 11:49, 24 June 2008 (UTC)

    Yes Erik Warmelink 02:42, 26 June 2008 (UTC)

22. Oppose, per Effeietsanders, Bdk, etc. And as Marcus said, stop commenting on opposing votes unless you really have found a point that's stated wrong. And no, not having your opinion does not mean the person is wrong. --Chrislb 17:42, 23 June 2008 (UTC)

    I'd say let them comment. That way their concerns can be addressed. For all the comments I've left, I don't think I've told a single person they are "wrong". Certainly not. This is a vote and people are entitled to their opinion. But maybe someone is making a misinformed decision, maybe we can help fix that. Plus, for every comment left - we gain a little more insight about what people don't like and want. So if this should pass, we will have a baseline for policy on how to use it. If it doesn't pass, we know what to fix for next time around. --ShakataGaNai ^{^_^} 18:06, 23 June 2008 (UTC)

    I'd like to add a short note: People on commons have much work to do and I appreciate the huge pile they go through each and every day. Though I still don't appreciate the technical implications, and I believe the overall system should be changed instead of going the "easy way" of giving global rights. --Chrislb 18:43, 23 June 2008 (UTC)

    What "Technical implications"? You mean the worry that someone on commons will get ahold of "dangerous" images. Also - How do you suggest the "overall system should be changed"? I only see two options right now: #1 - All wiki's start doing a proper job of transferring images (or not transferring the ones lacking critical information). Or #2 - All wiki's stop transfering images period. Of course neither of the "options" I can see fix the 100k or so images that are already on Commons that we will eventually have to delete. --ShakataGaNai ^{^_^} 19:33, 23 June 2008 (UTC)

    If I've believed this to be a good place to discuss these topics I would've been more precise on what I meant, I do actually prefer discussing on discussion pages. While being at it: Mediawiki is a bad system for a multilingual media file repository. The infrastructure evolving around it thus is crippled. Then again giving common admins access to local data is a simple solution though not doing anything about the real problems. --Chrislb 19:53, 23 June 2008 (UTC)

23.  Oppose because this is the wrong place to ask for this right. Ask for this right on the various Wikis: Maybe the English Wikipedia will say "sure, global sysops can view our deleted images" but the French Wiki will say "no" or vice-versa. Rephrase the question to "Create the technical infrastructure to allow Wikis to grant global sysops deleted-image-viewing rights" then I'd say yes in a heartbeat. However, as long as the proposal is to force this down every wiki's throat, I'm adamantly opposed. By the way, if the proposal is raised on a Wiki I participate in, I will probably vote "yes" for that particular Wiki. Davidwr 18:17, 23 June 2008 (UTC) rephrasing per comment below # because this is the wrong place to ask for this right. Ask for this right on the various Wikis: Maybe the English Wikipedia will say "sure, specific people who are not our administrators can view our deleted images" but the French Wiki will say "no" or vice-versa. Rephrase the question to "Create the technical infrastructure to allow Wikis to grant global sysops deleted-image-viewing rights" then I'd say yes in a heartbeat. However, as long as the proposal is to force this down every wiki's throat, I'm adamantly opposed. By the way, if the proposal is raised on a Wiki I participate in, I will probably vote "yes" for that particular Wiki. 76.185.205.210 02:39, 24 June 2008 (UTC) <-- note this timestamp is after the first comment below.

    Commons administrators are not global sysops (if there were such a thing and Commons administrators were it, they wouldn't need this ability, since this ability is a very limited read-only subset of administrative privileges), and this proposal has nothing to do with the global sysops proposal. —LX (talk, contribs) 00:47, 24 June 2008 (UTC)

24. I can't support global permissions without the permission of the local communities as well. If it came to a vote on the English Wikipedia, I would vote in favor of this, but I can't support this policy without the ability for individual project opt-out, because I feel strongly that local projects should be able to control themselves. Ral315 (talk) 19:49, 23 June 2008 (UTC)
25.  Oppose I see this as taking too much power out of the hands of the local wikis. We might not know someone's getting sysoped on commons, we may have info about their trustworthiness that isn't addressed on commons. If someone misbehaves in a way that makes us not want them to have access to sensitive stuff on a local wiki, how will we deal with that, by going through a process at commons? I feel like a better way might be an unbundling of image viewing that can take place on individual wikis; that way people from that project could retain control. Seems like there'd be more accountability that way. Delldot 20:26, 23 June 2008 (UTC)

    An unbundling of image viewing? Could you explain that please? And this is taking absolutely no power away from anyone. Commons admins can't do anything other than view deleted images, and local admins still have all their power. As for seeing sensitive stuff, get it oversighted then there's no problem. Besides, we're not on the lookout for your dirty laundry, we just want to be able to do our jobs. -mattbuck (Talk) 21:20, 23 June 2008 (UTC)

    Sorry, I didn't make myself very clear. I was thinking of unbundling the viewing deleted image right on the local wikis, the way rollback has been unbundled on en. Yeah, that would require the right to be given out on each wiki, much more cumbersome, unfortunately. But this would allow the local wiki to retain power over who has these rights on their wiki. My concern was more along the lines of someone being trusted on commons but not necessarily on other wikis. I certainly didn't mean to imply that I wanted local admins to retain more power, yuck! :P I was more talking about the power to hold people accountable for what they do on that wiki. Hope I'm being clear now, but if I'm not definitely feel free to ask for more clarification. Delldot 21:55, 23 June 2008 (UTC)

26. I  Oppose for the reasons above. --Albert galiza 21:58, 23 June 2008 (UTC)
27.  Oppose For the reasons above. --Sozi 12:57, 26 June 2008 (UTC)
28.  Oppose If Commons admins want the ability to view deleted image and image talk pages on a project, they should be an admin on that project. Just because a Commons admin is trusted on Commons, does not necessarily mean local projects trust them.--Rockfang 09:39, 27 June 2008 (UTC)

    There are 700+ projects. Requiring any particular commons admin to be a full blown admin on all 700+ is not practical... This is a limited permission, made possible by the new global groups functionality, not full blown adminship. It enhances the ability of Commons admins to investigate deletions and movements of images, and improve descriptions and licensing, which benefits all 700+ projects. But it is a passive permission only, it does not grant any active rights like restoration. ++Lar: t/c 15:29, 27 June 2008 (UTC)

29.  Oppose per what Ral said. I'm pretty sure that some commons admins/crats would fail in other languages' RfA. If they can examine something deleted in, say french wikipedia, without letting the French community to examine this candidate, that's a major flaw. OhanaUnited^{Talk page} 17:08, 27 June 2008 (UTC)

    I'm fairly sure alot of us would (fail), simply because we aren't active in those communities. A good portion of what RfA is, is a vote to see if the community is comfortable with giving that person god like powers (read: delete stuff). I know I wouldn't pass an RfA on en.wp, because I barely do anything there. For myself and a lot of Commons admins, Commons is our home project - not just something we do in our spare time. At the same time, we're not asking for full admin permissions on every project, we're not even asking for half of the permissions, just one tiny view ability. So I'm not sure why the idea of an "RfA" is even involved. --ShakataGaNai ^{^_^} 18:13, 27 June 2008 (UTC)

    I'm referring to those that're active in both commons and their native language. OhanaUnited^{Talk page} 21:44, 28 June 2008 (UTC)

30.  Oppose - I oppose this for the reason I gave at Commons. A user whom the English Wikipedia has explicitly decided not to trust with the admin tools should not be given a subset of those tools by another Wiki. If it were possible for an individual wiki to remove the permission from a particular user (ie, it is automatically granted to all Commons admins, but any local crat can take it away upon either abuse or community decision), then I wouldn't see a problem with it. As an enwiki admin, I have not been working image issues as much as I used to, but when I did, I would frequently find a copyvio image has been moved to Commons and then need to go find someone there to delete it. Should enwiki admins be given partial adminships on Commons so that we can delete images without having to trouble ourselves with the local processes/customs? No? Then why would you have other wikis do the same for Commons? --B 22:10, 27 June 2008 (UTC)

    Well the permission to delete images is different then the permission to view the deleted content. Furthermore, Commons Administrators were made admins on Commons because they have been trusted to work with images on commons and this permission is for verification of licenses. Alexfusco⁵ 22:17, 27 June 2008 (UTC)

    What do you define as "explicitly decided not to trust". About the only case that I can think of, is that someone has been banned (wouldn't be able to access it anyways) - or a user that has had their Adminship revoked (is it not possible for them to learn from their mistakes?). Any other case (say a failed RFA) is not "explicit" it is simply a failure to garner the needed support (Remember... AGF). Additionally, If you see a copyvio on commons. Feel free to "Nominate For Deletion", it is fast (5 seconds, for a good 'net connection), easy (2 clicks), and ANYONE (Even IP's) can do it. So... You don't need deletion. On the other hand where is the fast and easy meathod for Commons admins to help keep YOUR images. Name one wiki based solution that takes less than 10 seconds. That is the point of this "tool". Allow Commons to do their jobs more efficiently and save your images. --ShakataGaNai ^{^_^} 05:48, 28 June 2008 (UTC)

    Well, there's one Commons admin whose December 2007 en wiki RFA failed with only 15% support. 187 users opposed the RFA. So that's a pretty affirmative statement of not being trusted. As for your suggested alternative of nominating the image for deletion, this flagrant copyvio took over a month for a Commons admin to resolve. This one took an unbelievable 4 months. On the other hand, a commons admin asking for help on WP:AN would probably get the information they need or a temporary restore in under 10 minutes. I don't think it's too much to ask those commons admins that we as a community do not trust with the tools to take that 10 minutes. --B 17:23, 28 June 2008 (UTC)

    I'm sorry, but you're opposing because, like most wikis, commons has a backlog which needs to be sorted? Heck, en has a category for backlogs. Yes, some stuff is copyvio and it can take a while to get to it if people don't tag it with {{copyvio}}. We're trying to work through the DR backlog, and we're making good progress. That is not a reason to oppose, in fact it's a reason to give us the power, since we won't waste time trying to explain what we want every time we will be able to look and then go on to the next image. And, for crying out loud, "commons admins that you don't trust" - say he has failed an RfA. Fine. You're not giving him the power to delete stuff or make major decisions about the wiki, you're giving him a power with which he could do precisely nothing to harm your interests. If he was truly not trusted, he would be banned. Why would a commons admin want to go and look through all the millions of images you have deleted to find the "attack images" - it would be easier to just create their own, which would lead to them losing admin powers on commons. Seriously, finding an "attack image" is easy - this is the internet. But consider this: there are two sorts of people liable to abuse power. 1) People who like abusing power. These people would never have become admins on commons. 2) Those who just snap one day for some reason. There's nothing you can do about that, and frankly they could be disruptive without looking through your deleted images. -mattbuck (Talk) 00:15, 29 June 2008 (UTC)

31.  Oppose per Ryan Postlethwaite and Effeietsanders. --Brownout^(msg) 06:28, 28 June 2008 (UTC)
32.  Oppose Per the convincing reasons above. seresin (¡?) 06:41, 28 June 2008 (UTC)
33. for now:  Oppose following Effeietsanders and others, although, with one exception, "my" wikis are not concerned. Commons admins have not been voted for, and as such cannot automatically be seen as trustworthy, on local projects. As soon as the privacy issue is solved, I favour the proposal. Viewing deleted images and their description pages should be a time saver, and safe enough, when local admins can hide problematic ones. --Purodha Blissenbach 10:11, 29 June 2008 (UTC)
34.  Oppose Given the very real wikistalking and privacy issues already addressed. Online harassment is not to be taken lightly and once someone's privacy is compromised it's not so easily reversed. Many good admins and editors have retired rather than deal with ongoing harassment. Until we have a higher standard to ensure compromising material is kept under wraps it will need to be guarded by those entrusted with that task. If some piece of information is needed en.wiki seems to have some very active admin boards so assistance is always at hand. Benjiboi 13:48, 29 June 2008 (UTC)

    We're not talking about enwiki, but rather about all wikis. Please take a larger view of this issue and rethink your conclusion.  — Mike.lifeguard | ^@en.wb 01:11, 30 June 2008 (UTC)

    Correct me if I’m wring, but it appears that you also think that commons admins will be able to see the deleted history of every page on whichever wiki. Read the introduction, it’ll only “grant commons admins the ability to view deleted image and image talk pages on all projects, no other namespaces or sysop rights will be granted by this proposal.” — H92 (t · c · no) 22:56, 1 July 2008 (UTC)

35.  Oppose --Svens Welt 14:20, 30 June 2008 (UTC)

Neutral

• I'm sitting on the fence right now. I agree that there is a large problem with images that have been brought to Commons from other wikis and I thank the users presenting this proposal for addressing it. The problem needs to be discussed to see if a good solution can be found. This proposal certainly has the potential to help speed up the process and that is good.

• But I share some of the concerns stated by others in the discussion. Some admins on Commons have lost the trust of their local communities and been desysopped or resigned their tools "under a cloud". I can see potential problems with them having access to deleted material of any kind. This needs to be addressed in some manner, I think.

• Currently, a Commons admin or editor needs to collaborate with a local admin to sort out problems with images, or have admin access on the local wiki. In general, I think that is a good, not bad. Local admins need to understand image related issues so that they can help prevent future problems as well as fix past problems. My preference would be a collaborative project developed rather then to bypass the local community. Recruiting more local admins to have admin access on Commons seems to be a better longterm solution. FloNight 12:17, 23 June 2008 (UTC)

  Long term is already solved: Users don't get the right that allows local upload until they have been around long enough to know to upload their free images to commons. With only a few exceptions all the new commons-eligible image upload traffic is already going straight to commons. The issue of significance is the hundreds of thousands of old images transfered from other wikis with incomplete or misleading information. Coordinating one offs for each of image for routine checking is obnoxious in the extreme since it either requires two people to do one person's work at half or a quarter the speed, or the work to be limited to the much smaller pool of people who are admins on both projects (and whos time is already split). I can't say that it's an impossible situation, since we've survived it for a number of years but as we dig deeper into the backlogs it becomes a more and more material issue and it's already clear that it's hindering work. Thanks for your thoughts. --Gmaxwell 14:42, 23 June 2008 (UTC)

  That's not true. If a media file has insufficient publicly accessible permission to be included on commons, the image has insufficient permission to be included on commons. The creator of a file doesn't lose his/her copyright, just because a member of a very small group of people says/writes (s)he thinks it is OK to copy it. That fact doesn't change if the member of the very, very small group states that (s)he saw something on a page which is only viewable by said very small group of people and another similarly small group of people. Erik Warmelink 21:01, 27 June 2008 (UTC)

1. Neutral I would prefer the long term solution to recruit more people who become admins in both Commons and another project, like me. This proposal does not realistically "open up every single project" IMO. There will be many cases where I would have to contact a local admin anyway to translate the delete image description page into my native language, the web site linked as the image source, etc. Zzyzx11 17:10, 29 June 2008 (UTC)

   For some languages, true, but for the ones which are most used - french, german, spanish, portuguese etc; passable internet translation services exist. -mattbuck (Talk) 01:06, 30 June 2008 (UTC)

Comment

Gregory, can you please expand on the potential to oversight images that you said is already built in to the mediawiki code, please? -- Avi 03:34, 23 June 2008 (UTC)

• Bitfields for rev deleted. --Gmaxwell 03:43, 23 June 2008 (UTC)
  • Note that although rev_deleted is not yet enabled on Wikimedia, it is already for a large part in the core MediaWiki software. So it should not take too long until oversighting images is possible :) -- Bryan (talk|commons) 09:20, 23 June 2008 (UTC)

I just noticed it = not known on the projects I'm active. How can it be a global vote without global promotion? I am skeptical its validity. --Aphaia 03:50, 23 June 2008 (UTC)

• I dropped a notice on w:WP:AN and the enwiki pump, but I think something this basic should be given the wikibanner treatment, similar to the global sysop discussion and the board vote. -- Avi 03:53, 23 June 2008 (UTC)
• Aphaia, it's only been open for a few hours. It's been advertised here and on foundation-l, commons users were asked to solicit comments from their hope projects, and many have been, but people are still waking up. --Gmaxwell 04:13, 23 June 2008 (UTC)
• I know that it was also posted on nl.wp and de.wp. And like GM said - it just started - you have 2 weeks to "notice it". --ShakataGaNai ^{^_^} 04:22, 23 June 2008 (UTC)
  • And GM also posted a note on WikiEN-l too, so it has had decent exposure, although I'd still like the banner treatment, if possible. -- Avi 04:23, 23 June 2008 (UTC)
• I've left a note on the English Wikisource's Scriptorium (as we were asked to advertise at our "home projects"). giggy _(:O) 07:05, 23 June 2008 (UTC)
  • Posted at no:wikipedia:Tinget Finn Rindahl 10:51, 23 June 2008 (UTC)
• This permission would be nice on a per-user, per-project base. I am unlikely to become an en admin in the recent future, but I need this permission and I think I could get enough pros on en for limited rights. Nevertheless, there are some commons admins which should never see some of the deleted files at german wikipedia. Code·is·poetry 10:00, 23 June 2008 (UTC)
  • Why? What is in german wikipedia? Is that what the librarians are hiding? -mattbuck (Talk) 10:35, 23 June 2008 (UTC)
• Herbythyme, above, answering to somebody: Let's not get into "who community is nicest" please. Commons is a strong community & well watched by some. Well, this discussion here (and the oppose voices) is not on better or worse community, but on the experience with communities as a whole. My experience is that the commons community is not different from other ones. Therefore I say NO just like I would say No if all admins from en.wiki or all admins from nl.wiki or other ones should get the rights of sysops (thou limited) on my project. It is not true that commons admins are controlled more than admins on other projects. I will support the idea, sure, but not in this way. -jkb- (cs.source) 12:12, 23 June 2008 (UTC)
  • "I will support the idea, sure, but not in this way." - Without trying to contest your vote, if you say your experience is the same with all communities, in what way do you think you could support the idea? giggy _(:O) 11:24, 24 June 2008 (UTC)
    • just as I stated above and in talks: at least opt-out must be granted, and these right are not avaiable generally for some hundreds of admins, but for a much smaller group that is beeng trusted by others, -jkb- (cs.source) 11:44, 25 June 2008 (UTC)
  • It is not your project. For someone who has indefinitely banned me from cs.wikisource, you should not even comment about "abuse of adminship" on other wikis. Look in a mirror for a change. -- Cat ^chi? 11:23, 25 June 2008 (UTC)
    • please stop tis harassing again. Or did you forget this RfC??? Or should I give more links on more domains??? -jkb- (cs.source) 11:44, 25 June 2008 (UTC)
• Comment How would this be granted? It should be automated so we do not nag stewards all the time. -- Cat ^chi? 11:09, 25 June 2008 (UTC)

  As for oppose votes, I cannot even think of why seeing deleted images would cause problems. I do not see what "abuse of power" is there in question. Sensitive stuff (such as personal info) must NOT just be deleted, they must be oversighted out. Abuse of power is a risk but not a valid concern. Commons is a well regulated wiki, no "abuse" of adminship would go unnoticed. Commons has a very low tolerance for such nonsense, much less than any wiki I know. -- Cat ^chi? 11:09, 25 June 2008 (UTC)

How to create new section/topic in Wikipedia

Greetings,

I would like to begin the process of creating a new section/topic for ThwartPoker.

ThwartPoker is a new *patented* class of card games that follow the rules of poker, but completely eliminates the random aspects of normal poker. Because the random elements have been eliminated, ThwartPoker is legal to play for money and prizes as it is not properly classified as a gambling game.

ThwartPoker Inc. is a developer, publisher, and distributor of interactive strategy card games. The company made gaming history in 2004 when it introduced the next evolution of traditional poker, made possible by patented software that replaces the random aspects of poker with skill and strategy. Because ThwartPoker games are 100% skill-based, they do not violate U.S. federal gaming law. A mobile version of ThwartPoker titled “Hold’em Poker+ For PrizesTM is available on Verizon Wireless, T-Mobile, and AT&T - made possible through a licensing deal with Twistbox Entertainment. The company is headquartered in San Francisco, California.

Disclaimer. I am the Co-Founder of ThwartPoker.

Its spam. I hope they do not try and create an en wp. --Herby ^{talk thyme} 11:54, 24 June 2008 (UTC)

Please try creating the page at this website. Thank you. Majorly ^talk 00:44, 24 June 2008 (UTC)

Global rights policy proposal for discussion

Please see Global rights for a proposed policy governing the establishment, implementation and use of new global user rights. Avruch 01:53, 24 June 2008 (UTC)

Puntori as a bureaucrat

Puntori has been voted by the sq.wikt community to be a bureaucrat: here. Could anybody give him the bureaucrat status, please? Thanks. I know this place may not be the best for this request but I could not find the proper page to do it and I do not have much time. --Piolinfax ^(@es.wikt) 17:22, 25 June 2008 (UTC)

Go request it here OhanaUnited^{Talk page} 21:44, 25 June 2008 (UTC)

Nope, already done 2 weeks ago--Nick1915 - ^{all you want} 09:35, 26 June 2008 (UTC)

HELP NEEDED

As you probably noticed CommonsDelinker removed a lot of images that were deleted and SHOULD NOT of been deleted by me. If you have a toolserver account, could you please run a query on all of the wikis and get the links to undo any changes made by CommonsDelinker on June 27th with "Monobi" and "OTRS" in the edit summary? Also, could the admins on their wikis check and make sure that the edits are rolled back? Thank you, Monobi (talk) 04:15, 30 June 2008 (UTC)

I'll poke at it. OverlordQ 04:50, 30 June 2008 (UTC)

Wikipedias: de, es, en, fr, it

Wiktionaries: none

Wikinews: none

Wikiversities: none

Wikibooks: none

I've checked all of the bot's edits on the toolserver's cross-wiki contribs page and have undone all of the ones with "Monobi" and "OTRS" in the edit summary from the past week. Nakon 05:27, 30 June 2008 (UTC)

Hrm, some got missed, like on the polish wikipedia. Monobi (talk) 05:29, 30 June 2008 (UTC)

All edits on the 27th

Same, but ignoring lang = (it|fr|en|es|de). OverlordQ 05:53, 30 June 2008 (UTC)

CD reverted on pl-wiki. Beau (talk) 06:24, 30 June 2008 (UTC)

Reverted on nlwiki using Special:Contributions. Didn't know you already had a list of diffs. --Erwin(85) 08:01, 30 June 2008 (UTC)

Done: Disputed edits on de.wiki have been reverted this morning. →Christian.И 09:53, 30 June 2008 (UTC)

Done, Nakon has done all on ar.wikipedia!--OsamaK 16:04, 30 June 2008 (UTC)

http://toolserver.org/~str4nd/monobi.tmp/ — ”Monobi” and ”OTRS” by CommonsDelinker from s2 (20 June – 29 June). — str4nd ☕ 17:01, 30 June 2008 (UTC)

Done in Russian Wikipedia, thanks User:Beau. Sister projects were not affected. — Kalan ? 11:00, 1 July 2008 (UTC)

Done in dewikipedia, according to [14] --Church of emacs 11:33, 2 July 2008 (UTC)

Sysop out of control

What can be done against a sysop on the rampage, if the local Arbcom is disfunctional as on nl:Wikipedia? Regards, Guido den Broeder 07:44, 3 July 2008 (UTC)

The problem needs to be addressed by the local community. Discuss the local situation there and determine what the community would like done, then implement that decision as a community. Meta can't make the decisions of a community for them, only assist in implementing those decisions when needed. Kylu 07:50, 3 July 2008 (UTC)

Tried to, the sysop blocked me, as well as my IP address, and took away my email privileges. Guido den Broeder 08:01, 3 July 2008 (UTC)

The Dutch ArbCom assigned Oscar as Guido's mentor as the result of a request for arbitration. Guido has made clear that he doesn't agree with this. One of his friends even organized a poll about stopping the mentorship, which didn't succeed and received a lot of resistance. In short, the mentorship has been assigned by the Dutch ArbCom and has sort of been confirmed by nlwiki's community. As his mentor Oscar has blocked Guido. Apparently the Dutch community agrees, so please don't come to Meta complaining about this. Oscar is not a sysop on rampage! Please don't misuse Meta for what appears to be your own rampage. The Dutch Wikipedia should deal with it and if you don't like how they do it, please don't come complaining here. --Erwin(85) 08:47, 3 July 2008 (UTC) (nlwiki and meta user)

The above information is entirely incorrect. Guido den Broeder 09:22, 3 July 2008 (UTC)

What I am talking about here is a sysop who:

• Deals out long, random blocks to numerous users without any ground whatsoever
• Vandalizes user space, including the deletion of his own talk page, thereby hiding information relevant to current Arbcom cases against him
• Has caused the Arbcom to withdraw
• Refuses all discussion
• Makes slenderous remarks and constantly insults other users
• Falsely accuses various users of sockpuppetry
• Insults users on the IRC channel and then blocks them from it (today the Wikizine connection was even closed altogether, not sure if he caused this but the effect is obvious)
• Thinks he can unilaterally decide to be someones mentor using this only to ensure that a block cannot be undone by admins
• Thinks he can unilaterally decide that no user on nl:Wikipedia is allowed to refer to a user's scientific publications (even though the same publications can be found on e.g. en:Wikipedia)
• Etc.
• Has been under heavy criticism from the community for months Guido den Broeder 09:36, 3 July 2008 (UTC)