Wikipedia:Village pump (proposals)

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals.
Proposed software changes that have gained consensus should be filed at Bugzilla.
Proposed policy changes belong at Wikipedia:Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Proposal for Wikipedia in American English

If you go to List of Wikipedias, you may notice that although it appears that are many different languages in which Wikipedias exist on the net, some are actually different versions of the same language (there are separate entries there for Bavarian, German and Alemannic - the latter I take to mean Swiss German as opposed to High German). In the same way, do you think we could have two Wikipedias in English - one in U.K. English, one in American English? This would certainly clear up problems such as how to spell "ageing" (ageing in U.K. English, aging in U.S. English - go the article Ageing and visit its talk page and you will see my point. ACEOREVIVED (talk) 23:29, 21 September 2010 (UTC)[reply]

No. ♫ Melodia Chaconne ♫ (talk) 00:06, 22 September 2010 (UTC)[reply]

There is no question that the issue is a perennial irritation and will be for the foreseeable future. I personally despise the spelling aluminium and deplore the Chemistry WikiProject's choice to favor it just because IUPAC does.

But this is a minor point. On the other hand, the loss of expertise on both sides of a split en.wiki project would be anything but minor. We muddle along with WP:ENGVAR; it isn't perfect but it mostly works. --Trovatore (talk) 00:14, 22 September 2010 (UTC)[reply]

It works perfectly fine. The very minor differences between American and British (and Australian, and South African, and Canadian, and etc. etc.) versions of the English language are not really enough to justify the split into seperate Wikipedias. There are a few minor usage differences, and some small differences in vocabulary that do no more than cause a second or two of awkwardness. Articles written in ostensibly "British" English are perfectly understandable to an American reader (or Australian, or Canadian, or Kenyan, or Bermudan, or Jamaican, or...), so there's no impending need to create a new Wikipedia just so one can use the words "petrol" and "lift" while the other uses "gasoline" and "elevator". --Jayron32 00:27, 22 September 2010 (UTC)[reply]

Then you get editors like me that use a hopeless muddle of British and American spellings. To date, the only time I have been absolutely perplexed was when a Haynes manual told me to rub down my engine block with paraffin to get it clean. I had no idea that they meant kerosene, not candle wax.—Kww(talk) 00:45, 22 September 2010 (UTC)[reply]

Regional differences between variants of German are much greater than in English, especially in written form. I'm a native German speaker, and Bavarian description in Bavarian and Alemannish description in Alemannish are sort of decipherable, but barely a word is spelt exactly as in standard German. Rd232 ^talk 06:34, 22 September 2010 (UTC)[reply]

The regional differences in English are not enough to justify separate versions, nor are we likely to see standardization on one particular national variant. Much as Americans may think they dominate the world, they are only a small fraction of the English speaking world. Besides, as soon as we get American English and British English Wikipedias, we'll have to have Indian English, Singaporean English, Ebonics, Australian English, South African English, and so on, it's not practical for what amount to trivial differences. Triona (talk) 07:05, 22 September 2010 (UTC)[reply]

Out there in the real world, people used to read dozens of English-language books, magazines and newspapers that were published on the other side of the Atlantic (or of the world), and got used to most of the variations, with only a minor irritation or grumble here and there. Now they go to different websites. There is a North American BBC site, but I don't think it changes its spelling to U.S., while I don't think CNN Europe changes to British spelling. While an Anglicism or Americanism will periodically remind one where (or by whom) something was written, most of the time you have to be paying specific attention to small details even to notice the national style. [I had to be bilingual in my youth because I crossed from London to New England when I was 6, back again at 8, and then finally back in New England at age 11 (leaving for California at 17). But the differences were usually easily surmounted. If you live in another English-speaking country, you will find how very small the differences really are; they're enough to distinguish, without significantly impairing communication except at the slang or local dialect level which would confuse one at home. The successive introduction of the telephone, gramophone/phonograph, wireless/radio, talking pictures, television, mass air travel and the Internet, plus several wars in which the Anglophones served together, greatly reduced differences in the spoken language, too.] And where there are genuine ambiguities and obscurities, Wikipedia should clarify them (e.g. paraffin/kerosene, faucet/tap)—rather than leave the confusion as some kind of token of authenticity—which I think is a pillar of Wikipedia:National varieties of English, or should be. There are, as yet, no separate Wikipedias for the versions of French, Spanish or Portuguese spoken in the Americas as opposed to their European versions, although there are some very small little-used Wikipedias for Flemish, Walloon, Luxembourgish and Afrikaans. See meta:List of Wikipedias. —— Shakescene (talk) 08:00, 22 September 2010 (UTC)[reply]

Many thanks for all the comments - I see that the proposal soon stimulated an interesting response. I do appreciate that there are probably greater variations in different versions of German than of English, although I do remember reading in a Reader's Digest back in the 1980s that a publisher had already published the Dictionary of U.S. English. ACEOREVIVED (talk) 19:00, 22 September 2010 (UTC)[reply]

There's no question that English has dialects. There's always going to be tension between Yanks and Brits on WP over which one is the better one. But we can be better than that; we can overcome these tribal temptations and work on a basis of mutual respect. WP:ENGVAR is an imperfect but mostly workable framework for doing so.
Certainly others have made other choices. There are two Norwegian Wikipedias — two, for a language without a huge speaker base, but mutually comprehensible with Swedish! I haven't looked at them much, but their depth of coverage must surely suffer enormously. The better choice would be to merge with Swedish WP and come up with a SCANDVAR guideline to work over the rough spots. --Trovatore (talk) 19:15, 22 September 2010 (UTC)[reply]
No need to rely upon your memory. There's an encyclopaedia around here, wherein you can read all about Noah Webster. ☺ Uncle G (talk) 19:34, 22 September 2010 (UTC)[reply]

One minor point on the English-is-more-mutually-intelligible-than-German debate, that coincidentally I was just talking about at User talk:TFOWR: I have, on quite a number of occasions, seen articles listed for deletion as "patent nonsense" simply because they were written in Indian English. If there's ever a split, which I doubt, that would be where it is most likely to occur, I conclude from experience. Indian English writers seem to have the hardest time at the English Wikipedia, and are the largest group most often overlooked in the perennial British/U.S./Commonwealth/American discussions. Uncle G (talk) 19:34, 22 September 2010 (UTC)[reply]

No, please for the sake of my sanity! As a Brit who moved to the US 15 years ago at the age of 35, I have enough problems figuring out which version of English I do/should speak/write and for which audience... – ukexpat (talk) 19:56, 22 September 2010 (UTC)[reply]

The obvious solution is to use Canadian English, given it is a mixture of the two! ;o) Reso lute 20:05, 22 September 2010 (UTC)[reply]

You've got your toque on too tight. Go have a butter tart, you'll feel better, eh? :-) --Trovatore (talk) 20:10, 22 September 2010 (UTC)[reply]

Ahh take off, ya hoser! Reso lute 20:21, 22 September 2010 (UTC)[reply]

Isn't the obvious solution for those who find the confusion here too much to use Simple English Wikipedia instead :) Dmcq (talk) 21:07, 22 September 2010 (UTC)[reply]

I suspect it is a bigger problem than we think, though I think the solution is a different sort of multi dialect wiki not different wikis per dialect. We aren't as successful at recruiting editors as we once were; Not so much here in the land of warm beer, but definitely in the land with with extra Zs and fewer Us on the keyboards. Our classic routes to recruiting editors were; Newbie spots vandalism and fixes it, submits a new article or fixes a typo. Nowadays the vandalfighting bots and hugglers are getting rid of the vast majority of vandalism before a newbie has a chance; New pages is a newbie biting trainwreck; And we have relatively few genuine typos but loads of things that look like typos to your PCs spellchecker. I fear that we lose too many genuine good faith newbies who find their laborious adding of "ation" to every sixth word on the article on a British King has been reverted with a snarky and unintelligible comment. My preferred solution to this is to put icons on the screen so that people can click on the US, Australian, Canadian, or British flag and have Wikipedia displayed in the dialect of their choice see -Strategy:Proposal:More_multi_dialect_wikis. Or we cld mk txt spk wki Lol Ϣere SpielChequers 21:24, 22 September 2010 (UTC)[reply]

We await your solid and 100% accurate contribution to the codebase to automatically and seamlessly translate between the multiple dialects of English. (will it tell me I have an apartment tire? or that a character in a movie elevatored his friend off the floor?) --Golbez (talk) 21:41, 22 September 2010 (UTC)[reply]

I suspect that at some point we might need to do some AWB work to establish which bonnets were hoods and which were hats. But I understand we can have 50,000 rules before we need to upgrade the software, and that would get us a lot more than 90% towards the goal. Ϣere SpielChequers 22:21, 22 September 2010 (UTC)[reply]

So out of curiosity, what would the rule for flat vs apartment look like? I think you're making this sound much easier than it actually is. Chinese can switch back and forth because, in my understand, that is primarily an issue of the characters used, rather than the words. --Golbez (talk) 22:33, 22 September 2010 (UTC)[reply]

Flat vs apartment is one of the easier ones, as apartment would display as flat in the English version you could just use AWB or similar to change flat to apartment where the English meaning of flat was used. The vast majority of the differences are as simple as:

English - American English translation
English	translation rule	American English
Colour	=	Color
Favour	=	Favor
centre	=	center
Flat	<	Apartment
Pavement	=< (except Limestone pavement doesn't change)	Sidewalk
Under the bonnet	=	Under the hood

True that would only do 90% of it easily, and there would be some work involved in getting the other 10% right. But 90% is better than nothing, and judging from the number of people who come here wanting to change things between different versions of English I don't anticipate that there would be a shortage of new editors to do the rest - if anything this could recruit a whole new generation of wikipedians. It does get complicated for words like Fag, and I imagine we'd need some sort of system to store such words as Fag (cigarette) and then display them as fag or smoke. The biggest advantage of that would actually be for the large and growing number of people who use EN Wiki via machine translators, as these are amongst the words that are most likely to throw translators. Ϣere SpielChequers 12:09, 23 September 2010 (UTC)[reply]

So we would have to either use another term for "flat tire" (deflated tire?), or we would have to use a template to say {{not-us-english|flat}}, or what? Also, will it know not to change quoted titles? I don't think we should have an article discussing The Colour Purple. Etc etc... what you're suggesting here is machine translation, nothing more, and there's a reason machine translation isn't used on a large, automatic scale. --Golbez (talk) 12:27, 23 September 2010 (UTC)[reply]

You weren't perchance referring to The Color Mauve, now, were you? ;-) — Ah, the benefits of a trans-Atlantic childhood ! (everything that you learnt so well in one school or from one group of friends was of course absurdly wrong in the next.) —— Shakescene (talk) 18:05, 23 September 2010 (UTC)[reply]

No, that's why I showed that as a one way rule - Apartment can be displayed as flat to English readers but you can't go the other way for American English readers without marking which meaning of flat you are using, and for words like flat where one meaning predominates you'd probably leave that as the default. Words in quotes would also need to be left, and you'd probably need a {{no translate}} template. I agree that if this was nothing more than a machine translation you'd only get 90% of the job done, and the remaining 10% would require semi-automated editing. But the 90% is probably worth doing in its own right, its the remaining 10% would greatly improve machine translation from EN wiki. Ϣere SpielChequers 13:12, 23 September 2010 (UTC)[reply]

Nothing is that simple. "Four apartment buildings were demolished" is rather confusing if it is rendered as "four flat buildings were demolished". dramatic (talk) 07:46, 26 September 2010 (UTC)[reply]

First of all, I apologize for misunderstanding the meaning of your symbols with regard to flat vs apartment. But I disagree with your assertion that it's "worth doing in its own right". What of the sheer effort involved to not only template but maintain the templates for the many millions of words that shouldn't be converted, or could be converted incorrectly? For example, marking every single instance of the word Center in Verizon Center, plus the number of times it's referred to across the Wiki, times the number of other Centers that would be incorrectly converted? No thank you, I'll take an re over an er any day. This is not exactly a solution in search of a problem, but it's certainly one that far outweighs the problem. It's a shotgun brought to kill a flea. --Golbez (talk) 14:31, 23 September 2010 (UTC)[reply]

I think we have very different perceptions as to the size of the task, the potential benefits and who would take on the burden of doing the work. Many millions of words that shouldn't be converted or could be converted incorrectly would mean an average of more than one such anomaly per article. I very much doubt if it would be that high, but I agree that above a certain size a task can become daunting. However I'm not convinced that we have yet quantified the size of the task. As for the benefits, I believe you underestimate both the number of Americans who are thrown by English spellings and especially the amount of machine translation, or machine assisted translation that is already going on. I suspect it would be possible to quantify the number of newbies who leave after an Engvar warning, and someone else will doubtless have other theories as to why our editor base under-represents the USA, Google translate might even be willing to calculate some stats for us as to its use on Wikipedia. As for the sheer effort, this is a volunteer project, so no-one need put effort into this who doesn't think it worthwhile - we could even have a don't care option for those who want to see articles in the dialect they were written in. In my view this is more a few spots of carefully applied lubrication to a machine that has some stiff joints rather than a shotgun to shoot a flea, but if someone can quantify things I'm happy to review my assumptions Ϣere SpielChequers 15:09, 23 September 2010 (UTC)[reply]

If you really want to make things friendly for American editors, you can please stop distinguishing "American English" from "English". You can say "British English", "UK English", or "Commonwealth English". Unmodified "English" fully includes American English. --Trovatore (talk) 15:15, 23 September 2010 (UTC)[reply]

Thank you for an interesting discussion - perhaps we should leave things as they are, I can certainly understand American English.ACEOREVIVED (talk) 21:29, 22 September 2010 (UTC)[reply]

arbitrary break number 1

Yes, no one seems to have pointed out yet that if I were really keen to start a Wikipedia in American English, I could go the WikiMedia Incubator (go to List of Wikipedias and see the talk page there). However, I did want to start this discussion here first. I think that the main points from the above discussion can be summarized as follows:

1. Although there are certainly differences between U.K. English and U.S. English, these are probably not as great as the differences between different forms of German. 2. There are already Wikipedias in different forms of English - such as this one versus the Simple English Wikipedia or the Anglo-Saxon Wikipedia (then again, there is the Lowlands Scots Wikipedia - since Lowland Scots and English are intelligible, I shall leae it for others to decide whether this is effectively an English Wikipedia, although I can see the arguments that it is not). 3. The similarities between U.S. English and U.K. English are close enough for us to use the one Wikipedia (after all, it would mean goodness knows how much hard work to shift articles from one to another).

I would also like to add these comments. There are certainly differences between U.K. English and U.S. English, but some U.S. English words are so commonly known in Britain today that some people use them. We could all understand the terms "candies" and "cookies" for sweets and biscuits, and the word "mail" is almost used here as a synonym for post. There are, it is true, some words that have not caught one on this side of the pond (we always say "pavement" and never "sidewalk"). There are some languages that have Wikipedias in different forms of the same language - as one of the above Wikipedians noted, the New Norwegian and Dano-Norwegian Wikipedias - but these are probably justiied. After all, Danish and Norwegian are mutually intelligible, but given that these are quite definitely different languages, they would still need separate Wikipedias.

Thank you again for all the above comments,they are all apppreciated. So, many thanks indeed, ACEOREVIVED (talk) 23:17, 22 September 2010 (UTC)[reply]

But I say "footpath" and never "sidewalk", and if I say "pavement" it's a technical term for the surface of the road. Oh no, we need a separate Wikipedia in New Zealand English! Fortunately, I understand all of the above. dramatic (talk) 07:53, 26 September 2010 (UTC)[reply]

Why should the Americans be the ones to leave anyway? Start one in British English :-). No, don't, really; the status quo has its irritations but is better than any other idea I've heard, a conclusion you seem to have come to as well.

I would point out also that the Wikipedias for small languages such as Plaatduutsch (or however you spell it) or Lowland Scots are a bit different in purpose. They are not really there as the primary reference for speakers of those languages, who surely must be competent in some better known language as well (unless they're subsistence farmers or something, in which case they are not likely major users of online encyclopedias). Rather, those WPs are intended to help advertise and preserve the language in question. Neither American English nor British English needs that sort of help. --Trovatore (talk) 23:25, 22 September 2010 (UTC)[reply]

Excellent point. Rd232 ^talk 13:02, 23 September 2010 (UTC)[reply]

Funny you should mention Scots. Over at sco.wiki, they've adopted a policy quite different to WP:ENGVAR: the various Scots dialects are deprecated, and a generalied version of Scots is used instead: sco:Wikipedia:Spellin an grammar#Raesons for this policie - "ti dae awa wi arguments ower the richt spellins o words. That wastes time better spent writin new text for airticles." I've tended to be a big fan of ENGVAR here, but the sco.wiki approach has some merit - we're here to write articles, not argue over spelling. The problem here is possibly wider than we might think, as well - it's not just American English vs. "British" English - there are several varieties of English within Britain, with Scottish English being used for Scottish subjects, but not outwith that area. Non-American English includes more than just British English: New Zealand articles are written in an English understood by most Pākehā, with terms that are maybe less familiar to other English speakers. Now, I quite like this, because I quite like the quirkiness of our language. But it's less than clear. New Zealand articles aren't written exclusively for Kiwis. Non-Scots want to learn about Scottish topics. Expecting readers to learn several varieties just to read about different topics seems less than ideal. It's not a huge burden, but it's still a burden. I'm not an American English speaker, though I have a great deal of respect for Noah Webster, but I'd be inclined to accept American English as a standard on en.wiki. However... would it be possible to have some sort of technological magic, where a reader could select their preference (on a page or cookie level, if necessary, so that we don't disenfranchise IPs) and the wikicode {{magic|sidewalk|en-us}} renders as pavement for British English readers? TFOWR 13:23, 23 September 2010 (UTC)[reply]

If we want to make wikitext even harder to get grips with for newbies (and harder to edit for all), then templating every variant word is a great way to go. If one day Mediawiki can separate refs from body text properly, then that approach might possibly one day work for variant words and phrases... but I think the maintenance implications for software developers and Wikipedia editors are being underestimated. Rd232 ^talk 13:48, 23 September 2010 (UTC)[reply]

I missed the part where I insisted that newbies had to get formatting absolutely perfect! ;-) List defined refs already exists, but that's a different matter entirely. Back on topic, we already use templates for refs and locations, etc, and we currently don't expect perfection from new editors. Article development is iterative: with this template a newbie would write "sidewalk", and a more experienced editor would - instead of changing it to "pavement" ("per ENGVAR") - add the template. I'm not convinced there's much dev work here - some Ajaxy magic to hide/show a div when the setting changes. The real work is for editors (experienced editors, not newbies) who need to maintain a table in a template. But realistically - once the template is set up, how often will it need to be changed? TFOWR 13:57, 23 September 2010 (UTC)[reply]

It's not the expectation of perfection on the part of experienced editors, it's how scary it looks and how complicated to read and understand and edit, and the implication carried from looking at it that it's all very technical and you need to be some kind of expert. The more editing wikitext resembles programming, the more we drive people away. Rd232 ^talk 19:11, 23 September 2010 (UTC)[reply]

I have no doubt that the way they are doing things at the Chinese Wikipedia would work for us:

Global translation rules
Supplementary per-article translation rules, so if you use an unusual word that needs translating you just add it to the local translation table
Markup to use in the rare cases that the other methods don't work and the translation of a phrase must be hand-coded.

This system would close a few tins of worms and open a few new ones. And I think there is no good solution for the problem of article titles that are in one of the variants. On one hand I think it's cool and would like to see it. On the other hand it seems a lot of effort for very little gain.

There is also the political dimension: In the age of globalisation there is a huge new unifying force for the English language. So far Wikipedia is a significant part of it, because it helps to make editors and readers a lot more familiar with standards of English other than their own. Personally I think that's a good thing and should not be abandoned. But of course it is only tangentially related to Wikipedia's norms and values. Hans Adler 14:22, 23 September 2010 (UTC)[reply]

I think the current rough solution is the best. The risk is that standardising on American English wrecks the ability for people like myself (UK) to contribute - simply because there is no way I will be able to contribute in American English :D (not so much the spelling differences which I could work around but for the colloquialism). Even worse, articles on UK (and other non-US English speaking countries) topics will risk being incomprehensible to readers in those countries - to take a bad example, I doubt "hood" is as widely known as the US version of "bonnet" as you expect. I see this first hand; the company I work for also randomly sells high end outdoor catering appliances - we had to rewrite our entire website prose for the US market because it made no sense to any of you guys :) I think the current implementation is the best - ok so it is not standardised, and without strict policy definition it risks arguments and edit wars over single words. But on the other hand it leniently allows for the right language in the right place, where that does not make sense on a local level then it is easily changed. <joke>(also; we were first :) so if we standardise on anything it should be UK English ;))</joke> --Errant [tmorton166] ^(chat!) 19:32, 23 September 2010 (UTC)[reply]

Without wanting to get too pompous or pontifical, English has always been an evolving language, sometimes (in my humble opinion) changeing † for the better and sometimes for the worse, and always absorbing an enormous number of outside influences in every generation while discarding other features both "native" and imported. The spread of popular music, film, television and the Internet (as well as physical travel and migration) has only accelerated this process. Pinning down a "British" Wikipedia that Lord Reith would hardly consider acceptable, or an "American" one that would cause Noah Webster to weep, is pretty futile. While the Oxford University Press's U.S. editions do indeed use American spelling and punctuation, most people don't expect to see the Oxford Dictionary of the English Language spelt in a U.S. variant, or the Columbia Encyclopedia in a British one (the Columbia Encyclopaedia). And that's not considering all the recent influences of Caribbean, African, South Asian and East Asian English, plus the influences brought by 1st and 2nd generation Commonwealth immigrants to Britain, Canada and Australasia, and by Hispanic, Asian and Caribbean ones to the United States. Much of that vocabulary, grammar and style, as with most variations in every generation, is of course transitory colloquial street speech that will not last, but some will seep in directly or indirectly; the changes will assimilate so completely that first-year student of philology a century from now will need to do research to recognize their origins. You certainly don't need different editions of Wikipedia to handle all that; just commonsense and a great deal of care to ensure that a word or phrase you're using isn't either obscure or outright misleading to someone in a different country or with a different background. ¶ Because of its nature and origins, Wikipedia will always be written in a strange cosmopolitan semi-popular/semi-academic style, complete with arcane conventions, that no human being would ever use anywhere else, but that's Wikipedia. —— Shakescene (talk) 19:47, 23 September 2010 (UTC) † [I was going to go back to delete the "e", when I realised/realized that this once-common, and not-incorrect, British spelling makes a relevant point.][reply]

That's a good point; unlike many languages (French in particular comes to mind) which have governments which laughably claim ownership over the language and attempt to control it, English has no such authority, and thus grows and changes organically. It's is famously as impure as a cribhouse whore, so why even attempt to pin down two versions, let alone the hundreds that are in use? --Golbez (talk) 19:59, 23 September 2010 (UTC)[reply]

Thanks for reminding me of a point I forgot to make in my sea of other prose: although there have been many attempts to establish one, there is as yet no credible or widely-recognized/recognised (let alone legally binding) English-language equivalent of the Académie Française or the Real Academia Española (which, I learned from Wikipedia, has roughly 20 matching official authorities, one for each of the non-Iberian Hispanophone countries, including an embryo one for the world's second-largest speaker of Spanish, Los Estados Unidos de América. Yet, although there's a Catalan Wikipedia, there is as yet no Latin American or Ibero-Spanish Wikipedia, let alone a Mexican, Cuban or Argentine one.) After decades of wrangling and heart-wrenching, the linguistic authorities in Portugal, Brazil, and the other Lusophone countries finally came to an agreement (almost a treaty) about which accents to keep and which to retire (cf. a similar debate about the evolution of German among the West German, East German, Austrian and Swiss authorities), but even if they had not, I think Portuguese Wikipedia would have remained a single Project. —— Shakescene (talk) 20:16, 23 September 2010 (UTC)[reply]

¶ Some references (out of order) within Wikipedia for my remarks above: Portuguese Language Orthographic Agreement of 1990, German orthography reform of 1996, Association of Spanish Language Academies, and List of language regulators. —— Shakescene (talk) 21:43, 4 October 2010 (UTC)[reply]

English has no such body — and a good thing too. Those academies are a terrible idea. They MUST NEVER EVER EVER be tolerated in English. --Trovatore (talk) 01:49, 24 September 2010 (UTC)[reply]

Nonsense suggestion. All these variants of English are easily understandable to anyone with understanding of one. This is hardly like variants of some other languages eg Chinese YellowMonkey (new photo poll) 02:05, 24 September 2010 (UTC)[reply]

Just a little philosophical aside- wouldnt it be interesting to split English Wikipedia in two and see how each evolves, not spelling-wise, we already know what changes to each article would occur, but as far as policies, guidelines, consensus-decisions and such. How would different problems, both current and future ones that pop up be handled in each Wikipedia... as it is each language Wikipedia does have different "rules" and policies down to the smallest thing. I would find it interesting in how consensus is reached in each Wikipedia and how they may differ, even in the smallest aspects, after 5, 10, and 20 years.Camelbinky (talk) 01:10, 27 September 2010 (UTC)[reply]

As an Australian English user I can comprehend just about every other version of English. I just note that probably every second day I find myself reverting an incorrect spelling correction, almost always from UK to US English, and almost always by an IP editor (who is never going to read this stuff!) I feel that this Wikipedia, using all versions of English, is actually providing an education to those who don't yet know that there is more than one "correct" form of English spelling out there. HiLo48 (talk) 01:08, 27 September 2010 (UTC)[reply]

Yes. Variations in any language can be viewed as proposed improvements (-our => -or), or explorations of possibilities (windshield, windscreen?), but if the ultimate shared form is to be determined by worth (instead of by commercial or population dominance) then there needs to be forums of mixed usage where they can be compared. Some readers may find this confusing, but that kind of challenge is a valuable education, evolutionarily necessary. - J. Johnson (JJ) (talk) 22:06, 29 September 2010 (UTC)[reply]

arbitrary break number 2

It seems to me that (1) a "main" English wikipedia should exist. (2) And that any variant English wikipedia should be accessed via tabs , like the Chinese wikipedia, which uses tabs for different Chineses. (3) should these come about, a new reviewer flag would be needed so that any new contribution to a dialectal article branch should also be in the main branch article, and that the new dialectal article edit does not go live until the main article is checked for consistency with new facts or imrpovements, but that's quite a bit of work. There would not no auto-sighting on the dialectal versions, going live would require a log entry stating the check was done.

I wouldn't want to read 6 different English variants just go get information, by rereading material over and over again, just because a fact appeared here and not there. 76.66.200.95 (talk) 06:02, 28 September 2010 (UTC)[reply]

The software could be enhanced to "transliterate" the English content in the database into different types of English, able to be selected in the preferences by users and auto-voodoo selected for anon users based on useragent info. This has been suggested as a solution for date formats, but the main drawback is that the internet caches would then need to have multiple copies of the same pages, in order to give the desired English to users. There would probably be some efficiency in that British users and anons in Britain would likely want to read Wikipedia in British English, so there would be less need for American English version of the content in British caches. John Vandenberg ^(chat) 10:34, 6 October 2010 (UTC)[reply]

Multiple English language versions are indeed a non-starter. But a single EN wiki that people could choose to view in their preferred spelling would be a step change improvement in the pedia. Especially if we take John Vandenberg's suggestion and default the appearance to IPs according to the predominant spelling of that area. The reduction in good faith US corrections of GB spelling that we need to reverse would be a big bonus, it can't be a particularly positive start to one's wiki career to have your first edits reverted as unhelpful. Ϣere SpielChequers 11:36, 6 October 2010 (UTC)[reply]

I completely support this proposal as I can't understand American English. I'm joking. The reason that there are different Chinese Wikipedias is that there are two major languages spoken in China, and they are almost completely different. Ajraddatz (Talk) 15:30, 8 October 2010 (UTC)[reply]

Copying userrights from sysop to bureaucrat

I would like to see if there are any objections to copying the following userrights from the administrator group into the bureaucrat group:

Move pages with their subpages (move-subpages)
Not create redirects from source pages when moving pages (suppressredirect)
Override the title blacklist (tboverride)
Use higher limits in API queries (apihighlimits)
Search deleted pages (browsearchive)
View deleted history entries, without their associated text (deletedhistory)
View deleted text and changes between deleted revisions (deletedtext)

removed from original proposal as not strictly necessary

~~Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)~~
~~Bypass automatic blocks of proxies (proxyunbannable)~~
~~Quickly rollback the edits of the last user who edited a particular page (rollback)~~

This would allow a bureaucrat to perform their duties without requiring a sysop flag. –xeno^talk 19:28, 27 September 2010 (UTC)[reply]

Aren't all crats sysops anyway? Is this not a solution in search of a problem? → ROUX ₪ 19:29, 27 September 2010 (UTC)[reply]

The problem is that a bureaucrat can't shed his or her sysop flag without losing abilities required for the job. (And, while no non-sysop has ever been successful at RFB, adminship is not a requisite.) –xeno^talk 19:31, 27 September 2010 (UTC)[reply]

I guess I'm not understanding.. why would they need to shed the flag? Also, if it is (theoretically) possible for a non-admin to become a crat, isn't that an argument against adding admin privileges to the crat flag, as then crats would have abilities which the community hasn't approved at rfa? → ROUX ₪ 19:37, 27 September 2010 (UTC)[reply]

I can think of at least two bureaucrats who have considered relinquishing their sysop flag but continuing to perform their duties as a bureaucrat. As for your second sentence - the abilities would have been added prior to any potential successful non-sysop RFB so the participants would know what they were getting into. (This is a bit of a red herring, as it's a highly unlikely scenario. The primary reason is to allow bureaucrats to resign their sysop flag if they so desire.) –xeno^talk 19:39, 27 September 2010 (UTC)[reply]

I dunno. I'm not objecting, really, just not understanding why the need to remove the flag. Plus this would set up (even more than already exists) a more explicit 'leveling up' thing. → ROUX ₪ 19:42, 27 September 2010 (UTC)[reply]

I suppose a bureaucrat could simply declare "I am no longer using administrative buttons", but they'd still be there, and (quite likely) people would still request they use them to perform various tasks (unaware of their declaration or otherwise). –xeno^talk 19:45, 27 September 2010 (UTC)[reply]

Ah.. so you are suggesting instead of the crat flag being an add-on, it is a phase shift? One or the other? Are there any crats who have stated they will no longer be performing admin duties? → ROUX ₪ 19:48, 27 September 2010 (UTC)[reply]

Not one or the other, and it would not change the current RFB promotion process. But it would give bureaucrats an option to relinquish their sysop flag without losing abilities integral to the bureaucrat role. For your second question - I'm not sure. –xeno^talk 19:50, 27 September 2010 (UTC)[reply]

While I understand the need for the additional move privileges and access to view deleted material while performing username changes, why would a bureaucrat who is not trusted by the community with any other access beyond that of a normal user need to bypass IP blocks or use the rollback function? --Allen3 ^talk 19:54, 27 September 2010 (UTC)[reply]

I must admit, the rollback was something I threw in there to prevent having to have bureaucrat, rollback, but I'll strike it. For the ipblockexempt and proxyunbannable bits, I'll have to ruminate on it to see if I agree that they shouldn't be included (struck for now). FYI the viewdeleted parts are also for evaluating statements made at RFA about candidates' deleted histories. –xeno^talk 19:59, 27 September 2010 (UTC)[reply]

For the record, I am one the bureaucrats Xeno is referring to above. I toyed with the idea of just picking up my 'crat flag for awhile and leaving the sysop flag down for awile. Xeno's comments here, though, turned me off to the idea. Just peeked through my logs, I've done one deletion since returning at the beginning of the month, and no blocks. But I have done renames. I've been trying to focus my efforts on article creation at the moment, as that's why I came out of retirement. Useight (talk) 20:02, 27 September 2010 (UTC)[reply]

Is there any harm in a crat just keeping his/her sysop flag even if they don't use it much? I mean, this just sounds sort of weird, and why would a crat really need the option of not having their mop? I don't see any harm for actively editing users keeping their rights, even if they don't use them much. (Now, for users who haven't edited in years, that's a different story.) But I just don't see when this would really be necessary. It's not like being an admin and a crat is hurting you or anyone else, I'd hope. /ƒETCH COMMS / 21:40, 27 September 2010 (UTC)[reply]

There are any number of reasons why someone might want to relinquish the sysop rights. Just ask any sysop requesting voluntary removal at meta why they've done it. –xeno^talk 02:19, 28 September 2010 (UTC)[reply]

IMO, this is a solution without a problem that will waste both the community's time in discussing it and developer's time in figuring updating sysop and bureaucrat groups everytime updating the sysop group becomes necessary. I mean, I guess we could if we want, but I don't think it is worth it to even bother discussing it. NW (Talk) 21:43, 27 September 2010 (UTC)[reply]

I agree with NW. If a crat wants to stop doing sysop things, they should just stop doing them. Its not like there's a limit on the number of sysop accounts we can have. Mr.Z-man 22:15, 27 September 2010 (UTC)[reply]

While it is not required for a crat to be an admin, I can't imagine the community electing one who isn't. I don't see why a crat would want to stop admin roles either, but eh. He can just stop. Don't see the need for this, per NW. — Rlevse • Talk • 22:55, 27 September 2010 (UTC)[reply]

There are countless reasons why someone might want to give up their sysop rights. It's part of the reason we have a WP:RESYSOP procedure. –xeno^talk 02:20, 28 September 2010 (UTC)[reply]

Self evidently pointless. Why on earth do we need this discussion? All 'crats are admins. This is either make-work or a solution in search of a problem. The only time I can see someone getting +crat without +sysop is at a foundation level; in which case it's not the communities problem / issue. Sorry, but this is without value. Pedro : Chat 23:30, 27 September 2010 (UTC)[reply]

@NW/Pedro: Despite your belief that this is a solution in search of a problem, do you have any specific objection to the proposal? –xeno^talk 02:19, 28 September 2010 (UTC)[reply]

This is rather needless. If a crat decides to resign the sysop bit but not the crat bit, then we should start worrying. But really, why would someone bother doing that, as things like viewing deleted pages and whatnot are useful to crats? I don't get why any crat would want to resign their adminship but still want to retain certain abilities (like viewing deleted pages). Either you keep both or none; it's just absurd to bother with the possibility of a non-admin crat. If you don't want to be a sysop but you do want to be a crat, stop using the sysop tools and keep using the crat ones. That seems easy enough. I mean, I understand where this proposal is coming from, but it just seems... weird and without any current application/purpose. /ƒETCH COMMS / 03:37, 28 September 2010 (UTC)[reply]

"why would someone bother doing that, as things like viewing deleted pages and whatnot are useful to crats?" Precisely. Right now they couldn't. Do you think they should be permitted to do so; if they desire? Is it such an unreasonable request to add a few words to an array to give them the option? (The future application you speak of) –xeno^talk 04:03, 28 September 2010 (UTC)[reply]

In this case, would it be reasonable for a new user right to be created for me, because I don't want the block ability but I like the rest of the stuff? What's wrong with all-or-nothing? I mean, this isn't a big deal, but I just cannot see why on earth anyone would ever bother doing this. Why should they be permitted to do so, if they so desire, but not me? (Why would they so desire?) Seeing deleted pages is part of being a sysop; just ignore the other abilities, no? (If I could, I would revoke from my account the ability to block users, because I don't like doing it.) I mean, can you specify one or two reasonable rationales for why one would wish to be a crat but not a sysop, rather than keeping the sysop bit but not using it other than for seeing deleted pages and such? /ƒETCH COMMS / 03:14, 29 September 2010 (UTC)[reply]

This isn't about creating a personal userright, this is about copying some required abilities for a bureaucrat into the bureaucrat usergroup. As an analog, there are several abilities in the admin flag that are also granted by other userrights (some redundantly, like autoconfirmed and "all users") because they are required or useful for the job. Reasons for not wanting to hang on to the sysop flag if one is not going to be using are numerous: it gives a more accurate count at WP:LOAA, it would discourage other users asking one to carry out administrative tasks, clean the interface of buttons that won't be used, removes the guilt factor for hanging onto a right one isn't using, the list goes on. As I suggested above, just query any user who ever gave up the flag voluntary as opposed to simply stopped using it. What I really don't understand is the push-back to this proposal. You wonder why anyone would bother doing this, but on the other hand: where is the harm in the redundancy being added? –xeno^talk 18:21, 29 September 2010 (UTC)[reply]

Also, if a crat removes their sysop bit voluntarily, can't they give it back to themselves? ~DC ^{We Can Work It Out} 03:41, 28 September 2010 (UTC)[reply]

Technically yes; but from a practical standpoint, they should re-request at BN to avoid the appearance of impropriety. –xeno^talk 04:03, 28 September 2010 (UTC)[reply]

Sure, why not? I always assumed bureaucrats can do everything admins can do, anyhow (Who would vote for someone as a bureaucrat, but vote against the same person as an admin?). --Conti|✉ 11:07, 28 September 2010 (UTC)[reply]

THIS. --Cybercobra (talk) 15:53, 28 September 2010 (UTC)[reply]

I can't see what the problem with this is. Bureaucrats aren't required to be admins by policy, so it makes sense to give them the buttons to do their job properly without the admin bit. Jafeluv (talk) 10:41, 29 September 2010 (UTC)[reply]

Agree with Jafeluv and others above. If these rights are needed to do the Crat job, then put them in the Crat userrights. Leaving them out seems like an end-run around the fact that Crats are not required to be admins. If these tools are needed for the job, then they should be granted to the job. Whether or not all current Crats are Admins is irrelevent. Policy doesn't require it, so there should be no artificial construct that makes it seem like a requirement. Jim Miller ^{See me | Touch me} 19:43, 29 September 2010 (UTC)[reply]

Policy doesn't require it, but practice does. Policy is supposed to reflect practice. Its incredibly unlikely that we will ever appoint a bureaucrat who isn't an admin, the only time this would matter is if a bureaucrat gave up the admin tools, which AFAIK has never happened. Changing policy to require crats to be admins would resolve this in a much simpler way while having no effect on how things actually operate (since we'd just be codifying standard practice). Mr.Z-man 22:01, 29 September 2010 (UTC)[reply]

And how would giving crats the additional rights change how things actually operate? Jafeluv (talk) 06:19, 30 September 2010 (UTC)[reply]

I didn't say it would. But changing the policy would be less work than this, we could do it immediately, and it wouldn't waste the time of the sysadmins. Mr.Z-man 14:48, 30 September 2010 (UTC)[reply]

There really is no work involved, apart from adding 7 words to an array. –xeno^talk 14:51, 30 September 2010 (UTC)[reply]

And then we get bureaucrats wasting the time of the stewards when they want a "break" but want to actually give up the tools for reasons that to me are just asinine. Then they waste the time of the other bureaucrats when they want the tools back a month later. It isn't very much work, but it is absolutely pointless. I see zero benefit from this other than to indulge the whims of some self-important users. Mr.Z-man 19:34, 30 September 2010 (UTC)[reply]

By that logic, we should eliminate the WP:RESYSOP procedure because it is a waste of time that allows people to indulge themselves? –xeno^talk 20:19, 30 September 2010 (UTC)[reply]

In a large number of cases, yes that's all it is. The idea of giving up the tools just so you can take a break or worse, "get a fresh perspective" (ugh) is just as asinine. If someone wants to take a break, just take a damn break. Not as many people will care as you think (or wish). You don't need to make it into some grandiose show like the changing of the guard. Mr.Z-man 00:25, 1 October 2010 (UTC)[reply]

What makes you think this was meant to be "some grandiose show"? I actually thought this was going to be a quiet proposal that would pass with no objections. The sound and fury that has presented itself against it has been quite shocking and peculiar. The proposal in its base elements is actually pretty tame. Seems like people are objecting for objection's sake. –xeno^talk 00:49, 1 October 2010 (UTC)[reply]

I wasn't talking about this, I was talking about the great lengths some people go to whenever they go on/return from a break, something that this will only encourage more of. Mr.Z-man 00:54, 1 October 2010 (UTC)[reply]

Other than your belief that relinquishing userrights is an asinine maneouver (which doesn't seem to be widely shared given that we have both m:SRP#Removal of access and WP:RESYSOP procedures to allow it), do you any specific objections to the proposal? –xeno^talk 01:00, 1 October 2010 (UTC)[reply]

I'm not saying that its always asinine, and I think you know that. Just the reasons why some people on the English Wikipedia choose to do so. There are plenty of valid reasons for relinquishing rights. My main objection is that its pointless. I can say with 99.999% certainty that we're never going to appoint a bureaucrat who isn't already an admin. If a bureaucrat wants to not use the admin tools, they can just not use them. If they want to go on a break, they can just go on a break. I can't think of, nor have I seen here, a good reason why someone should have +crat and not +sysop. Mr.Z-man 05:37, 1 October 2010 (UTC)[reply]

In essence, you don't like the idea of a bureaucrat giving up their sysop rights, and you can't think of a good reason why they would want to, nor do you like the examples I provided above. Fair enough. I appreciate your willingness to elucidate your position. –xeno^talk 14:14, 1 October 2010 (UTC)[reply]

Yes, the stewards won't be able to deal with the dozens of requests they get from bureaucrats every week. They'll be overwhelmed.. Yes, yes, I know. Sarcasm. Really helpful. But the "wasting everyone's time" argument is just so damn silly. This discussion has wasted more time than the implementation and the effects of the implementation would ever have. --Conti|✉ 22:55, 30 September 2010 (UTC)[reply]

All of the arguments in favor are just as silly. Mr.Z-man 00:25, 1 October 2010 (UTC)[reply]

How so? Seems pretty sane to me to assume that bureaucrats should have all the abilities admins have. --Conti|✉ 06:31, 1 October 2010 (UTC)[reply]

How convenient that they already do, because they're all admins. Mr.Z-man 22:13, 1 October 2010 (UTC)[reply]

Pretty much, yes. :) So here we have a situation where, practically speaking, implementing this or not doesn't really make much of a difference. Yet implementing this really wouldn't require any real effort on anyone's side (I'd be curious to hear from a developer whether this is actually true, I'm simply assuming it is), and some people find it useful, not to mention logical. This is a tiny, insignificant change with no extra effort involved from anyone. Worst case, nothing will happen. Best case, some people will find it useful. Why on earth would someone want to oppose this so vehemently? I don't get it. --Conti|✉ 13:39, 2 October 2010 (UTC)[reply]

By that logic, adminship really shouldn't include the rollback ability. :) We assume that someone who cannot be trusted with rollback cannot be trusted with adminship either, after all.. Really, this is silly. Just make the change and then let's all do something productive again. --Conti|✉ 16:28, 30 September 2010 (UTC)[reply]

If rollback had always been a separate group, there's a pretty good chance that sysop wouldn't include rollback. —Preceding unsigned comment added by Mr.Z-man (talk • contribs) 19:34, 30 September 2010 (UTC)[reply]

And it would be a sensible thing to integrate rollback into the sysop privileges eventually then. --Conti|✉ 22:55, 30 September 2010 (UTC)[reply]

I doubt it'll make any difference either way, but I agree with this for "correctness" reasons, more or less. Because of the possibility of a 'crat adminning themself, you couldn't make a user a 'crat unless you trusted them to be an admin, so it's not the sort of thing which is likely to make a difference. I can think of a potentially useful use for this, though; sometimes, in an emergency, you get developers or stewards temporarily granting themselves rights in order to perform actions (although more often on other wikis than enwiki, where there'd likely be many admins or 'crats willing to help in such a situation within ready reach). (I note that there have been cases of developers granting themselves admin rights before now in order to perform admin actions, IIRC occasionally causing controversy.) Although I can't think of a reason for an emergency closing of an RfA as passed, it doesn't take too much of a stretch to imagine a situation in which an emergency user rename was needed for technical reasons (even if a bit unlikely). (The extra permissions probably wouldn't be required for bot-flagging/unflagging.) In such cases, it would leave a clearer log entry if the user in question just marked themselves as a 'crat, rather than having to mark admin as well. I admit that this is a really contrived example, but as it doesn't matter either way, why not go for the more technically correct option? --ais523 20:10, 30 September 2010 (U T C)

Heh, and I just realised a situation in which a steward would need to close an RfA: if all the existing 'crats went inactive simultaneously. Not that that's at all likely to happen, of course... --ais523 20:11, 30 September 2010 (U T C)

So forming a Bureaucrat Union and going on strike could be powerful! Useight (talk) 14:38, 2 October 2010 (UTC)[reply]

Copying userrights from sysop to bureaucrat - arbitrary break

I'm scratching my head, but I still don't get why this is worth doing. In any emergency situation, a bureaucrat can make themselves an admin if they genuinely need to. For any non-emergency situation I'm struggling to see why a bureaucrat who for some reason is not an admin should have the rights that come with adminship without going through RFA. It just seems intellectually muddled to me, and I can't see any technical need to kludge it. Rd232 ^talk 14:29, 2 October 2010 (UTC)[reply]

Bureaucrats have two jobs requiring userrights: renames, and setting userrights.

The first three are needed for carrying out renames -

1. Move pages with their subpages (move-subpages) self-explanatory

2. Not create redirects from source pages when moving pages (suppressredirect) to avoid leaving behind redirects from usurped users userright shared by bots

3. Override the title blacklist (tboverride) in case a title blacklist false positive shows up during a rename userright shared by account creators

The following rights may be required when granting permissions; to review user history or community statements -

4. Use higher limits in API queries (apihighlimits) in case number crunching is needed userright shared by bots & researchers

The following primarily for evaluating RFAs -

5. Search deleted pages (browsearchive) userright shared by researchers

6. View deleted history entries, without their associated text (deletedhistory) userright shared by researchers

7. View deleted text and changes between deleted revisions (deletedtext)

Do note that only two of the userrights proposed to be added are admin-exclusive rights. –xeno^talk 06:03, 3 October 2010 (UTC)[reply]

Support - I think it would help the crats do their jobs. I thought they could already perform this action. According to the table at Wikipedia:User access levels bureaucrats can perform all of the actions you mentioned. Is the table incorrect? --Alpha Quadrant ^talk 04:17, 9 October 2010 (UTC)[reply]

Here is the table:

User access levels

Special:ListGroupRights is an automatically generated list of granted user group rights. The below table is manually updated, and also includes global groups with local access.

v t e Permission	Allows user(s) to…	All users^[a]	Registered accounts^[b]	Autoconfirmed and Confirmed	Bots	Administrators	Bureaucrats	other groups^[c]
abusefilter-hidden-log	View hidden abuse log entries							OS
abusefilter-hide-log	Hide entries in the abuse log							OS
abusefilter-log	View the abuse log	Y
abusefilter-log-detail	View detailed abuse log entries	Y		Y		Y		GR
abusefilter-log-private	View edit filters marked as private					Y
abusefilter-modify	Modify abuse filters							EFM
abusefilter-modify-restricted	Modify edit filters with restricted actions					Y
abusefilter-privatedetails	View private data (IP addresses) in the abuse log							CU
abusefilter-privatedetails-log	View the AbuseFilter private details access log							CU
abusefilter-revert	Revert all changes by a given abuse filter					Y
abusefilter-view	View non-private abuse filters	Y
abusefilter-view-private	View edit filters marked as private							CU, EFH, EFM, OS
apihighlimits	Request API queries in batches of 5,000, rather than 500				Y	Y		Researchers
applychangetags	Apply tags along with one's changes		Y
autoconfirmed	Not be affected by IP-based rate limits			Y	Y	Y		PCR, GR, IE
autopatrol	Automatically mark all edits made by the user as patrolled				Y			AP, GR
autoreview	Automatically mark all revisions made by the user as "accepted"			Y	Y	Y		PCR
bigdelete	Delete pages with over 5,000 revisions							Stewards
block	Block an IP address, user account, or range of IP addresses, from editing					Y
blockemail	Block a user from sending email					Y
bot	Edit without their edits showing up in recent changes				Y
browsearchive	Search deleted pages					Y		CU, OS, Researchers
centralauth-merge	Merge their account^[d]	Y
changetags	Add and remove arbitrary tags on individual revisions and log entries				Y	Y		EFM
checkuser	View all IP addresses used by a user account or show all edits from a given IP address							CU, Ombuds
checkuser-log	View the checkuser log							CU, Ombuds
collectionsaveasuserpage	Save books as user subpage		Y	Y
createaccount	Create a new user account for themselves or another user	Y				Y		ACCP
createpage	Create a new page		Y
createpagemainns	Create a new mainspace page (users without this right are redirected to the Article Creation Workflow landing page)			Y
createtalk	Create a new talk page	Y	Y
delete	Delete a page with ≤ 5,000 revisions					Y
deletechangetags	Delete tags from the database					Y
deletedhistory	View the history of a deleted page or a user's deleted contributions, provided it is not CSS or JS					Y		CU, OS, Researchers
delete-redirect	Delete single revision redirects during page moves							PMR
deletedtext	View the text of deleted revisions, provided the page is not CSS or JS					Y		CU, Ombuds, OS, Researchers
deletelogentry	Access the RevisionDelete tool and change the public visibility of log entries					Y		OS
deleterevision	Access the RevisionDelete tool and change the public visibility of edit revisions					Y		OS
Permission	Allows user(s) to…	All users^[a]	Registered accounts^[b]	Autoconfirmed and Confirmed	Bots	Administrators	Bureaucrats	other groups^[c]
edit	Edit any page which is not protected	Y	Y					IE
editcontentmodel	Edit the content model of a page					Y		TE, IE
editinterface	Edit the MediaWiki namespace to affect the interface					Y		IA, IE
editmyoptions	Edit your own preferences	Y
editmyprivateinfo	Edit your own private data (e.g. email address, real name)	Y
editmyusercss	Edit your own user .css files		Y
editmyuserjs	Edit your own user .js files		Y
editmyuserjson	Edit your own user .json files		Y
editmywatchlist	Edit your own watchlist	Y
editprotected	Edit fully-protected pages					Y		IE
editsemiprotected	Edit semi-protected pages			Y	Y	Y		PCR, GR, IE
editsitecss	Edit sitewide .css files							IA, IE
editsitejs	Edit sitewide .js files
editsitejson	Edit sitewide .json files					Y
editusercss	Edit other users' .css files							IA, IE
edituserjs	Edit other users' .js files							IA, IE
edituserjson	Edit other users' .json files					Y		IA
extendedconfirmed	Edit 30/500 protected pages				Y	Y		XC, IE
globalblock-whitelist	Disable global blocks locally					Y
hideuser	Block a username, hiding it from the public							OS
import	Import pages from other wikis					Y		IMP, TWI
importupload	Import pages from a locally stored XML file							IMP
ipblock-exempt	Be unaffected by blocks applied to the user's IP address or a range (CIDR) containing it				Y	Y		IPBE
managechangetags	Create and (de)activate tags					Y		EFM
markbotedits	Mark rollback as bot edits, to keep them out of recent changes					Y		GR^[e]
massmessage	Send a message to multiple users at once					Y		MMS
mergehistory	Merge the history of pages					Y
minoredit	Make an edit marked as 'minor'		Y
move	Change the title of a page by moving it			Y		Y		PMR, GR
move-categorypages	Change the title of a category by moving it				Y	Y		PMR
movefile	Change the title of a file by moving it					Y		FMV
move-rootuserpages	Move root user pages		Y			Y
move-subpages	Move pages with their subpages					Y	Y	PMR
movestable	Move pages under pending changes			Y		Y		GR
mwoauthmanagemygrants	Manage OAuth grants		Y
nominornewtalk	Minor edits by this user to user talk pages do not trigger the "you have new messages" banner				Y
noratelimit	Not be affected by rate limits				Y	Y	Y	ACCP, EVC, GR^[e], Stewards
Permission	Allows user(s) to…	All users^[a]	Registered accounts^[b]	Autoconfirmed and Confirmed	Bots	Administrators	Bureaucrats	other groups^[c]
nuke	Mass delete pages					Y
oathauth-enable	Enable two-factor authentication					Y	Y	CU, EFM, Founder, IMP, IA, OS, TE, TWI
override-antispoof	Allows the creation of accounts with mixed-script, confusing and similar usernames					Y	Y	ACCP
pagetriage-copyvio	Tag pages in the Special:NewPagesFeed as likely copyright violations, through the pagetriage-tagcopyvio API							Copyright violation bots
patrol	State that they have checked a page that appeared in Special:Newpages					Y		NPR
protect	Change protection levels, edit and move protected pages, and edit cascade-protected pages					Y		IE
purge	Purge a page by adding `&action=purge` to the URL		Y
read	Read pages	Y	Y
renameuser	Change the name of an existing account							Global renamers, Stewards
reupload	Overwrite an existing unprotected file			Y		Y
reupload-own	Overwrite existing files uploaded by oneself		Y
reupload-shared	Override files on the shared media repository locally					Y
review	Mark revisions as being "accepted"					Y		PCR
rollback	Use a special link to more easily revert a bad edit					Y		RBK, GR^[e]
sendemail	E-mail a user (using `Special:EmailUser/username`) who have associated an email address with themselves		Y
skipcaptcha	Perform CAPTCHA-triggering actions without having to go through the CAPTCHA			Y	Y	Y		GR
spamblacklistlog	View the spam blacklist log		Y					EFH
stablesettings	Configure how the latest accepted revision is selected and displayed					Y
suppressionlog	View private logs							OS
suppressredirect	Not create a redirect from the old name when moving a page				Y	Y	Y	GR^[e], PMR, IE
suppressrevision	Access the RevisionDelete tool and change the public and administrator visibility of edit revisions and logs							OS
tboverride	Override the title blacklist					Y	Y	TE, PMR, IE
tboverride-account	Override the username blacklist							ACCP
templateeditor	Edit pages under template protection					Y		TE, IE
titleblacklistlog	View title blacklist log (note: the log is empty, as it has not been enabled)					Y
torunblocked	Bypass automatic blocks of Tor exit nodes							IPBE
transcode-reset	Reset failed or transcoded videos so they are inserted into the job queue again			Y		Y
transcode-status	View information about the current transcode activity					Y
undelete	Undelete a previously deleted page or specific revisions from it, view deleted revisions					Y
unwatchedpages	View a list of pages which are not on anyone's watchlist					Y
upload	Upload a media file			Y		Y
urlshortener-create-url	Create short URLs	Y				Y
userrights	Edit all user rights							Stewards
viewmyprivateinfo	View your own private data (e.g. email address, real name)	Y
viewmywatchlist	View your own watchlist	Y
viewsuppressed	View revisions hidden from any user							OS
vipsscaler-test	Use the VIPS scaling test interface	Y
writeapi	Use of the write API	Y	Y		Y
Permission	Allows user(s) to…	All users^[a]	Registered accounts^[b]	Autoconfirmed and Confirmed	Bots	Administrators	Bureaucrats	other groups^[c]

^ ^a ^b ^c ^d Includes IP users. Any permission granted to all users will be inherited by the other user groups.
^ ^a ^b ^c ^d Any permission granted to registered accounts will be inherited by the other (registered) user groups.
^ ^a ^b ^c ^d Any user listed in this column has the relevant permission. Italics indicate a global permission.
^ Irrelevant since the SUL finalisation in 2015 where all mergeable accounts were merged.
^ ^a ^b ^c ^d Per Wikipedia:Global rights policy, Global rollbackers are only allowed to use this right in the context of counter-vandalism efforts.

The table is oversimplified, there is no inheriting. People just belong to more than one group, i.e. everyone belongs to "(all)", all registered users belong to "Users", all current Bureaucrats are also Administrators, and so on. The real list of who can do what is at Special:ListGroupRights. Anomie ⚔ 18:43, 9 October 2010 (UTC)[reply]

Change default skin back to monobook

I think the reasons for this are pretty obvious. It has a cleaner and simpler look and better usability without the over-the-top nature of the vector skin. Anyone agree with me? Access Denied ^{[FATAL ERROR]} 07:14, 28 September 2010 (UTC)[reply]

Nope. --Yair rand (talk) 07:31, 28 September 2010 (UTC)[reply]

Nope. d'oh! _talk 07:39, 28 September 2010 (UTC)[reply]

MONOBOOK FOREVER etc. etc. The thing is, the foundation paid loads of money for a new skin, and they are not going to revert the default back because of that fact. I'm sure this topic has several threads in the archives of the various village pumps, if you'd like to do more research on it (you're a little late on the draw). Killiondude (talk) 07:58, 28 September 2010 (UTC)[reply]

I agree, but then I'm still using the windows classic theme. Noodle snacks (talk) 09:27, 28 September 2010 (UTC)[reply]

The Usability Project claims otherwise. I'm just set in my ways and thus personally use MonoBook; setting the preference isn't very hard at all. --Cybercobra (talk) 09:45, 28 September 2010 (UTC)[reply]

I think we should stick with Vector. The reasons are pretty obvious. It has a cleaner and simpler look and better usability. Anyone agree with me? (X! · talk) · @497 · 10:56, 28 September 2010 (UTC)[reply]

Yes. Alzarian16 (talk) 11:05, 28 September 2010 (UTC)[reply]

Yes.—Emil J. 11:05, 28 September 2010 (UTC)[reply]

(in case it wasn't clear, the point of my reply was to show how baseless and subjective the arguments were. Personally, I do support Vector. I use it, and I think it's much better looking than Monobook could ever hope to be.) (X! · talk) · @928 · 21:16, 28 September 2010 (UTC)[reply]

Just revert back yourself. They even provided a helpful button to revert back to monobook on all Wikimedia projects, which was a great help. You can even keep using the former (and better) Wikipedia logo with css. –xeno^talk 12:48, 28 September 2010 (UTC)[reply]

Regardless of which skin is default, let the people (and that means unregistered users) decide for themselves which skin they want. Hpvpp (talk) 22:31, 28 September 2010 (UTC)[reply]

Allowing unregistered users to set preferences for themselves is counter-productive. They can register an account if they want that amount of control over how the site is displayed for them; that's not an unreasonable expectation on our part. EVula // talk // ☯ // 02:35, 30 September 2010 (UTC)[reply]

And unregistered users can't actually have preferences. They are associated with the account, which doesn't exist in this case. It would have to be saved to a cookie, which is totally different from how it's currently done. If the choice of skin is so important, why not create an account? Reach Out to the Truth 23:07, 1 October 2010 (UTC)[reply]

Most people use Wikipedia for what it is intended, namely to get information. Having to log in to an account to get a preferred look-and-feel is not worth the effort if the purpose of the visit was just to get some information. In addition, there are many sites out there that offer customization without that hassle so why can't Wikipedia, that very popular site? Furthermore, there are users out there that are not as computer literate as Wikipedia editors. Moreover, there are users out there that do not actually want, for whatever reason, to become that much computer literate, they just want to be able to get the information. And then there are the elderly of which there are many who would find it challenging to become computer literate. But they still have there preferences. And, lastly, there are those who have a dislike for change. And, indeed, "if it ain't broken, don't fix it". I, personally, don't appreciate it when people change something saying that "it's for your own good". Now, it might well be that vector is better for me, but I haven't seen a scientific demonstration to that effect. Failing that, let the choice of skin be stored in a cookie. (Which I proposed here, but which got ignored.) The majority of users are not contributors, but still have preferences which should be honored. Wikipedia is there for users and not just for registered users. Hpvpp (talk) 23:28, 3 October 2010 (UTC)[reply]

You can register, and have your prefs. If people caresmart enough about it to know they can change them in some fashion, they are smart enough to register. You don't even need an email here, unlike most sites. Your account will never even be visible if you never edit. Obviously allowing people to edit without registering is a good thing, but that doesn't mean that prefs should be saved without somehow. ♫ Melodia Chaconne ♫ (talk) 00:13, 4 October 2010 (UTC)[reply]

Some people not liking change is not a very good reason to avoid change. Your previous thread on this was not ignored. As was said in that thread, Wikimedia's caching infrastructure doesn't and can't support allowing anonymous users to have any preference that affect page display. In any case, almost nothing changed for people who do nothing but read articles. A few colors changed (slightly) and some things might have moved a few pixels but the only major difference for readers is the relocated search box. The rest of the major changes affect editors only. Mr.Z-man 02:16, 4 October 2010 (UTC)[reply]

Okay. Hpvpp (talk) 22:28, 4 October 2010 (UTC)[reply]

I like Vector, but if some IP doesn't, they can suck it up or create an account (yay!). The WMF did spend a lot of effort on this switch and it's happened. Either change it in your settings or spend some of your own money and time showing why Monobook is better (which it isn't, because it's outdated ugly). /ƒETCH COMMS / 03:08, 29 September 2010 (UTC)[reply]

Now there is still a lot of room for improvement for the Vector skin. Some changes are good usability-wise, some others are really lacking. It would be really long to thoroughly explain - especially to users who are not familiar with the Web usability guidelines - so I won't say more. But I am confident that those issue will be solved later on, and going backwards just won't help. Yours, Dodoïste (talk) 19:07, 29 September 2010 (UTC)[reply]

It's been quite a while since they trashed their cash, they can quietly admit the fact and turn monobook back on. Never say never. East of Borschov 06:34, 1 October 2010 (UTC)[reply]

I say switch back. I find it rather hard to verbally describe how to navigate this new one, which is why I stick with Monobook for all the private wikis I've set up for my clients. Frotz (talk) 04:06, 2 October 2010 (UTC)[reply]

I'm use to monobook and use that as my skin but I find there's one big advantage to having vector set as the global default. It makes it immediately obvious if I'm for some reason not logged in. --Ron Ritzman (talk) 02:52, 4 October 2010 (UTC)[reply]

Same here. ♫ Melodia Chaconne ♫ (talk) 04:14, 4 October 2010 (UTC)[reply]

Good point, I guess I can get rid of my green save button now =] –xeno^talk 12:52, 4 October 2010 (UTC)[reply]

Vector already appears more user-friendly to me than Monobook, and it's more likely to be the basis of further improvements. There is always resistance to change in a user interface. Even the mere fact that the resistance stayed within reasonable bounds even though Monobook had been the default for such a long time indicates that it is an improvement. Personally I am missing one of my former extensions (which isn't compatible), but am otherwise very happy with the change. Hans Adler 13:04, 4 October 2010 (UTC)[reply]

Not only do I think that vector is more user friendly, I like the look of it, and would opposing having the default switched back to monobook. Ajraddatz (Talk) 15:34, 8 October 2010 (UTC)[reply]

I tried to get used to Vector, but I couldn't. The main thing is I just don't like where the search box is. The Monobook choice for the search box location is better. --Trovatore (talk) 16:07, 8 October 2010 (UTC)[reply]

Advertising

This discussion has been closed. Please do not modify it.

The following discussion has been closed. Please do not modify it.

I know that this is a perennial proposal, but I would like to reopen this for discussion because consensus can change.

I would like to propose that a single innocuous random ad be placed at the bottom of every article. The ad would not need to be on the behind the scenes page but only the articles. The money can go to the wikimedia foundation or to various charities chosen by the community. This website is simply far too popular to ignore the tremendous amount of good that can be done even with one day of advertising. It would also motivate me to work on the encyclopedia more because the work would be contributing to a source that is doing a lot of good. I would like to discuss this with the community now. --Iankap99 (talk) 20:29, 3 October 2010 (UTC)[reply]

The foundation is currently asking for creative proposals for fund-raising advertising in the encyclopedia – see here for details. The projected income from soliciting donations is apparently much higher than the return from hosting third party ads, and of course there is less potential for conflict of interest. - Pointillist (talk) 21:19, 3 October 2010 (UTC)[reply]

If I may, I don't buy that, I think the donations game will be over. I think after the last drive, the donations wont even be close. I also never understood why people would think there would be a conflict of interest, we know that wikipedia is done by us. Also the prospect of me constributing for charity would motivate me and many others.--Iankap99 (talk) 22:12, 3 October 2010 (UTC)[reply]

The charity-choosing process would be terribly divisive (geographically, ideologically, etc.). --Cybercobra (talk) 21:31, 3 October 2010 (UTC)[reply]

I see what you mean, but something like this would be uncontroversial. World Cancer Research Fund--Iankap99 (talk) 22:11, 3 October 2010 (UTC)[reply]

No it wouldn't, because I would oppose it. — Gavia immer (talk) 22:22, 3 October 2010 (UTC)[reply]

Almost any charity will have its detractors, the anti-vivisection lobby would be likely to be offended at any medical research charity. Picking one or several charities would inevitably mean not picking many more charities that others believe are more worthy. I've seen several proposals for advertising in the last couple of years, but I've yet to see one that tackles the problems of us breaching NPOV by advertising, and therefore endorsing, another entity (charitable or not). Or the problem that the foundation has a particular charitable remit that probably doesn't include fundraising for others. There is also the issue of the priority we get in searches from certain search engines - would we get such high rankings if we started to compete for their advertising revenue? Ϣere SpielChequers 22:38, 3 October 2010 (UTC)[reply]

Ok well then what about the money going toward the wikimedia foundation? And NPOV wouldn't be breached because the advertising would be random, there would be no reason to think that the content would be compromised.--Iankap99 (talk) 23:11, 3 October 2010 (UTC)[reply]

Even if the ads are randomly displayed (and that can go poorly as well; ads for exterminators on articles about the Holocaust are the classic example), there's still a company paying to display them. Even if ads for Company X don't appear on the article for Company X, Company X is still giving the WMF money to run ads. Even if NPOV isn't actually violated, there's still an appearance of it. Mr.Z-man 23:28, 3 October 2010 (UTC)[reply]

The exterminator example is an interesting pun, but it can in no way damage the article. The company x example too, doesn't hurt the article. All of the arguments saying that NPOV would be breached are that others would think that it is breached. But no one actually argues that the article will be harmed.--Iankap99 (talk) 00:16, 5 October 2010 (UTC)[reply]

You are missing the point entirely. Obviously nothing that actually compromises the quality of articles would be accepted. So there's no point in comparing any theoretical system to that. It needs to be compared to Wikipedia without adverting. We can put out as many press releases as we want claiming that it has no effect on the content of articles, we could even be truthful when we say it. That won't change the fact that a lot of people won't believe it. Mr.Z-man 02:25, 5 October 2010 (UTC)[reply]

Consensus isn't changing on this issue right now. Your proposal is nothing new, and it's quite obvious that people are disagreeing even now. I, for one, oppose this. /ƒETCH COMMS / 23:21, 3 October 2010 (UTC)[reply]

If we decide to allow advertising, then how can we continue to respond to advertisement pages and spam with "Wikipedia is not for advertising" when the misguided newbie (or not) points out that advertising already exists on every page? I also oppose this proposal. Intelligentsium 23:31, 3 October 2010 (UTC)[reply]

We say that wikipiedia is not for independent advertising. There's no reason that this should stand in the way of a major economic proliferation opportunity for WMF on such weak grounds of how to explain to a newcomer what belongs on a wiki page.--Iankap99 (talk) 00:19, 5 October 2010 (UTC)[reply]

STRONG, STRONG, STRONG OPPOSE. Sorry for the shouting. Access Denied ^{[FATAL ERROR]} 00:03, 4 October 2010 (UTC)[reply]

I don't think a change of this type would ever come from a proposal from enwiki. It would be a major Foundation change of direction; if it ever happened, it would be their lead, maybe with some attempt to get the various communities (of which enwiki is just one) on board, presumably on the basis that the alternative would be dire, like some kind of financial/technical collapse. So, this discussion is pretty moot. Rd232 ^talk 17:06, 4 October 2010 (UTC)[reply]

However, if the largest wiki by far, en.wiki, was behind it, wiki never says no to the community.--Iankap99 (talk) 00:19, 5 October 2010 (UTC)[reply]

Hopefully that won't happen. But if you want to convince the foundation you could try putting your case on say meta:Wikimedia Forum, but I suggest you first read Encyclopedia Libre, and try to think how your proposal can generate big enough positives to offset splitting the community in the same way again. Be aware that when you say "lets take advertising" what a lot of people will be reading is "Lets split the community and gamble that the version with advertising and probably a minority of editors can beat the version with no advertising and probably a majority of the editors". Wikipedia only survived the Spanish split by ditching the idea of advertising before it was implemented. Ϣere SpielChequers 00:41, 5 October 2010 (UTC)[reply]

Even if a supermajority of the community supported it, advertising is such a divisive issue that you can assume that most of the minority will just leave the project. You would need near-unanimous support. But as fetchcomms said, there is nothing new in this proposal that is going to win people over. Mr.Z-man 02:25, 5 October 2010 (UTC)[reply]

The WMF recently conducted a focus group of previous donors. One of the conclusions was that people would rather donate than see paid ads. According to the linked page, "respondents were unanimous" on that point. A survey conducted of donors also found a similar result; 77.3% indicated that keeping Wikipedia free of advertising was a very good or extremely good reason for donating. 35.7% were very concerned or extremely concerned that Wikimedia would be forced to sell ads. Mr.Z-man 03:06, 6 October 2010 (UTC)[reply]

This is a snowball, that is the sun... There is no Wikipedia financial crisis, what possible rationale is there for whoring out the site to ubiquitous consumer capitalism? —Carrite, Oct. 5, 2010.

Increase Special New Pages from 30 days to 60 days

At Special:NewPages any article not marked as patrolled within 30 days is automatically marked as patrolled. The unpatrolled queue varies in length but is usually between three and four weeks, however there are times such as now when it runs to 30 days and a couple of hundred articles a day are being marked as patrolled simply because they have survived 30 days. ~~I propose we lengthen the time period to sixty days,~~ (see later in this thread - for technical reasons this has been amended to add a hidden category to articles that are still unpatrolled after 30 days) this will hopefully reduce the number of articles which get through Newpage patrol by default rather than because someone has looked at them and marked them patrolled. Ϣere SpielChequers 14:48, 4 October 2010 (UTC)[reply]

I'm not actually convinced this would solve the problem at all in the long term. Quite frankly nobody patrols pages in the middle of the queue - they either get reviewed in the first few hours after they're created, or they get checked when they approach the end of the queue. If pages are getting through the thirty-day period without being patrolled, the only real solution is to recruit more patrollers to review the back of the queue. Otherwise, we'll increase it to 60 days, gain a brief respite, and then in all likelihood the backlog will reform at around the 58-60 day mark. If the change can be made easily, there's no real harm in it - but I equally doubt it will help significantly. ~ mazca ^talk 15:17, 4 October 2010 (UTC)[reply]

Whilst I agree that most patrolling activity is at the two ends of the queue, I do believe that a fair bit of deletion occurs in between - not least when projects look at articles newly tagged or categorised in areas of interest to them. As to whether extending the queue to 60 days merely postpones the problem or reduces it, I suppose that depends on whether this is just one of many oscillations in the length of the queue and in a month it could be back at three weeks, or whether there has been some fundamental change to the NPP process and the back of the queue team are no longer able to keep abreast of matters. I'm inclined to think of this as just an oscillation and therefore that increasing the queue length to 60 days will greatly reduce the number of articles that get patroled by default. But I also think we could take some pressure off NPP by appointing more suitable candidates as Autopatrollers, and of course more patrollers would be welcome. Ϣere SpielChequers 15:39, 4 October 2010 (UTC)[reply]

(ec)I'll second that proposal, WSC. The articles that languish at the bottom of the list are those that most new page patrollers don't know what to do with. The fact that they are all generally problematic, means that there really are a lot that must be either speedied, PRODed, and sent for AfD, rather than be allowed to default to 'keep', or should at least be tagged to point out their deficiencies. A significant number of them are:BLP, which is our greatest area of concern.--Kudpung (talk) 15:42, 4 October 2010 (UTC)[reply]

How can we be sure that anyone is working from the bottom of the list? I know I do, but what I can get through is just a drop in the ocean. Perhaps we could organise a special drive with barnstarts as a carrot - or would that simply invite too much more drive-by?--Kudpung (talk) 15:49, 4 October 2010 (UTC)[reply]

Well there are a number of editors who certainly have worked there and discussed their findings. At the beginning of the year the backlog was actually cleared at one point. If the oldest unpatrolled artcle is less than 30 days old then I'm happy to assume that some editors are or have been active there recently. If I'm working there and get edit conflicts then I know there are others active. As for incentivising this with barnstars et al I'm cautious, I'd much rather have patrollers who tag what they are certain should be deleted, mark as patrolled what they are sure belongs and attempt to categorise the rest; But who don't individually attempt to keep up with the flow - as that in my view leads to people feeling pressured and even taking shortcuts. Ϣere SpielChequers 16:39, 4 October 2010 (UTC)[reply]

Why are unpatrolled pages marked automatically as patrolled in the first place if they haven't been patrolled by anybody?--Tikiwont (talk) 16:00, 4 October 2010 (UTC)[reply]

Because behind the scenes, it's edits in recentchanges (not active on enwiki) / newpages (active on enwiki) that are marked as being patrolled, rather than articles. Once an edit falls off the end of recentchanges/newpages, there's no edit around to require patrolling. So the pages aren't exactly marked as patrolled, but there's nowhere that the software stores that they're unpatrolled, which comes to much the same thing. --ais523 16:15, 4 October 2010 (U T C)

Thanks. I'd prefer a full record of such pages as opposed to have some of them fall off. So why not disable the cut-off or make it 90 days at least. --Tikiwont (talk) 16:39, 4 October 2010 (UTC)[reply]

The proposal makes sense to me. If in a while we end up with the same situation with new articles c 58-60 days old, at least we'll have learned something, and in the mean time, some articles won't have gone unpatrolled. In addition, maybe there should be more of an effort to eg use {{new unreviewed article}} for problematic articles no-one's quite ready to grasp the nettle on - for the "hard" cases "that most new page patrollers don't know what to do with" (as someone said above). (This could be added as a suggested option in the NPP guidance.) Rd232 ^talk 17:02, 4 October 2010 (UTC)[reply]

I think there's a misunderstanding of how this feature works. It's based on the recentchanges table, which has been set to 30 days for a very long time now. I don't think there's much (if any) chance of this time being increased, especially not to double its current value. It also wouldn't solve the underlying issue very well. --MZMcBride (talk) 17:12, 4 October 2010 (UTC)[reply]

But why should it continue to be based on the recentchanges table? Surely new page patrolling is important enough to have a table of its own that would allow longer timespans? Alzarian16 (talk) 17:19, 4 October 2010 (UTC)[reply]

I suppose another table could be added. I think 30 days is reasonable, personally. This wiki has thousands and thousands of active contributors. If it can't keep up in 30 days, it's probably not as much of a priority as people make it out to be. I don't think the solution is to enable a bigger backlog. --MZMcBride (talk) 17:28, 4 October 2010 (UTC)[reply]

One solution would be to more strongly encourage the guiderule that suggests people patrol from the back. –xeno^talk 17:30, 4 October 2010 (UTC)[reply]

Whether you think 30 days is reasonable or not this is a volunteer project and every now and then 30 days is not long enough at NPP. Remember this process is cyclical and we've often had 30 day backlogs before. This is about what happens when articles go over the thirty days - are we still happy to go on automatically marking them as patrolled or do we want to treat them differently? Ϣere SpielChequers 21:19, 4 October 2010 (UTC)[reply]

I asked Domas about this. He says it's more likely to be reduced to 7 days. I really don't see any chance of this proposal being implemented. The underlying problem and possible solutions should be re-examined instead. --MZMcBride (talk) 17:40, 4 October 2010 (UTC)[reply]

The reasons why articles sink to the bottom is not one of lack of encouragement. It's the difficulty level. However, we naturally need people working hard and accurately at both ends of the list - for quite different reasons of course. One thing is for sure, of the thousands and thousands of active contributors working on the Wikipedia, there are probably fewer than five or ten (I'm just guessing) working on NPP at any given time. Nothing short of at least 45 days is going to give us a chance to keep the current backlog down, and to prevent some really bad articles from slipping unchallenged or unimproved through the net. --Kudpung (talk) 19:02, 4 October 2010 (UTC)[reply]

Given that I think the main concern here is that (substandard) articles will disappear into the ether after the magic cutoff of 30 days, hows about I have a go at coding a permanent log of all those that dropped off untouched? I might not be successful, mind, and also, even if I were, maybe I shouldn't publicise the fact. But we can cross that bridge if we come to it. How does that sound? - Jarry1250 ^{[Who? Discuss.]} 19:24, 4 October 2010 (UTC)[reply]

I would prefer to see an extension to at lest 45 days, but your idea jarry, isn't such a bad one either. What would you call it? 'Log of not so new unpatrolled pages'? ;) --Kudpung (talk) 19:54, 4 October 2010 (UTC)[reply]

I'd prefer a wp:hidden category, category:Unpatrolled new article that way anyone can find them, and just as importantly people can remove the hidden category almost as easily as reviewing them. Ϣere SpielChequers 21:04, 4 October 2010 (UTC)[reply]

Of course, once you've got the list, you can just make a bot add the category. - Jarry1250 ^{[Who? Discuss.]} 21:16, 4 October 2010 (UTC)[reply]

Yes, but a list may not get updated each time someone works on one of the articles on it, whilst if we use a hidden category any editor working on one of those articles could decide to remove an unpatrolled category. And if you want a list the category itself gives you one. Ϣere SpielChequers 21:23, 4 October 2010 (UTC)[reply]

Great, another maintenance category that can get backlogged for years. This isn't sensible. Either people care enough to patrol them in a reasonable timeframe or they don't. I suppose there's no stopping a hackish bot implementation (which is probably the "best" solution you're likely to get anytime soon), but it's rather silly all around. At least don't include "new" in the category titles, please. --MZMcBride (talk) 22:14, 4 October 2010 (UTC)[reply]

Happy to make it category:Unpatrolled articles if that suits you, but I wouldn't be so sure that it will become another of the permanent backlogs, we've had NPP for years and it is usually below thirty days. All this proposal does is close a loophole in the process. Ϣere SpielChequers 00:09, 5 October 2010 (UTC)[reply]

It'd be great if it stayed at about 30 days (or maybe 45 days). But I think history has shown that once the incentive is removed to keep it pruned, it's going to fall behind (that is, unless a few dedicated people keep an eye on it constantly). This is the same way that anything on this site works. Right now, there's at least an incentive to act because after 30 days, the pages will "fall off the cliff." That's after 30 days, not after a week or even two weeks. Thirty days in wiki-time is quite a while. You'd also be introducing a bot dependency, and bots have a horribly nasty habit of breaking or having their maintainers disappear after a few weeks or whatever else. I'm not trying to be pessimistic, but a lot of this seems very predictable. We'll see what happens. --MZMcBride (talk) 02:42, 5 October 2010 (UTC)[reply]

On another note, can the watchlist and recent changes made to go back furhter? YellowMonkey (new photo poll) 00:17, 5 October 2010 (UTC)[reply]

It's all the same database table, controlled by the same configuration variable (mw:Manual:$wgRCMaxAge). As I said above, I talked with the person who's the go-to guy for Wikimedia database infrastructure and I've heard him talk about this before. It's a "hot" table (constantly changing and constantly being queried), it already contains a lot of data (think about how many edits and actions are done in a day, times 30), and there are real implications to changing the timeframe. Dumps would suddenly expand, the Toolserver's replicas of the databases would suddenly expand, queries that relied on the data only being so old would suddenly be returning older results... it's certainly not impossible to change $wgRCMaxAge, but it wouldn't be a small thing. Watchlists and Special:RecentChanges are already limited (watchlists to seven days, RC has no pagination) because of how expensive querying the database is (and updating a zillion rows with info like "(top)" and whatever else). --MZMcBride (talk) 02:42, 5 October 2010 (UTC)[reply]

Sorry to sound naïf, but I know nothing about tables, dumps, and programming bots - I wouldn't even know how to make a simple template with a built in function - so a lot of this is over my head. However, if we already have bots that automatically add categories and compile lists of categories that can be made available to those who subscribe to them, where, in laypersons' terms, is the real difficulty in automatically creating a list of the new pages that are falling of the cliff? Kudpung (talk) 03:16, 5 October 2010 (UTC)[reply]

Hmm, I'll try a poor analogy. You've got the ocean (all edits to the site). That's the revision table. You've got a good-sized river that flows into the ocean. That's the recentchanges table. Along the edges of the river, people have set up their houses and their town, based on the size of the river.

This proposal is about making the river double its size. Now, there isn't anything impossible about this. It's certainly possible to implement, but doing so has consequences. Suddenly instead of being 100 feet wide and 500 feet long, the river is now 150 feet wide and 666 feet long. That changes a lot, in some large and small ways.

As with nearly any software development, given enough time and energy, nearly anything is possible. Nobody is saying that raising the new pages limit from 30 days to 60 days isn't possible. They are saying it might not be desirable to do so due to the side effects, though. And they are saying that there might be better ways to solve the underlying problem.

All that said, the subsequent proposal is to build a dock into the ocean a bit. That is, to implement a bot that will automatically categorize these pages and then generate a list of them (either dynamically or statically). That also certainly isn't impossible, but as I said above, it's a bot dependency (which isn't usually great) and it just delays the inevitable underlying issue (that there are pages to patrol). It kills the incentive to patrol new pages if the deadline has been moved (cf. procrastination). I'm not sure what the equivalent analogy is, but I think this clarifies a bit. --MZMcBride (talk) 04:48, 5 October 2010 (UTC)[reply]

I actually agree with you (FWIW). A list that people know the existence of removes the attraction of getting it done before the thirty days (one might call the effect moral hazard). A list that nobody knows the existence of makes sure any pages that do fall through get checked. So, if I say now that it might be possible, would someone like to volunteer to privately take on full responsible for checking the list (without giving away its existence) if I could build it? Then we all assume I failed and go back to the regular 30 day patrol. Hell, I'll even say I failed if it helps. But it'll be a thankless task, since you could never claim your prize; to do so would to be to admit that articles no longer disappear into the ether and ruin the whole NPP temporarily. If you're still interested, email-this-user me, rather than posting here. Then it'll look like to all intents and purposes that the project failed on two separate fronts. (I realise, of course, that the above sounds very non-wiki-like. But you might say that needs must. If you want to object to the whole idea, feel free; it's not a perfect solution.) - Jarry1250 ^{[Who? Discuss.]} 18:03, 5 October 2010 (UTC)[reply]

Tempting, and thanks for the offer, but this is of its nature a task for multiple people not for one editor. I've been happy to go through new pages screening out attacks and reading the articles that interest me and marking them patrolled if I think it appropriate. But there are whole subject areas that I ignore and I assume others think likewise. I also bitterly resent the idea that a loophole should be left in the process simply because the existence of that loophole might encourage editors to work harder - we are volunteers and leaving arbitrary loopholes to motivate volunteers to work harder seems to me a terrible way to demotivate a group of volunteers. Ϣere SpielChequers 12:28, 6 October 2010 (UTC)[reply]

NPP patrolling bots

To me, the best and only way to solve unpatrolled articles is to create patrolling bots. It should be possible. I am a violinist ♫ talk to me here! 12:27, 5 October 2010 (UTC)[reply]

First find your bot writer Wikipedia_talk:Criteria_for_speedy_deletion/Archive_36#possible_botting_of_speedy_deletes is an example of a bot that would do a few thousand non-contentious speedy deletions a year, many from New Page Patrol. But you need a volunteer to write and run it.

It would be great to extend Igloo or Huggle with options that would show suspect new articles to hugglers and allow them to also tag for speedy deletion/mark as patrolled. That wouldn't directly alter the back of the queue as you very rarely get blatant vandalism or attack pages there, but it might help indirectly by screening some more at the beginning.

Where a bot would be doable and really useful to NPP would be to select a list of candidates for the wp:autopatrolled flag, at the moment it is very time consuming checking out potential candidates who've submitted a well referenced new article only to find they may not meet the criteria. A bot that created a shortlist of likely candidates would make a real difference - I'd certainly be willing to review a bunch of them and where appropriate flag some as Autopatrolled. Again getting a willing bot or report writer is the difficult thing, I've tried several times to find one for this. But flagging more editors as Autopatrolled would certainly take some of the workload off NPP. Ϣere SpielChequers 16:15, 5 October 2010 (UTC)[reply]

Bot writer here - ping my talk page if you decide on something here to be coded. 930913 (Congratulate/Complaints) 05:46, 6 October 2010 (UTC)[reply]

Alternative

What about making more use of the existing {{new unreviewed article}} infrastructure? That already has dated maintenance categories etc (and I see discussion above about creating a new one). It's also already integrated into WP:Twinkle for easy tagging. A big part of the problem with pages being unpatrolled longer than 30 days is "hard" articles - articles no-one's quite sure what to do with. If these are tagged with {{new unreviewed article}} (which a bot could do automatically, and in the mean time it can be manual) then you have the dual purpose of (a) warning the reader that it's a new article that's not really been reviewed by the community (b) placing it within a process where it may well be ages before someone gets round to doing anything about it, but at least it's being tracked, which is better than the status quo. This is a low-cost alternative - it doesn't even need a bot, though that would be helpful. Rd232 ^talk 13:25, 5 October 2010 (UTC)[reply]

This sounds like a great idea to me. Fully support. Alzarian16 (talk) 20:19, 5 October 2010 (UTC)[reply]

I fundamentally disagree here. At the minute, very few articles make it past 30 days and drop off the end of the list. Why? Because the 30 days is a stick. It prevents (as MZM mentions above) endless procrastination. Tagging and leaving will just leave us with a load of rubbishy articles on potentially non-notable subjects languishing for ages - potentially, cleanup crews will get there first, just to see the whole article deleted. Not good. Plus I can think of a good few ways to game the system, too. I mean, it sounds like a good idea, but the 30 day cutoff is a useful motivation that we should keep. - Jarry1250 ^{[Who? Discuss.]} 21:30, 5 October 2010 (UTC)[reply]

"potentially, cleanup crews will get there first, just to see the whole article deleted." - that's contradictory: any cleanup should either be trivial, or involve removing the new article tag. In addition, it's contradictory to say that the 30 day cutoff is a Big Stick, whilst allowing articles to drop into the long-term tracking pool of Unreviewed New Articles, which involves "potentially non-notable subjects languishing for ages" is no stick at all. From an NPP point of view, articles dropping off with {{new unreviewed article}} on them is only marginally better than dropping off without it. Nor is it an unfamiliar tag: because the Article Wizard adds it automatically, patrollers should be used to seeing it. So it shouldn't necessarily have that much impact on NPP behaviour for a bot to add it to, say 15-day old unpatrolled articles. Rd232 ^talk 23:27, 5 October 2010 (UTC)[reply]

The thirty day cutoff isn't a stick, it's just a loophole that means that every now and then a bunch of unpatrolled articles get past NPP. Ϣere SpielChequers 06:23, 6 October 2010 (UTC)[reply]

Quick Reference

I get on here, and I start learning about a topic, and by the time I have clicked on link after link I have forgotten what exactly I started with. This is especially true with technical pages. Many of the links I click on I would only need a quick reference to continue with the article I am on. I know I can open it in a new tab, I know I can just look quickly at the new page, but I see some other link in the new page that I end up exploring and well this continues. I would really like a small reference box to appear above the text, with a quick definition or important information, when the mouse rolls over the embedded link. A quick summary I believe would make mine and many others' wiki exploring much more efficient and focused. With technical pages this would be key there are do many items that all would be required is a definition. Thank you —Preceding unsigned comment added by 99.250.113.221 (talk • contribs) 14:34, 5 October 2010 (UTC)[reply]

That's a benefit of creating an account; there are customizations that can be made in the user interface so that, when you hover over a wikilink, it shows the first few lines of the article. —C.Fred (talk) 14:38, 5 October 2010 (UTC)[reply]

Yup. It's Wikipedia:Tools/Navigation popups. Fences&Windows 23:00, 5 October 2010 (UTC)[reply]

Public Energy Consumption Records

The Wikimedia foundation should publicly release the financial records. We built this encyclopedia, it would make sense for us to see the server costs, salaries, and donation statistics. --Iankap99 (talk) 22:36, 5 October 2010 (UTC)[reply]

Something like foundation:Annual Report, you mean? — Gavia immer (talk) 22:49, 5 October 2010 (UTC)[reply]

Thank you I have another one that there's a lower chance of existing.--Iankap99 (talk) 23:55, 6 October 2010 (UTC)[reply]

Does anyone else think that the energy consumption records should be released?--Iankap99 (talk) 23:55, 6 October 2010 (UTC)[reply]

This isn't the place to deal with that. Only the Foundation can decide what to release and what not to release. /ƒETCH COMMS / 23:56, 8 October 2010 (UTC)[reply]

Anything released by the Foundation would be primary, so to be useful, the data would have to be reported by a reliable secondary source. Anyway, what's with this "we built" stuff? What have you built? - Pointillist (talk) 00:14, 9 October 2010 (UTC)[reply]

We all built this encyclopedia.--Iankap99 (talk) 19:18, 11 October 2010 (UTC)[reply]

Indentation in Talk pages

The current policy is that we use indentation to separate different users' words in talk pages. But when discussion gets heated with a lot of replies on a same subject, the colons used to indent become more and more and the page looks ugly. Can we change it? Like making a dedicated box template?--Netheril96 (talk) 11:06, 9 October 2010 (UTC)[reply]

There is a template {{od}} Access Denied ^{[FATAL ERROR]} 15:46, 9 October 2010 (UTC)[reply]

The indentation doesn't just separate comments; it shows which previous comment is being replied to (see Help:Talk_page#Indentation). How would a box achieve that, without indentation? Also note that WP:LiquidThreads may eventually be deployed here. PL290 (talk) 19:22, 9 October 2010 (UTC)[reply]

PLEASE NO LQT'S. NO NO NO NO NO NO No. That goes against WP:NOTFORUM, WP:NOTBLOG, WP:NOTCHAT, WP:NOTTWITTER, WP:NOTFACEBOOK, WP:MYSPACE, and many other policies. It also will increase loadng times on my iPod touch. Plus, theyre ugly, and unwanted by nearly everyone. Access Denied ^{[FATAL ERROR]} 19:25, 9 October 2010 (UTC)[reply]

This looks pretty damn ugly. Access Denied ^{[FATAL ERROR]} 19:27, 9 October 2010 (UTC)[reply]

That's a matter of personal taste; looks fine to me personally. Regardless, would you at least agree that the conversational flow in the example is easier to follow? --Cybercobra (talk) 22:03, 9 October 2010 (UTC)[reply]

You're misinterpreting those shortcuts you cite (which actually only point to 2 distinct policies between them all; dept of redundancy dept!); they're about Wikipedia not being a social media site or web forum, not about our having "forums" in the sense of talkpages and meta-discussion pages. Otherwise, the Village Pump wouldn't exist and this discussion wouldn't be happening. --Cybercobra (talk) 22:03, 9 October 2010 (UTC)[reply]

Renaming the accountcreator group

I propose changing the name of the accountcreator usergroup to something like "account supercreator", since it's often confused with users who just have access to the ACC interface and who aren't necessarily part of the accountcreator group. As if to make it even more confusing, the bottom of the ACC interface main page displays "Account Creators currently online (past 5 minutes):". — Waterfox 14:53, 9 October 2010 (UTC)[reply]

God, just kill the whole user group already. And kill tools:~acc as well. What a horrible waste of time and resources. An entire sub-culture devoted to account creation. It's simultaneously completely mind-boggling, while at the same completely predictable for the English Wikipedia. Impressively idiotic. --MZMcBride (talk) 22:18, 9 October 2010 (UTC)[reply]
- Do you have a solution for people who cannot read the CAPTCHA, or who want a username that is falsely detected as being too similar to an existing username or is hit by the title blacklist? Anomie⚔ 22:52, 9 October 2010 (UTC)[reply]
  - Implement a proper extension into MediaWiki that allows admins to handle requests from users. Using the Toolserver presents a whole slew of issues that could have been and should have been completely avoided. --MZMcBride (talk) 06:16, 10 October 2010 (UTC)[reply]
    - Feel free to go ahead. [stwalkerster|talk] 14:22, 10 October 2010 (UTC)[reply]
    - (edit conflict) Go for it. See also Template:Bug. Although unless the situation behind Wikipedia talk:Request an account/Archive 3#Increasing Limit and Wikipedia talk:Request an account/Archive 3#Discussion on giving accountcreators override-antispoof right has changed, admins-only may not work out so well. Anomie⚔ 14:53, 10 October 2010 (UTC)[reply]
      - You don't see a problem with people implementing an entirely different system in the same programming language? There's an external server dependency, leaked private data (like IP addresses), an entirely different user auth and permissions system, a different user interface, and more... for account creation. I was involved in the discussions about this project much, much earlier. I said it was a stupid project then and nothing has changed. I'll re-open that bug. --MZMcBride (talk) 20:18, 10 October 2010 (UTC)[reply]
        It's more a problem of getting access to the svn repo, and writing to an API which many of the current developers are unfamiliar with, as well as getting updates code-reviewed and scapped when we need/want them. [stwalkerster|talk] 20:36, 10 October 2010 (UTC)[reply]
        
        I see a problem with advocating deleting the entire thing without any concern for why it exists in the first place or how the legitimate functions it provides would be done in the future. Anomie ⚔ 03:01, 11 October 2010 (UTC)[reply]
- I think you are confusing the necessity of the process with the subculture which has grown up around it. cf vandal fighting & huggle. → ROUX ₪ 22:56, 9 October 2010 (UTC)[reply]
Strong support Not commenting on the tangential issues raised above, the fact is that I agree in toto with Waterfox's pov. The account creator flag is essentially different from the right to use the ACC Tool Server interface - although I think the name accountsupercreator that Waterfox suggests might not be that appropriate. Wifione _.......^{Leave a message} 10:08, 10 October 2010 (UTC)[reply]
Another possibility would be not to rename the group, but put all people who have ACC access in the accountcreator group. — Waterfox 13:03, 10 October 2010 (UTC)[reply]

No! Perhaps a better idea would be to allow the account creator flag to remain the way it is. Rather, we should completely change the terminology we use to address the ACC team. In other words, rather than addressing ACC team members as account creators, we should call them user name request handlers; and the same even on the tool server interface. That should solve this whole issue once and for all. Because of this very issue, I had to create a new userbox for showing the ACC Tool Server usage right. Waterfox, whenever you wish, open up an RfC on this issue. Wifione _.......^{Leave a message} 15:38, 11 October 2010 (UTC)[reply]

Flag Option for Broken References

Instead of just removing broken references, I suggest the option to Flag broken reference links so future Wiki readers will be aware that the reference is not valid.

Reference Flags would appear (at least to viewers currently logged into a Wiki Account) as a small symbol by the Reference Number, in all locations that it is shown, to make its need for correction more obvious.

This Reference Flag could also be applied to statements still requiring references.

A particular statement or reference could be Flagged repeatedly and after a defined number of Flaggings, or when the conditions of a set algorithm are met, it could be changed to a higher grade Flagging. This would make that particular statement or reference more obvious to those in the Wiki community and thus more likely to be fixed/Edited. —Preceding unsigned comment added by RossCaleb (talk • contribs) 01:24, 10 October 2010 (UTC)[reply]

Other than the ability to repeatedly flag it, I don't see anything this does that the {{Dead link}} template doesn't do. —C.Fred (talk) 01:47, 10 October 2010 (UTC)[reply]

Community Sanctions noticeboard

Hi, there is currently a proposal at Wikipedia:Administrators' noticeboard#How to enforce that might involve reactivating WP:CSN, but as a community-run version of Arbitration Enforcement board. Input would be appreciated over there. Thanks, The Wordsmith^Communicate 01:53, 10 October 2010 (UTC)[reply]

Append welcome templates automatically to first talk posts on new editors talk pages

I often welcome editors. I also often see that editors have been "welcomed" by a spam, prod, image copyvio or AfD templates, or such, almost all the time those "welcomes" are automated and not personalized. This is problematic, as it 1) introduces the editor to the community in a rather scary way and 2) makes it less likely he will ever be properly welcomed. I know that there has been some objection to an automatic welcome bot, as not personal enough, but as things stand, a lot of editors are not welcomed for months or years, and others are welcomed by unfriendly warning templates. I'd like to propose that we consider a welcome bot again, or if it is still not acceptable, that most warning templates (listed above) would automatically transclude Template:Welcome in them if they are posted to new talk page (i.e. they create it). --_{Piotr Konieczny aka Prokonsul Piotrus| talk} 15:42, 10 October 2010 (UTC)[reply]

How would automatically including Template:Welcome at all solve the problem of other "welcomes" being automated and not personalized? Anomie ⚔ 15:48, 10 October 2010 (UTC)[reply]

Hmm... we already have some discussion about the value of the overwhelmingly warm welcome made automatically when making a first warning about some really blatant vandalism! I tend to manually delete it. --Kudpung (talk) 16:18, 10 October 2010 (UTC)[reply]

Porting videos from Khan Academy to Commons, and including them in articles

I'd like to get others' ideas on a large-scale porting of videos from Khan Academy (http://www.khanacademy.org/) to Wikimedia Commons and including those videos in relevant Wikipedia articles. The videos are freely licensed (CC-BY-SA-3.0) and thus compatible with Commons's licensing policy. There are a handful of KA videos already on Commons (see [1]). My idea is to get all KA videos onto Commons. Each video could be automatically tagged with at least one high-level category based on which section of the main KA page it is featured. Presumably, there are tools that could be used to programmatically transcode the videos into .ogv format -- this may be the biggest technical task. From a Wikipedia policy perspective, I could foresee an objection being made that directly including Khan Academy videos in Wikipedia articles runs afoul of WP:NOTTEXTBOOK; however, I think many of those videos are more informative than they are instructive. As an example, consider how including http://www.khanacademy.org/video/phases-of-meiosis?playlist=Biology into Meiosis#Phases would benefit that article. It seems that many other articles could benefit similarly. Emw (talk) 15:47, 10 October 2010 (UTC)[reply]

New edit filter?

A recent discussion at AN or ANI (can't remember which) noted that a vandal was redirecting multiple Today's Featured Articles to the same target page; as a result, a filter was created to prevent articles from being converted into redirects to that article. While this is potentially useful, I see a greater problem in the possibility of vandals redirecting featured articles: therefore, I'd like to propose a filter to prevent anyone other than autoconfirmed users from converting featured articles into redirects. EdoDodo, who put together the filter I mentioned above, suggests that producing such a filter wouldn't be hard, since the filter could check for the little {{Featured article}} that is meant to be displayed on all articles. I've proposed this because I can't imagine a good reason to convert a featured article into a redirect under any normal conditions. Nyttend (talk) 20:32, 10 October 2010 (UTC)[reply]

Seems reasonable to me. Maybe do that for GAs, too? /ƒETCH COMMS / 16:19, 11 October 2010 (UTC)[reply]

I've set up filter 365 to see what happens. -- zzuuzz ^(talk) 21:41, 11 October 2010 (UTC)[reply]

Looks like it's stopped 67 edits so far, and I don't see any false positives. Nyttend (talk) 18:52, 12 October 2010 (UTC)[reply]

Handy link. There have been a couple, as I'm still adjusting the parameters. It does a bit more than check for redirects, and Good Articles can still be subject to bold edits which we obviously don't want caught up in it. Another day or three to get some more data, and it should be OK to set to disallow. -- zzuuzz ^(talk) 19:06, 12 October 2010 (UTC)[reply]

Community-based discretionary sanctions proposal

Hello, I'm currently drafting a new, standardized community-based discretionary sanctions system, somewhat similar to Wikipedia:General sanctions (but, with approval, intended to supercede that system for future topic areas placed under probation). It is currently located at User:The Wordsmith/Community sanctions. Input would be appreciated in drafting a proposal ready for RFC. The Wordsmith^Communicate 16:35, 12 October 2010 (UTC)[reply]

[all-1] Includes IP users. Any permission granted to all users will be inherited by the other user groups.

[reg-2] Any permission granted to registered accounts will be inherited by the other (registered) user groups.

[other-3] Any user listed in this column has the relevant permission. Italics indicate a global permission.

[accountmerge-4] Irrelevant since the SUL finalisation in 2015 where all mergeable accounts were merged.

[GRP-5] Per Wikipedia:Global rights policy, Global rollbackers are only allowed to use this right in the context of counter-vandalism efforts.

[a]

[b]

[c]

[d]

[e]