Meta:Babel

Note: If you seek the language competence templates, see Meta:Babel templates.

Hello,
especially for smaller wikis it is very interesting how many visitors are attracted daily/monthly!

WikiCharts was/is a nice idea, but figures have been wrong for the last months, and the last weeks (like several times, now) it just does not work!

I have made a JavaScript script which will do similar for combined use with an external (Wikimedia or own) server.

My script eventually will only count the number of visitors/IPs, and it will not expose sensitive referrers, except a given meaningless address!

External (non-Wikimedia) server? Please read wikt:als:Benutzer:Melancholie/monobook.js carefully!

Here my question: Is this idea conform to our Privacy policy? If not, will you allow projects to expand their privacy policy a little bit towards this feature? --- Best regards, Melancholie 02:58, 15 February 2008 (UTC) Reply

You may be interested in user:midom's statistics at http://dammit.lt/wikistats/ .Hillgentleman 21:32, 16 February 2008 (UTC) Reply

Thank you very much for this link! It's better than nothing, but it is not really a Visitor Counter but a Hit Counter! My suggested counter will be a pure visitor counter! The "problem" with Midom's hit counter is that it is based on the squid access-log stream, and thus probably most bots, reloads, crawlers etc. are counted, too! --- Thanks, Melancholie 06:06, 17 February 2008 (UTC) Reply

P.s.: Furthermore (like so often) only Wikipedia, Commons and Meta have been considered for that stats, yet!

It would be great if every article would display history of visits.--Piotrus 14:56, 22 February 2008 (UTC) Reply

Wikipedia users and editors have been asking for this for ages. Everyone wants a timestamped visitor counter for each page. The problem appears to be twofold: First, coding time and second, computation resources. -Kslays 21:23, 25 February 2008 (UTC) Reply

I don't think the first one is a problem! Huji 07:50, 27 February 2008 (UTC) Reply

Previous discussion is archived.

I don't see any reason provided in the discussions why the colors were changed. The new colors really are counter-intuitive. Moreover, as it was already noticed, meta is the central coordination platform for all Wikimedia wikis. Having a different color code for babel templates will confuse everyone. I see the color code can be personalized in the new template, but I think default colors should be the old ones. Thanks. guillom 08:57, 9 February 2008 (UTC) Reply

Ik ben het helemaal eens met Guillom. De kleuren die er nu op gezet zijn, zijn triest en ongelukkig gekozen. Het voelt zowat als een beschuldiging met het donkergrijs als je "slechts" een -1 hebt, terwijl het eigenlijk een complimentje hoort te zijn. De standaardkleuren dienen sowieso de oude te zijn wat mij betreft, en ook alleen in de taal waar het over gaat als het aan mij ligt. Mensen zijn intelligent genoeg om te snappen wat er staat, zeker als er meermalen onder elkaar hetzelfde staat. Ik zie dan ook niet de noodzaak in om nu na tien dagen discussieren hier dit botmatig dwingend te gaan wijzigen. Ik zie overigens ook niet in waarom de oude sjablonen niet naar de nieuwe kunnen blijven bestaan, en waarom dit nu weer allemaal onder "old" geplaatst moet worden. Dit soort veranderingen kan wmb beter langzaamaan gaan, zodat mensen er aan kunnen wennen en het zelf kunnen doorvoeren. Effeiets anders 14:26, 9 February 2008 (UTC) Reply

Translation: "I totally agree with Guillom. The colors that we put on now are sad and unfortunate. It feels almost like an accusation with a dark gray if you "only" have a -1, whereas it should actually be a compliment. The old standard should anyway be what I am concerned, and only in the language it is about if it was up to me. People are intelligent enough to understand what it says, especially if there are several others on the page with the same standard. I therefore see no need, after ten days here discussing, for this mandatory bot work to go ahead. I also see no reason why the old templates cannot continue to exist alongside the new , and why now all of the "old" templates need to be placed. This kind of change can be made more slowly, so that people can get used to it and it can carry itself out." —translated by Pathoschild.

The new colour scheme was chosen as a progression of related colours. If you don't like the colours, suggestions are more than welcome. However, you are more than welcome to use the old babel format, and this is explicitly stated in the edit summaries when updating. Compare:

{{user nl}}

{{babelold|nl|N}}

{{user language|nl|N}}

{{babelold}} contains the babel format in one template but uses the new text and categories. We could conceivably place it on every babel template page, but this would be more work in the future and most users would not even realize the templates are superseded. :) —{admin} Pathoschild 20:03:23, 09 February 2008 (UTC)

You say "However, you are more than welcome to use the old babel format". Well, you are the one declaring the "old" template is deprecated and using scripts on thousands of userpages to switch to your new template with colors you only have chosen. If you really want to let users choose, then don't replace the babel box by your new template, replace it by the "babelold" template, so that you don't change the appearance of every single userpage on this wiki. Besides, the "progression of related colours" may look like a good idea to yourself, but how does one know that a light green means a lower level than a dark green? At least, in most cultures it is commonly accepted that red means "not ok" and green means "ok". guillom 21:30, 9 February 2008 (UTC) Reply

PS: I know you're trying to make things better, but I would really like to see more attention to the pursuit of consensus. guillom 21:30, 9 February 2008 (UTC) Reply

This was discussed quite a bit before implementation. I invited comment repeatedly in several multilingual IRC channels, particularly #wikimedia and #wikimedia-translation, before I even posted the product of our discussion here. This proposal was to change the default templates, not to introduce a redundant system (which is a bad idea).

Ideally, there should be nobody at all using {{babelold}}. If someone switches to {{babelold}}, that means they're not satisfied with the new template, and I'm personally contacting them to discuss whether the template can be changed to their liking. So far, a very tiny percentage (much less than one percentage point) have expressed dissatisfaction with the new template.

With regards to the colours, there is a clear relation between the colours for every level ( 1 , 2 , 3 , N ), much more so than the old colour scheme ( 1 , 2 , 3 , 4 , 5 , N ). If you have suggestions for a better colour scheme, these are very welcome. This template is the product of a lot of collaboration and suggestions. —{admin} Pathoschild 22:00:14, 09 February 2008 (UTC)

The 4th and 5th level are almost not used on meta, and their color in the "old" color code is surely not ideal. Though, I see you don't propose any better color for these two levels though, your template actually doesn't even allow them, probably because the most used templates are the blue and green ones, and the one you forgot, the level 0 . I think this color scale ( 0 , 1 , 2 , 3 , N ) is more intuitive: green means "ok, you can talk to me in this language", blue means "so-so" and red means "not ok, I am not able to communicate in this language".

The new color code you propose ( 1 , 2 , 3 , N ) makes sense when all colors are next to each other: once can understand that green means "ok" and the less green there is, the less ok it is. Though, "grey" doesn't really mean "not ok". Besides, there is no difference between level 0 and level 1 , though there is a real difference between these two: one means "I cannot communicate in this language" and the other means "I have basic knowledge in this language".

What about something like: ( 0 , 1 , 2 , 3 , N , Pro )? This is probably not ideal yet, but we could work on it. You may note this fixes the inconsistency with the professional "babel-5" template which is supposed to be a better level than only "native". guillom 10:31, 10 February 2008 (UTC) Reply

People interested in this discussion may wish to take a look at User:Pathoschild/Sandbox4 where a new color set was proposed : ( 0 , 1 , 2 , 3 , N , P ) (knowing that the P level may not be implemented). guillom 13:13, 10 February 2008 (UTC) Reply

Sorry for being a bit late, but I'd like to ask that some distinction between the colors for 0 and 1 be made. If we use the greening scheme, I would suggest that 1 be a very light grayish green or something instead of exactly the same as 0. Alternatively make 0 reddish and keep 1 at gray?? (I use -0 a lot on wikis where I do not speak the native language) Thanks. ++Lar: t/c 00:27, 29 February 2008 (UTC) Reply

It makes a sense to give different colors to 0 and 1. While I don't know the proposal of Guillom is intuitive, it may be an option (at least it is more eye-pleasure). Red / Green scaling may be another option, I suppose. --Aphaia 00:56, 29 February 2008 (UTC) Reply

The reason levels 0 and 1 don't have separate colours is that level 0 isn't recognized as a standard level; the template only allows English to bypass the level validation for 0, and without a category. —{admin} Pathoschild 02:48:02, 29 February 2008 (UTC)

I think there's a lot of value in recognising 0 as a standard level, (I tried 0 with ja and it seemed to work for me in a test edit so maybe I don't quite follow what you meant?) and in any case the color should be different than 1, standard or not. The old boxes worked that way on many wikis. ++Lar: t/c 03:04, 29 February 2008 (UTC) Reply

No, using {{user language|ja|0}} should display something like "This user speaks Japanese at a level." (note the missing adjective), with the page categorized to Incorrect user language level. A more visible error message is possible, but that would require special coding to make an exception for English. I'm not strongly opposed to a zeroth level, but please wait until we finish discussing the fourth level before proposing it. :) —{admin} Pathoschild 04:08:18, 29 February 2008 (UTC)

Well since I don't read japanese, all I saw was that the template didn't throw an error. And it shouldn't. The old system has -0 templates. I would prefer not to discuss one digit at a time, but instead discuss the notion that the new system should be as powerful as the old system was, and not mandate a different, more restrictive way of thinking about things. That's what I allude to below but I'll reiterate it here, because that's what I do :). Many many wikis use -0, have categories set up for it, have old system boxes that use it, etc. and therefore the new system should support that, or it won't be portable. And portability, a single template, a single set of translated strings, etc., is a big selling point for me. It's basically the whole reason I haven't been opposing the change entirely, I was sold on the idea that a simpler, more regular system would be more portable. That doesn't mean it shouldn't be as powerful as the old one, as expressive... we need 0-5 and N because that's what existing wikis use. ++Lar: t/c 04:17, 29 February 2008 (UTC) Reply

The {{user language}} localizations need to be updated to reflect the recent changes. I've contacted all the translators, and most have already been updated. Please update any localizations in your languages listed at User:Pathoschild/User language update. —{admin} Pathoschild 22:29:48, 25 March 2008 (UTC)

When enabled, lets you enter CIDR ranges (/16 and /24 - /32) in Special:Contributions as well as wildcard prefix searches, for example: "Splark*"

Thanks to User:Splarka for the gadget! ~Kylu (u|t) 16:54, 7 March 2008 (UTC) Reply

Very good, thank you very much Splarka. --Anonymous Dissident ^Talk 08:21, 18 March 2008 (UTC) Reply

• Requesting input here: Requests for comments/Meta-wiki suffrage in regards to local elections ~Kylu (u|t) 04:58, 19 March 2008 (UTC) Reply

Please comment on the discussion at Top Ten Wikipedias. Waldir 19:05, 23 March 2008 (UTC) Reply

I just want all metapedians to join the discussion there. Thanks — Vasil ievVV 14:32, 25 March 2008 (UTC) Reply

Is there a way to translate gadget descriptions? Like MediaWiki:Gadget-BiDiEditing/fr being a French version of MediaWiki:Gadget-BiDiEditing (or I suppose it might be MediaWiki:Gadgets-definition/fr translating MediaWiki:Gadgets-definition).

Also, is there a way to change the page so it uses labels on the text? On all other preference panes, clicking the text activates the check box as well. I'd love to see this extended to gadgets as well. EVula // talk // ☯ // 18:45, 25 March 2008 (UTC) Reply

The extension currently does not allow localisation of dynamic messages... Maybe a feature request at mw:Extension talk:Gadgets could help. Siebrand 14:28, 26 March 2008 (UTC) Reply

Just noting, I have flagged the above account as a bot, as it was flooding recent changes. If anyone feels this was a mistake, please reverse it, or let me know. Thanks, Majorly (talk ) 21:55, 28 March 2008 (UTC) Reply

Bah, majorly thanks for the flag. The bot does counterspam statistics, which will be useful for the folks working the blacklist. As I said to majorly I did not think it would be a big deal, as it should be doing only a few edits an hour, that is after it gets the initial statistics reports down. —— Eagle101 ^{Need help?} 22:04, 28 March 2008 (UTC) Reply

Regarding Image:Imagepageexample2.PNG & Image:Imagepageexample3.PNG

Some assistance from users both cool-headed and legally-minded would be welcome. College IP law course attendance a plus. :) ~Kylu (u|t) 20:13, 7 April 2008 (UTC) Reply

Now global title blacklist is live Wikimedia-wide — Vasil ievVV 03:54, 10 April 2008 (UTC) Reply

Great news.. I love that title blacklist extension :-) --Meno25 19:18, 10 April 2008 (UTC) Reply

Looking at the recent Recentchanges ... do we need to multiligualize {{test}} and so on? It seems pointless to put a warning in English in case a user wrote in Japanese or French and they give no sign they are capable to read English. --Aphaia 13:14, 13 April 2008 (UTC) Reply

Definitely - "steal" from Commons maybe? --Herby ^{talk thyme} 13:15, 13 April 2008 (UTC) Reply

Go for it! --Aphaia 19:49, 13 April 2008 (UTC) Reply

How can I filter http://meta.wikimedia.org/w/index.php?title=Special%3ALog&type=rights&user=&page= for getting the rigths of the users in huwiki? I want to get user:<anybody>@huwiki. Bináris 20:28, 14 April 2008 (UTC) Reply

Have a look in preferences, and then gadgets. Under the interface section is an option to filter logs. Majorly (talk ) 20:49, 14 April 2008 (UTC) Reply

Thank you, I found it and switched on, but I still cannot write the query, beacuse I am very much beginner with regex (altough I have tried). Could you please help me to query the rights for anyusers@huwiki? Bináris 07:06, 15 April 2008 (UTC) Reply

This filter seems to work wrong: it checks changed rights instead of target user — 12:53, 15 April 2008 (UTC)

Oh, that's why I couldn't do it! Bináris 15:06, 15 April 2008 (UTC) Reply

You can use this tool to do it. For the rights changes of the users of huwiki, see [1] (note that this also includes users of huwikisource and huwikibooks). Korg 17:18, 15 April 2008 (UTC) Reply

That's great, thank you very much! Bináris 20:31, 18 April 2008 (UTC) Reply

I observed situation on SR/SUL. Since SUL was enabled, there were a lot of usurpation requests (~100) with I high request rate. When SUL is publically available, there most probably will be a big backlog. So, I propose so a new group (SUL admins) who will have access to Special:CentralAuth (or grant it to meta sysops), since it doesn't allow to make something really harmful, unrevertable or not logged and doesn't reveal private info — Vasil ievVV 13:09, 19 April 2008 (UTC) Reply

I think it makes more sense (if additional hands are needed; and I agree the volume is large - whether it's beyond a reasonable workload for the stewards is for them to determine) to make this a 'crat right, rather than an admin one (or creating a new usergroup). Bureaucrats deal with user-account stuff - user rights, user renames... seems like administering SUL fits right in! – Mike.lifeguard | ^@en.wb 13:59, 19 April 2008 (UTC) Reply

Agree with Mike. Majorly (talk ) 16:13, 19 April 2008 (UTC) Reply

Agree with both! Huji 16:27, 19 April 2008 (UTC) Reply

On pl-wiki we responded to the higher volume of SUL usurpations by electing a couple of new bureaucrats (this is actually when I joined the club there, too). Pundit 19:51, 19 April 2008 (UTC) Reply

See bugzilla:13810 — Vasil ievVV 16:28, 21 April 2008 (UTC) Reply

Sounds good to me. Easier than holding an extra set of steward elections before SUL gets rolled out. :) EVula // talk // ☯ // 23:34, 21 April 2008 (UTC) Reply

Will stewards still be able to deal with CentralAuth then? (Otherwise we'd need 30 additional bureaucrats when they enable SUL for all... *ggg*) --Thogo (talk) 11:09, 22 April 2008 (UTC) Reply

Of course — Vasil ievVV 17:15, 22 April 2008 (UTC) Reply

For those who may have missed it, there is discussion happening about global blocking over there. Input is always welcome. – Mike.lifeguard | ^@en.wb 14:02, 19 April 2008 (UTC) Reply

Please see

• MediaWiki talk:Common.css#Wikitable borders in email and outside web pages

I sometimes want to copy wikipedia tables and lists into my web pages, or into my email. The standard table created by the table button in the Wikipedia editing form does not add the necessary bit of code to allow tables to show up easily outside wikipedia. So the tables lose their borders when pasted into my web pages, or into my email. A jumbled mess. A simple solution awaits! border="1" - See the above talk page link. --Timeshifter 20:55, 19 April 2008 (UTC) Reply

Per a previous motion to close on 1 May 2008, MF-Warburg closed this interminable, two-year discussion today. He closed it as "keep". 64 editors supported closing the project, 56 opposed closure. While MF-Warburg did not elaborate on his decision, presumably he made it on the lack of sufficient consensus to eliminate a project.

In November 2007, a non-admin, Prince Kassad "closed" the discussion as "close", stating this was not a useful project. This was quickly overturned as an invalid action by a non-admin.

Today, Prince Kassad struck MF-Warburg's decision, calling it invalid since MF-Warburg gave no reason for his decision.

I believe MF-Warburg's decision was entirely proper and within his rights as an admin. I believe Prince Kassad's actions, while surely made in good faith, were invalid and inappropriate. I have temporarily protected the page for one week so that only admins can edit it and I have referred any further discussion to the talk page. Note that there was already a previous, robust discussion of this project on the talkpage.

Disclaimer: for the record, I am a supporter of keeping this project open. --A. B. ^(talk) 14:52, 2 May 2008 (UTC) Reply

MF-Warburg is not an admin, at least on Meta. I'm not sure who has authority to close them, but I assumed it was Meta admins. Majorly (talk ) 14:55, 2 May 2008 (UTC) Reply

Oh, heck. Thanks for catching that, Majorly. I thought he was. Well then, this is just like Prince Kassad's invalid November closure all over again.

I feel OK stopping the discussion and protecting the page, however as a partisan of keeping that project alive, I think another, more neutral admin should make the final decision and close the discussion.

This matter needs to be settled now -- the closure discussion has dragged on for two years. --A. B. ^(talk) 15:37, 2 May 2008 (UTC) Reply

I closed this discussion because of the "motion to close" that was there. Nobody objected and 64/56 is not enough support so the result should be of course keep. I made this decision although I am not an admin here (why should only admins be allowed to close discussions?). I have yet closed other project closing proposals and nobody ever protested (except Yaroslav Zolotaryov...). --MF-W 16:57, 2 May 2008 (UTC) Reply

Probably nobody complained because the others were uncontroversial (except for Yaroslav Zolotaryov's and that's an entirely different, very long story!). Besides, you know more about our small projects than>95% of Meta admins. I always thought you were an admin; I hope you will consider becoming one here.

Perhaps an admin's not needed. We don't have a formal procedure and have not needed one before. In any event, VasilievVV has closed it as "keep" the same as you did. --A. B. ^(talk) 18:46, 2 May 2008 (UTC) Reply

Since, as per the inclusion policy, unfree content is not allowed on Meta, I propose that we disable local uploads and instead use Commons for all images. Commons is much better set up to handle images and is in a better position to manage any issues. I'd welcome any comments on this issue and any suggestions as to why this might not be worth doing. Regards. Adambro 13:23, 3 May 2008 (UTC) Reply

I suggest not to disable it at all, but limit to sysops for some rare cases, like it's done on Incubator — Vasil ievVV 14:05, 3 May 2008 (UTC) Reply

I agree. The majority of uploads here are deleted immediately, but some images are uploaded. The policy is also wrong in practise, as Meta has several unfree images hosted. However, such images can be uploaded by admins only. It'll make less work in having to delete them. Majorly (talk ) 14:12, 3 May 2008 (UTC) Reply

Limiting to sysops seems sensible. Leaves the option open in those limited circumstances where it might be appropriate. Adambro 14:24, 3 May 2008 (UTC) Reply

Meta is much used for marketing materials (see Presentations, etc.). Where are we supposed to upload these files, given that some people on Commons claim Commons shouldn't host text documents? Note that this is an open question: I am not really against disabling local upload on meta, I'd just like to be sure that all materials uploaded and to upload to meta will be accepted on Commons. I think this should be discussed with people from Commons as well, because Commons' scope is unclear about this. guillom 06:53, 4 May 2008 (UTC) Reply

When we talk about "uploads" everyone starts with thinking about images. However, an important part of uploads are non-image files such as PDF documents, Powerpoint presentations, etc. Some of such things are only related to Meta and as long as there is no licensing problem, it is fine if they are uploaded on Meta, not Commons. So in short, I'm not sure if we should disable uploads. Huji 17:48, 4 May 2008 (UTC) Reply

On another note, I open another discussion: Meta:EDP. Please provide feedback on this in the talk page. Thanks Anthere 23:35, 3 May 2008 (UTC) Reply

I have flagged Erwin85Bot as a bot as it was flooding recent changes. I'm hoping this was a good move. Majorly ^talk 15:09, 22 May 2008 (UTC) Reply

Yes it was :) – Mike.lifeguard | ^@en.wb 22:39, 27 May 2008 (UTC) Reply

Hello,

Could a kind bot owner set up a bot to reset the sandbox? The bot that did this before, Uncle G's 'bot, is no longer running. Thanks in advance, Korg 11:02, 29 May 2008 (UTC) Reply

There's a stack of these bots on sister projects (especially EnWP) if someone wanted to import the code. giggy _(:O) 11:34, 29 May 2008 (UTC) Reply

When should it reset the sandbox? At some given time or at a given time after the last edit? I've got a bot running on nlwiki that resets it twice a day. I could run it here as well or use a bot to reset it after a given time. I'll be gone until monday though. If anyone else wants to run this bot, be my guest. --Erwin(85) 13:43, 29 May 2008 (UTC) Reply

The old one ran once a day at 0:00 UTC iirc. Twice a day would probably be good. Majorly ^talk 13:50, 29 May 2008 (UTC) Reply

Looking into this. Would probably run once every six hours. Daniel (talk) 14:00, 29 May 2008 (UTC) Reply

Once or twice a day would be good, but every six hours would be good as well :) (As a comparison, the Commons sandbox is cleared every six hours, although it is less actively edited than Meta's). Thanks, Korg 01:01, 30 May 2008 (UTC) Reply

User:SoxBot has been brought over from EnWP to run. Soxred93 06:09, 2 June 2008 (UTC) Reply

Thank you very much! Korg 11:04, 2 June 2008 (UTC) Reply

I have noticed the Assessments template on Commons doesn't work properly. I'm referring to the "considered" button, which should direct you to the nomination page of he image. I have see that the Turkish Wikipedia is the only one for which this feature worked. What they have different is that the instead of having {{FULLPAGENAME}}, like all other Wikipedias, they have {{PAGENAME}}. This is in order to exclude the "Image:" prefix from the name, because all Wikis have another prefix for Images, and the way this template on Commons works doesn't allow for all of them to be defined.

Besides this, in order to work (cause this isn't enough), the names of all the nominations, at least from now on, should be changed to that they would include the actual name of the picture, for without the "Image:" prefix. For a better understanding see Image:Lightning over Oradea Romania 2.jpg, where the above mentioned feature works for the Turkish, but not for the English Wikipedia. Also see the source of trwiki, and of enwiki, where you can see the {{PAGENAME}} and {{FULLPAGENAME}} codes.

So, do you think this new change should be applied to all Wikipedias, in order for the template to work properly? diego_pmc 07:07, 6 June 2008 (UTC) Reply

Since many stewards feels that bureaucrats should not have access to it, I suggest to vote on it. Please, vote if you think Meta bureaucrats should have an access to it.

• Support Support — VasilievV ² 13:39, 7 June 2008 (UTC) Reply
• Support Support Also see my latest addition to the RFA talk page. Majorly ^talk 13:46, 7 June 2008 (UTC) Reply
• Oppose Oppose just because those that made this mistakes, were warned too many times, but they did, its more of an immaturity issue than abuse...--Comet styles 13:55, 7 June 2008 (UTC) Reply

  Both bureaucrats and stewards made such mistakes — VasilievV ² 14:09, 7 June 2008 (UTC) Reply

• Oppose Oppose —DerHexer (Talk) 13:56, 7 June 2008 (UTC) Reply
• Oppose Oppose --Complex 13:57, 7 June 2008 (UTC) Reply
• Support Support Is this just based on principle or have their been legitimate cases of abuse/mistakes? Cbrown1023 talk 13:58, 7 June 2008 (UTC) Reply

See Cometstyles' vote there have been many mistakes, and by the same people too. Majorly ^talk 14:02, 7 June 2008 (UTC) Reply

• Oppose Oppose, --birdy geimfyglið _{(:> )=|} ∇ 14:03, 7 June 2008 (UTC) Reply
• Oppose Oppose as much per Comets as anything else. Frankly I am very glad I am not a 'crat here at present (& doubtless others will agree) --Herby ^{talk thyme} 14:04, 7 June 2008 (UTC) Reply
• Comment Comment. If CentralAuth were bug free and nothing irreversible could be done, I would see no problem with it being in the hands of meta crats. However, the fact that people can lose accounts if this is not done properly is troubling. Perhaps we should run a while with only stewards doing this and monitor the workload. If the stewards feel they are being overwhelmed with work, access can always be given to others (either to another usergroup or presumably individually). Ideally, if Bug #13507 could be fixed, there would be far fewer requests to process anyway. WjBscribe 14:11, 7 June 2008 (UTC) Reply

  I removed this functions from Special:CentralAuth today — VasilievV ² 14:20, 7 June 2008 (UTC) Reply

  I'd like to second WjB's comment. The ability to give the functionality to others of administrating global accounts and such may not be a bad idea. ----Anonymous Dissident ^Talk 15:20, 7 June 2008 (UTC) Reply

  Did we have a clear consensus already? ++Lar: t/c 15:17, 7 June 2008 (UTC) Reply

  VasilievVV means removing the ability to delete accounts from CentralAuth [2]. One of the problems here is that what exactly CentralAuth can do tends to fluctuate - either due to bugs or features being added/removed by developers. It is difficult to discuss sensibly whether a group should have access to a right without being utterly sure what that right will be able to do in the future. This seems another reason to limit access in the short term until we are sure exactly what CentralAuth is going to be able to do. WjBscribe 15:49, 7 June 2008 (UTC) Reply

• I'm not sure which way support/oppose means so I'll try to state my views unambiguously. I now (on reflection) Oppose Oppose meta 'crats being able to carry this function out and Support Support removal of the ability to carry out this function from meta 'crats. Note that if the backlogs build up, please feel free to beat up stewards (including myself) to get the work done... ++Lar: t/c 15:17, 7 June 2008 (UTC) Reply
• Oppose Oppose mainly per Cometstyles, but also because there was no real consensus on granting this ability to Meta crats. --Brownout ^(msg) 15:24, 7 June 2008 (UTC) Reply

  We didn't, but now we're discussing this — VasilievV ² 16:26, 7 June 2008 (UTC) Reply

• I think the only problem now is that we (and by "we" I mean "you, collectively") are not able to play by the rules. Since that's not a problem with administering CentralAuth, let's keep this ability, but go with Majorly's proposal (gasp!) Crats who haven't done a "real RFB" may do renames and SUL, but not admin/bot promotions. The best of both worlds. – Mike.lifeguard | ^@en.wb 16:19, 7 June 2008 (UTC) Reply

  Erm, they shouldn't be allowed to the matematical stuff like sysop/bot promotions but the global serious account deletions, locks etc.? Sounds a bit strange. :-/ —DerHexer (Talk) 16:26, 7 June 2008 (UTC) Reply

  Were there problems with crats handling that previously? Will there be in the future now that bugzilla:13507 is fixed? Depending on the answers, my view would change. But my current understanding leads my to the position above. I think this whole radical idea may have fallen apart. At this point, I'm of the view that it should be scrapped entirely, and all crats promoted since it was begun should be removed pending a proper RFB. This has actually been a tad embarrassing to watch. Seriously, how hard is it to not close RFAs early (etc)? – Mike.lifeguard | ^@en.wb 18:34, 7 June 2008 (UTC) Reply

• Oppose Oppose - 'crats have been doing a sloppy job lately with closing Rfas early, etc. While that stuff can be removed/reverted much more easily, this can't be. Monobi (talk ) 17:05, 7 June 2008 (UTC) Reply
• Oppose Oppose - we have a position for dealing with global matters: stewards. Meta bureaucrats were not chosen for this purpose (and in fact many of them were not chosen at all). — Dan | talk 17:24, 7 June 2008 (UTC) Reply
• Oppose. Any Meta administrator is eligible to become a bureaucrat, and these administrators were not elected with important global responsibilities in mind. They are elected locally, and do not represent the choice of the wider community. Furthermore, they do not have access to technical discussion and bug warnings on stewards-l. Stewards are capable of administering global account conflict resolutions themselves, and can create a global group with the rights if need be without giving access to every administrator on a project. —{admin} Pathoschild 17:27:01, 07 June 2008 (UTC)
• Oppose - Pathoschild put it nicely above. Meta admins turned 'crats shouldn't really be dealing with global affairs external to the wiki in which they were given the trust. We have Stewards, who went through an election in which the wider community participated, for global purposes. --Anonymous Dissident ^Talk 17:35, 7 June 2008 (UTC) Reply

  I think the spam blacklist, interwiki map and the portals are precisely why admins here do have abilities affecting more than meta, no? Of course, not at the same level as the stewards, but adminship at meta is different in this respect. – Mike.lifeguard | ^@en.wb 18:34, 7 June 2008 (UTC) Reply

  This is true, but this particular function should be particular to Stewards, I think, because it revolves around user housekeeping and user-based requests. It just seems like a duty that is related to Stewardship, not bureaucratship, even if it is on Meta. --Anonymous Dissident ^Talk 18:48, 7 June 2008 (UTC) Reply

• Oppose per Pathoschild. --Erwin(85) 18:13, 7 June 2008 (UTC) Reply

Though meta has it is own community but i think most people here are representing other wikis ideas so i really think crat's here could deal with such subject and up to now i didn't see any abuse may some wrong action both have done by crats and steward due to the bug but now it seems bug has been fixed and would have this problem.so i Support Support meta's crat can deal with such subject.--Mardetanha ^talk 19:07, 7 June 2008 (UTC) Reply

• I see no real advantage to have meta crats here too as SUL administrators, I think it makes communication, especially in the startup phase with bugs etc, harder then when there is only one group with their own mailing list anyways and I agree with the election argument. I think that means an oppose. Effeiets anders 19:23, 7 June 2008 (UTC) Reply
  • People are using this as an excuse to obtain crats on Meta which maybe another reason I have opposed this, and I'm not sure what the stewards have discussed regarding this and why it was brought up in the first place and I do know it has been abused by meta crats as well, so I'm sure it should stay with the Stewards for know, since they are forced to clean up the mess made by the crats, so for the betterment of the community (not meta, wikimedia)..that feature should only remain with the stewards...--Comet styles 22:41, 7 June 2008 (UTC) Reply
• I concur with Dan and thus oppose. giggy _(:O) 01:03, 8 June 2008 (UTC) Reply

Regardless of the technical issues, if we shrink the pool of those capable of deleting global accounts without fixing the bugs that are making the requests necessary, we will see a rapid bottlenecking of the SUL process. The way the process currently works, anyone who encounters an SUL conflict that requires a usurpation using a pre-existing, differently named account is unable to complete this usurpation without a global account deletion (or lose all the edits made on the differently named account - I myself even have the problem with la:Usor:Andrus, though I don't care to preserve that contribution history). So, we have a lot of users who don't complete SUL unification, and due to language barriers or just general confusion, never make the proper request in the proper place. The problem with Pathoschild's reasoning is that, in essence, an SUL rename or usurpation is a local issue, which cannot be solved by local bureaucrats. Andre (talk) 01:44, 8 June 2008 (UTC) Reply

I think we have enough stewards to handle this for now. If at some point it's not getting handled, beat up the stewards. Another alternative approach is to create a new group to handle this, some group with a bit more vetting than "meta admin from whenever, and then asked nicely to be a 'crat and some other 'crat that just recently got to be a crat by asking nicely turned it on for them". ++Lar: t/c 04:06, 8 June 2008 (UTC) Reply

• Ok, consensus is quite clear here that this function should be turned off by the developers fro meat bureaucrats. I think it would be fine if someone could give them the go ahead with the request on bugzilla, which was effectively suspended pending the outcome of this discourse. --Anonymous Dissident ^Talk 04:16, 8 June 2008 (UTC) Reply
• Oppose Oppose per (Happy Birthday) Pathoschild. --FiliP ×ばつ 06:22, 8 June 2008 (UTC) Reply
• Oppose per Pathoschild. --.anaconda 09:58, 8 June 2008 (UTC) Reply
• Oppose Oppose There were enough good reasons named already. --Thogo (talk) 12:16, 8 June 2008 (UTC) Reply
• Oppose Oppose, per good reasoning above, though I note that this makes my reasoning for getting Bureaucrat here a little, well, moot. :-( James F. (talk) 19:54, 8 June 2008 (UTC) Reply
• Oppose Oppose Meta bureaucrats were elected with only adjusting local user rights in mind. It's a jump if local bureaucrats get to control a Wikimedia-wide process. --O (谈 • висчвын) 22:31, 08 June 2008 (GMT)

  Er, they already have it. This is a poll about whether it should be removed. :-) Cbrown1023 talk 01:44, 9 June 2008 (UTC) Reply

  I think he means that they shouldn't have it, and thus supports removal. giggy _(:O) 02:41, 9 June 2008 (UTC) Reply

  Ack giggy. --O (谈 • висчвын) 20:31, 09 June 2008 (GMT)

• Oppose Oppose Bureaucrat is a local position and should not perform global tasks. If we need more stewards, lets get some more stewards instead of giving meta 'crats semi-steward status. --MiCkE ^d _b 20:43, 9 June 2008 (UTC) Reply

• Communication
• Multilingualism
• Meta-Wiki organisation