Jump to content

Wikipedia:Village pump (proposals)/Archive 66

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Bot tagging of new articles

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus against implementing bot is shown; however, smarter tags may be implemented. Therefore, let's steer the conversation towards improving the tagging process. Later, we can re-evaluate the usefulness of the bot. THEMONO™ 23:29, 25 October 2010 (UTC)

I've proposed a bot that automatically tags new articles with cleanup tags. The tags include:

and are based on automatic assessments of the article, like:

  • If no articles link to the article Foo, then the bot tags it a {{Orphan}}


The bot will not tag articles for CSD, as they will likely be deleted. Additionally, the bot would process around 1,000 to 2,000 articles a day; many of those would be skipped. I'm told that this has been controversial in the past. THEMONO™ 16:47, 23 October 2010 (UTC)

Not a good idea, since this is biting newcomers. -- d'oh! [talk] 17:01, 23 October 2010 (UTC)
How would it "bite newcomers"? Articles are usually tagged anyway by a human or an AWBer (this is an AWB-based bot), and it is a net gain, because
  • the writer can work to address the concerns
  • we can identify what we need to do to articles

⅊™ 17:11, 23 October 2010 (UTC)

I doubt a experienced editor will create an article which warrants one of those tags. In fact most of the time those clean up tags are used when someone not knowing how Wikipedia/MediaWiki works creates an article, mainly by inexperienced editors, i.e. new comers. Its a problem when as soon as the new comer creates an article, the article is flooded with clean up tags it might scare them away which is a big problem for Wikipedia. I am not saying the articles shouldn't be tagged but caution should be used, e.g. a delay of a few hours/days before tagging will be a good idea to include, so articles with a harmless mistake, which have been or will be fixed by the newcomer or other editor, is not flooded with clean up tags. -- d'oh! [talk] 17:59, 23 October 2010 (UTC)

So facts to help discussion:


Strongly Oppose. For several reasons:

Have you ever sat through a movie with someone who works in the business? While you are enjoying the chase, they will be spooling the experience by trying to explain to you how good or bad some professional aspect of the filming techniques used which destroys the illusion that the film is trying to create. Wikipedia editors of an article often approach an article not from the aspect of a reader who has come to look for some information on a topic (similar to the ordinary member of a documentary audience), but like a professional film maker to see how the presentation of the documentary could be improved.

  • First the stub template covers all of this.
  • Second of all the example tags listed above are maintenance tags and their comments shoudl be directed to the talk page. The tags confuse what should be in article space and what should be on the talk page. What are the article talk pages for in not discussing editorial issues. One of the tags listed above is {{Dead end}} what possible reason can there be for putting the comment "This article needs more links to other articles to meet Wikipedia's quality standards." into article space and not onto the talk page? -- There are some templates like {{unreferenced}} that covers both a warning to the readers, and a maintenance part for editors that should be in article space but they are the exception to the rule, and the stub template on small stubs does that job as well.
  • Third if a article is a short stub, it does not look aesthetically pleasing to place dozens of lines of information which is not about the article overwhelming the article content.

-- PBS (talk) 20:23, 23 October 2010 (UTC)

Tags are on the articles for a reason. See here for why; that's been rejected. Not happening. The stub template does not cover this (stubs are articles deemed too short to provide encyclopedic coverage of a subject). Additionally, we have templates like {{Uncategorized stub}} because of this. Honestly, dozens of lines of information is not accurate either, as the bot collapses the templates into {{multiple issues}} and the bot only uses five tags. Remember, articles are a work in progress, and anything to help with that progress should be good. THEMONO™ 19:32, 24 October 2010 (UTC)
To the best of my knowledge there is no consensus on the use in maintenance tags in general in and whether they should be placed on the talk page or in article space. If there ever has been such a consensus either way I would be interested to see it. "Remember, articles are a work in progress" that is I think an example of the editor myopia I was talking about. Articles are there to inform a reader about a subject, that they are are also a work in progress is a secondary issue that can be discussed by those who want to develop the article on the talk page of the article. Why place editorial comments into article space when there is a better alternative? If a template is to be added to an article it should have information contained within it that informs the reader of a problem that they should be aware of. Eg {{unreferenced}} -- PBS (talk) 23:58, 24 October 2010 (UTC)
Take a look at Move maintenance tags to talk pages. The fact that moving them to talk pages is a classified as a perennial (rejected) proposal indicates consensus is to keep the tags on the article page. To quote the reasons for rejecting, "Every reader is a potential editor and the maintenance tags give potential editors ideas of how to improve an article." For that matter, they also help readers (at least, the knowledgeable ones) to identify articles that may be less reliable, sourced, or non-neutral. Qwyrxian (talk) 00:09, 25 October 2010 (UTC)
I had a look at Wikipedia:Perennial proposals#Move maintenance tags to talk pages and to the best of my knowledge you are misreading it (Something I am addressing on the talkpage). You are reading "Reasons for previous rejection:" as there has been a consensus for rejection, which is not what it means, what it means are here are some commonly voiced reasons why we should have maintiance templates in artile space, not that there has ever been a consensus for or against their use. The truth is that there is probably support for some specific templates on the article page like {{unreferenced}} which also act as warning for the general reader but little support for editor to editor communication such as {{Orphan}}. If you think I have mis-represented then please direct me to a conversation before 8 December 2008 when the text was added to the Wikipedia:Perennial proposals page-- PBS (talk) 05:40, 25 October 2010 (UTC)
  • Oppose Yes, yes cleanup tags point out errors... if we wanted to help new users, we'd make a bot that fixed pages, not tagged them. We don't need more tags. We need more fixing. I don't understand why people mass tag stuff with AWB anyway, other than to up the editcount. /ƒETCHCOMMS/ 01:52, 24 October 2010 (UTC)
Then let's improve the tagging process. Make it easier for editors to fix articles. The bot could also be set up to automatically fix errors (but it isn't, as that could create errors). The problem is many articles that were written were abandoned, and have tags slapped up, but the attention span of new users to the articles they created would drive them to improve. Tagging should lead to fixing, not abandonment. THEMONO™ 19:27, 24 October 2010 (UTC)
No! Let's improve the article improvement process. If you see an issue with an article, don't tag it. Fix it. Most new users don't know how to address those tags for the simple reason that those tags are essentially useless. Tagging leads to backlogs; nothing gets fixed. /ƒETCHCOMMS/ 22:57, 24 October 2010 (UTC)
I've started on a mockup of "helpful tags" at User:Mono/Sandbox/2. THEMONO™ 23:32, 24 October 2010 (UTC)
  • Oppose. There's already been bots in the past that go on these kinds of tagging sprees. I think I recall the orphan tagging bot got shot down after the first month because it attracted a lot of negative attention, and it made a lot of mistakes. Even if this proposal is meant for newly created articles only it would still probably be tripling the size of the backlogs, and that only serves to discourage those wikignomes that work on these maintenance categories. -- œ™ 02:03, 24 October 2010 (UTC)
I don't see how a well-coded orphan bot could make mistakes - the article is either linked or not. The bot also knows to remove tags that don't apply (helpful as well). Additionally, the bot is not constant, so it would process around 1,000 articles a day, and likely make 250-500 edits. THEMONO™ 19:27, 24 October 2010 (UTC)
  • Oppose - I agree with above, it is better if people fix articles than have a bot tag them. Also, an article with 5 templates stacked on top of eachother looks worse than an article with two sentences. Ajraddatz (Talk) 04:21, 24 October 2010 (UTC)
The goal here is not to stack tags (btw, we have {{multiple issues}} for that), but to allow users to improve their articles - many users may not know to link their article from others, etc. While experienced editors will recognize problems, how is a new user supposed to know? How about making our tags more friendly and helpful? THEMONO™ 19:27, 24 October 2010 (UTC)
Allow users to improve articles? Two scenarios: either the original author is long gone/doesn't care and the article is now just one out of 10,000 in a cleanup category, or the author has no clue how to fix the issue and gives up. An experienced article creator doesn't need tags to see what's wrong; a new user needs guidance, not useless, general tags. Oh, one might say, then fix the tags. Well, I might say back, don't add anymore of them until we improve the tags. /ƒETCHCOMMS/ 22:57, 24 October 2010 (UTC)
Well, then, let's improve the tags. THEMONO™ 23:32, 24 October 2010 (UTC)
The tags could use improvement, but how would one go about improving them? I really can't think of any positive changes that could be made :S - Maybe reducing their size? Ajraddatz (Talk) 02:03, 25 October 2010 (UTC)
I've started at User:Mono/Sandbox/2 (that's not done by a mile), but with some CSS we could hide the "tutorial" from experienced editors... THEMONO™ 02:10, 25 October 2010 (UTC)
Say "please add incoming links from other related Wikipedia articles to this article, and then remove the code {{orphan}}". Something very clear. But I didn't come hear to discuss improving tags. I just came here to voice my opposition to bot tagging right now. /ƒETCHCOMMS/ 04:23, 25 October 2010 (UTC)
  • Oppose It's not helpful. Tags do not solve any problems, particularly on new articles (apart from things like copyvio warnings). Rather than debate the theory, before proceeding with a bot proposal, please show ten examples of new articles where tags have helped. Manually adding tags may be helpful if the tagging editor watches the article and responds to attempts by the page creator to either fix the issues or to ask questions. Johnuniq (talk) 10:14, 25 October 2010 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"DISPLAYTITLE" magic word, and DAB titles

Idea Lab discussion
Moved from the Idea Lab
Hey. Currently, if we have two articles with the same title Article 1 with different topics, we disambiguate the headers as, for example, Article 1 (policy) and Article 1 (song).

On the other hand, we are blessed with {{DISPLAYTITLE}}, a magic word.

Why don't we clap our hands and integrate the DISPLAYTITLE in every article with a DAB-style title, to display only the main subject, in this case, Article 1.

Whats even more interesting is that we could add a feature in preferences (which is on by default) where any registered user can enable the display of both the real title Article 1 (song) and the triggered title Article 1. The only question is, where to display the real title (as what shows in the current title area is the triggered DISPLAYTITLE)? Rehman(+) 11:42, 17 October 2010 (UTC)

Can't be done. DISPLAYTITLE can only change the format (lowercase, italics), not the title itself; in other words, it cannot cut off parts of the title. Choyoołʼįįhí:Seb az86556 > haneʼ 11:56, 17 October 2010 (UTC)
Well, once upon time I did see someone partially hiding his/her username title, without doubt. But if you're sure it can't be done through DISPLAYTITLE, then it should be something else... Kind regards. Rehman(+) 12:40, 17 October 2010 (UTC)
{{DISPLAYTITLE:Part to be displayed<span style="display:none;"> Part to be hidden</span>}}. --Yair rand (talk) 13:16, 17 October 2010 (UTC)
There you have it! Right there! ;) Rehman(+) 14:35, 17 October 2010 (UTC)
Please don't do that. It makes it hard for someone to put in the correct link to the article ad could be quite confusing. Article names don't have to be definitive names for the topic, they are ways of finding the topic. Dmcq (talk) 17:13, 17 October 2010 (UTC)
I wasn't aware of that span-"hack". In any case, it would be confusing and cause more work when people link to the dab, and then someone else has to go fix it. Choyoołʼįįhí:Seb az86556 > haneʼ 22:44, 17 October 2010 (UTC)
Well, thats when the option in Special:Preference part come in handy; switching to the display of the actual Article 1 (song) title. The altered title would pretty much only be seen by IPs, as we could make the option to switch on by default for registered/logged-in users, as I said above. Rehman(+) 00:28, 18 October 2010 (UTC)
A working compromise might be doing this similarly to redirects: If you get redirected you see a helpful reminder that you have been e.g. "(Redirected from Elvis)". In the same vein, it could look like this:
Batman
Full name of this article: Batman (1989 film)
--Morn (talk) 17:57, 18 October 2010 (UTC)
  • Is displaying (eg) "Batman (1989 film)" really a terrible disservice to our readers, or just a vague "it could be tidier" issue? This seems in some ways to be a rather complicated solution in search of a problem... Shimgray | talk | 18:09, 18 October 2010 (UTC)
The parenthesized part of the title is only there for technical reasons and a good user interface should try to hide obscure implementation details. (That's why we have e.g. an article about "iTunes" instead of "ITunes".) As long as the full name stays within easy reach for linking, I think title simplification is a good idea. It conforms to the principle of least astonishment, because clicking the piped link ''[[Batman (1989 film)|Batman]]'' would take me to the title I expect to see. Of course power users glance at the status bar to know in advance to which page they are going, but everyone else probably does not. --Morn (talk) 19:33, 18 October 2010 (UTC)
That's a really bad idea I think. People need tags to organize information just as much as computers do. We just don't need the confusion of people not knowing how to refer to pages and mixing them up in their minds. It is better toi forgoaccuracy in order to get easy identification. For instance the name of the state described in the article Republic of Ireland is 'Ireland' and the name of the island described in Ireland is 'Ireland'. This sort of thing would lead to dreadful confusion when people refer to the article 'Ireland'. Dmcq (talk) 19:46, 18 October 2010 (UTC)
Nobody has proposed shortening a title like "Republic of Ireland"! This idea here is purely about the stuff we have to add to titles to make them unique in the wiki: "Republic of Ireland (1978 Portuguese movie directed by Martin Scorsese starring Bela Lugosi)", or somesuch. :-) --Morn (talk) 20:03, 18 October 2010 (UTC)
I think that's a valid idea for (info in brackets) but I what about doing something other than hiding the info altogether as it is usually important when a distinction can be made. A sub-title? ~ R.T.G 16:57, 20 October 2010 (UTC)
This discussion

Hi. I propose the use of the {{DISPLAYTITLE}} magic word to hide unnecessary dab-style titles (such as "Article 1 (song)" to "Article 1"). Please see the original discussion above; copied from the Idea Lab. Rehman(+) 07:41, 24 October 2010 (UTC)

Strongest Possible Oppose Page titles and URLs should match. This proposal would complicate the creation of wikilinks and even just telling someone which page to go to. If I read "X" as the article title and tell someone to go to "X" on Wikipedia, it should take them straight there; this would break that. The disambiguation is also helpful for readers. Was I referring to the article on the video game or the the band? Guess now I'll have to inspect the URL instead of the much more obvious and friendly page title. I should be able to tell at a moment's notice even on a mobile browser which sense page a link has sent me to. --Cybercobra (talk) 08:54, 24 October 2010 (UTC)
This. → ROUX ₪ 09:00, 24 October 2010 (UTC)

I don't think the disambiguating information should be hidden completely, but it would be a great help if we could present it as a subtitle, rather than as part of the title. That would help (to some extent) resolve a lot of silly arguments about how to name articles - for example (to take a current example), both the city and the state could have their articles titled "New York", and both could have a disambiguating subtitle (a lot less ugly and intrusive than the bracketed disambiguators that have to be in large type as part of the title). This idea was proposed a few(?) weeks ago and was generally quite well supported (it was even shown how it could work with a template).--Kotniski (talk) 10:25, 24 October 2010 (UTC)

Btw, I never said that disambiguating information should be hidden. ;) Rehman(+) 12:01, 24 October 2010 (UTC)
If you interpret the above as well-supported, I repeat myself: bad idea. Choyoołʼįįhí:Seb az86556 > haneʼ 11:59, 24 October 2010 (UTC)
It was well supported when it was proposed before, and when it was made clearer that the disambiguating information would still appear (but in smaller/different type). All the objections seem to be based on the premise that it wouldn't be visible at all.--Kotniski (talk) 18:06, 24 October 2010 (UTC)

Having an additional subheader would be cluttering, imo. Especially if the reader arrives at the target via a redirect, they'll have the "From Wikipedia, the free encyclopedia" subheader, the redirect, and this proposed subheader. The design drafted above by Morn is definitely appealing:

Batman
Full name of this article: Batman (1989 film)

But in practice, it would be more like this:

Batman
From Wikipedia, the free encyclopedia
Full name of this article: Batman (1989 film)
  (Redirected from Batman (1989 movie))

So not a perfect idea. HTH. -- Quiddity (talk) 20:12, 24 October 2010 (UTC)

How about this?
Batman (1989 film)
--Yair rand (talk) 20:20, 24 October 2010 (UTC)
Interesting. That might be workable. However, it's a fairly major style change.
I'd recommend setting up a separate draft page, with
  1. a multitude of examples of how various titles would be changed by this – (for easy before&after comparison, and for analysis of any potentially problematic instances)
  2. using the exact sizing of the existing elements – (I've changed the 2 drafts above to reflect the 188% H1 title size),
  3. settling upon a firm "suggested size and color" for the new proposed suffix change – (the current gray is possibly not dark enough, and the size possibly not large enough, for easy legibility)
so that an unhurried design can be agreed upon, and then a formal RfC can take place. HTH. -- Quiddity (talk) 21:13, 24 October 2010 (UTC)
Interesting indeed, but the title should not be bold, the disambiguation part should be black and at least be larger then normal text. Here's a H1/H4 combo example:
Batman (1989 film)
Or only change the color of the disambiguation part:
Batman (1989 film)
But yeah, setting up a draft page is a good idea. — Edokter • Talk • 23:39, 24 October 2010 (UTC)
Now this I would be fine with. --Cybercobra (talk) 01:00, 25 October 2010 (UTC)
I've fixed the bold in the earlier examples, and fixed the gray in Edokter's 2nd example. -- Quiddity (talk) 01:57, 25 October 2010 (UTC)
I know you can't read it, but see nv:Ndilkal (chʼil). Choyoołʼįįhí:Seb az86556 > haneʼ 02:23, 25 October 2010 (UTC)
Interesting. Any idea how that is done? — Edokter • Talk • 11:10, 25 October 2010 (UTC)

Interesting proposal, not sure I support it. I'm concerned about how however the software would handle pages like Voodoo Child (Slight Return), which is the correct title. Headbomb {talk / contribs / physics / books} 03:56, 25 October 2010 (UTC)

This has to be done by manually inserting a template on every applicable page. Choyoołʼįįhí:Seb az86556 > haneʼ 03:59, 25 October 2010 (UTC)
Yes, but then that creates a very ugly situation where similar articles have page titles displaying with striking dissimilarity. Some of the articles will have these tags, and others won't because no one bothered to add them yet, making the whole thing look very inconsistent. Therefore very strong oppose. Headbomb {talk / contribs / physics / books} 06:31, 25 October 2010 (UTC)
I guess that was my point from the beginning... I'm still against it on this three-million-pages-ten-thousand-plus-users deal; it's gonna be a mess. Just saying... Choyoołʼįįhí:Seb az86556 > haneʼ 06:33, 25 October 2010 (UTC)
That's a pretty poor argument - we should never change anything because there will inevitably be inconsistency during the time the change is being carried out. But once the changeover is complete, that won't matter any more (and the interim effects can be mitigated by doing the change in thematic batches).--Kotniski (talk) 08:24, 25 October 2010 (UTC)
It wasn't an argument, it was a warning. Choyoołʼįįhí:Seb az86556 > haneʼ 10:21, 25 October 2010 (UTC)
This should ideally be done by MediaWiki by changing the font of the (dab) part, or assigning a CSS class to it. — Edokter • Talk • 10:58, 25 October 2010 (UTC)
Yes, if we could get the developers interested in treatment of page titles, all sorts of things might be achieved (I've always wondered why dabbing has to be done by hand, for example - and wouldn't it be good to have these hatnotes telling you what else you might be looking for not only generated automatically, but also tailored to how the user actually got to the page?) But as noted above, there would have to be a way of making an exception for those occasional titles that do have a bracketed part as part of the name, not a disambiguator.--Kotniski (talk) 11:31, 25 October 2010 (UTC)
It is technically possible (but you have to use a display=none tag around the bit you don't want displayed).--Kotniski (talk) 13:00, 25 October 2010 (UTC)
Not a good example, since the title is now governed by the infobox template. Here's a working example. Strangly, it only work 100% when viewing using the next link in the previous revision. Clicking the revision directly in the history loses the color somehow. Strike that; that works too, as long as it is not the last revision. It also does not work in preview, which is an issue. Strike that, it does work in preview, at least in the sandbox. — Edokter • Talk • 13:15, 25 October 2010 (UTC)
Why change the colour why not just make it smaller in text as shown in one of the Batman (titles) above? ~ R.T.G 13:21, 25 October 2010 (UTC)
That is a matter of taste, that is why draft page with all examples is needed so we can come to a consensus. — Edokter • Talk • 13:24, 25 October 2010 (UTC)

I have to agree with the opposers. I think this would really confuse people, especially with regards to disambiguation, especially with those not familiar with WP in general. –MuZemike 18:11, 25 October 2010 (UTC)

I don't understand why it would confuse people. Because:

1. I do not propose hiding the dab part.

2. The display of the dab part is always on by default to all registered users (as per my proposal), and will only be hidden to IPs... Rehman(+) 00:28, 26 October 2010 (UTC)

IMDb does the same thing (at least since their redesign; I don't know if this was different before) and I haven't heard reports of anyone being confused by it:
Unhappily Ever After (TV Series 1995–1999)
That there is so much controversy about this simple change explains why Wikipedia is always a little backwards in its user interface decisions. Apparently we always need a usability study first to figure out the painfully obvious improvements that everybody else is already using. --Morn (talk) 20:53, 25 October 2010 (UTC)
I think the "oppose" commenters are still addressing the apparent original proposal to remove disambiguating information altogether. It's hard to see how putting the disambiguators in smaller type could confuse people - quite the reverse, as it would allow us to make clear what we consider to be the "name" (in the usual Wikipedia sense, i.e. the common name in good sources) and what information we are adding purely to distinguish it from other topics with the same name.--Kotniski (talk) 07:49, 26 October 2010 (UTC)
Then perhaps the original proposal should be updated to reflect the fact that complete removal of disambig info from the page is out of the question. Making the text smaller and less obtrusive is the good idea here, not removing it entirely. --Morn (talk) 13:48, 26 October 2010 (UTC)

Synopsis: A potential style change for disambiguated titles. For example:

Benchmark (surveying)

Please see WP:VPR/Styling disambiguated titles where a draft page has been set up.

I've copied across the discussion from above, to the talkpage there. Please help analyze and consider this idea further. Find us more examples to ponder upon. Once firmer conclusions have been reached there, we can bring it to a more formal RfC, here or VPT or elsewhere. Hope that helps. -- Quiddity (talk) 22:51, 26 October 2010 (UTC)

When I clicked on the link in this article meant to lead to Ultra Records official website (www.ultrarecords.com) I was redirected to Wait a minute! This is important - we check your device, which is a scareware web page ([1]). I had to switch my internet connection off to be able to close this site.

After reading several articles about Wait a minute! This is important - we check your device I initially thought that this is a problem with my computer rather then the website, but: 1) Google states www.ultrarecords.com as a malicios website ([2]); 2) I am redirected to Wait a minute! This is important - we check your device only from ultrarecords.com; 3) I have not found on my computer any of Wait a minute! This is important - we check your device's files suggeested by spyware-db.com (but I am not an expert - maybe they are hidden and I don't know how to uncover them).

The fact I am unsure is the first reason why have I not deleted the two links on the Ultra Records article immediately - the other one is that I was afraid that if I just remove the links it would be threaten as vandalism, and the links would be soon restored.

Sorry for any mistakes (I am not native to English),

Marcgal (talk) 09:22, 24 October 2010 (UTC)

Every result from Google indicates that this is a problem with your browser, not the site. Get a better virus checker. → ROUX ₪ 09:26, 24 October 2010 (UTC)
Uh no, Google actually has this site blacklisted. — Edokter • Talk • 10:34, 24 October 2010 (UTC)
Uh, yes. The Google search given by the OP -- I assume you clicked on it -- showed that this specific problem is the result of viral infection. → ROUX ₪ 10:42, 24 October 2010 (UTC)
Yes, the site is infected; it will try and install mallware on your computer. I asume you clicked my link? — Edokter • Talk • 10:52, 24 October 2010 (UTC)
Of course I did. However, as I said above, the specific problem which was raised by the OP is a local viral infection according to the link he himself posted. Please reread that before snarking further. → ROUX ₪ 10:58, 24 October 2010 (UTC)
That does not warrant you telling OP to get a better virusscanner. The problem is not that OP is infected; the problem is that ultrarecords.com will try to install that particular malware on anyone's computer; and that problem warrants a warning, which is what OP is trying to tell us. I have put a warning link pointing to Google's analysis page on the article. — Edokter • Talk • 11:06, 24 October 2010 (UTC)
My FireFox blocked it as a G10, er, no, an attack page. Access Denied [FATAL ERROR] 02:27, 25 October 2010 (UTC)
This looks like a break-in to a legit site, rather than a hostile site. "ultrarecords.com" is a legitimate company. I tried McAfee SiteAdvisor, which checks for hostile content, and they don't report any problems. StopBadware reports that they were on and off their list twice in the last two days. (I also ran the domain through Sitetruth.com, which reports that they share a street address with the Communist Party of the United States, which they do; they're in the same office building.) So put a time limit on their block. --John Nagle (talk) 05:43, 27 October 2010 (UTC)

Archiving bots adding comments

Currently, H3llBot has been leaving <!-- Bot retrieved archive --> next to archived links. This includes uses of |archiveurl= parameter and {{Wayback}} template. This is done because there is no manual verification of the content. The archived version is only retrieved within 6 months of the original access date, but even so, the actual archived content may differ from the cited material. The comment helps identify the fact that the archived copies are retrieved without human intervention; similar to how <!-- Bot retrieved title --> is placed.

A comment has been made to me that this shouldn't be done, so I'm bringing this up here. Should bots that add archived copy links also post a comment specifying that this is an automatically retrieved link? —  HELLKNOWZ  ▎TALK 12:40, 27 October 2010 (UTC)

Tutorials for admins on conflict resolution etc.

  • I started a thread on Jimbo's talk here; he replied with a general affirmation of support (disagreeing with the suggestion of video format). Here's full text of my original post:

The question of civility, civility police, etc etc is a festering sore in the admin/non-admin dynamic, especially with respect to edit wars etc. My position is kinda painted here. My suggest is this: break open that wallet, boy! Hire some conflict resolution consultants to produce some sort of... I am out of my area of expertise here, but.. some sort of Internet accessible.. video series? I have no idea what format, but something that admins can watch and interact with, to train them on conflict management. Maybe even regular IRC seminars? Maybe some police department somewhere has resources..? Maybe you can even get this kinda thing free from some Wikipedian whose real-life job is in a similar kind of consultancy..? Train those admins; help them to be all that they can be. Tks.

Proposal to modify implementation of Template:Reflist

There is a proposal at Template talk:Reflist to modify the implementation of Template:Reflist. This change would have the template set widths for columns, rather than fixing a column count. This causes improved display on particularly large or small screens, while keeping things essentially the same for most users. This does not affect the syntax of the template and keeps the same browser compatibility. The proposal is being announced here because of the large number of uses of the template. Please comment on the template talk page. Thanks, — Carl (CBM · talk) 19:18, 29 October 2010 (UTC)

Make the edit window taller

As per title. I feel like I'm editing in a dam letterbox and constantly have to scroll up and down, even just for section editing. Make it settable as a user preference (e.g. to n number of lines in height), but also increase the default value for all users by about 1/3 over the current default. Regards. Zunaid 10:56, 30 October 2010 (UTC)

Strong support. The short box is quite annoying. And the user preference is a good idea. Rehman(+) 11:01, 30 October 2010 (UTC)
Support - I think making it an adjustable user preference is a great idea. Mlpearc powwow 11:14, 30 October 2010 (UTC)
Comment. Isn't it what preferences/editing/sizeofeditingwindow is for? East of Borschov 11:24, 30 October 2010 (UTC)
Comment Please look in your preferences, it already is user configurable.... —TheDJ (talk • contribs) 11:34, 30 October 2010 (UTC)
But "Widen the edit box to fill the entire screen" option doesn't make the edit box taller, does it (it doesn't for me)? Rehman(+) 11:44, 30 October 2010 (UTC)
Special:Preferences -> Editing -> Size of editing window works fine for me. Does it fail for you, or give undesirable/unexpected results? bobrayner (talk) 11:48, 30 October 2010 (UTC)
Oh that... Yeah that works for me... *closes windows in embarrassment* Rehman(+) 11:51, 30 October 2010 (UTC)

Oops!!! Man that's embarrassing! (I'm now editing this in a box that's 50 rows tall; I'm drowning in whitespace :P). Proposal amended accordingly on behalf of our IP users. Zunaid 05:58, 31 October 2010 (UTC)

indentation the craigslist forums way

indented lists can be made using either * or :
I suggest a third option.
One that produces an indented list similar to what you see on craigslist forums.
http://sfbay.craigslist.org/forums/?forumID=96&mode=night
where each level of indentation addes ":.."

sfo Why are cigarettes still available in the US whn < scientific-studies-have > 10/30/10 12:27
: . . population control < - > 10/30/10 12:32
: . . : . . *_chem trails_* § < - > 10/30/10 12:33
: . . reliable tax revenue? § < toober > 10/30/10 12:39
: . . Why do grays always post stupid questions? § < Witchgrl > 10/30/10 12:51 -3+5
: . . : . . why does that question confuse you § < ?-- > 10/30/10 13:18
: . . : . . : . . There is no confusion. < Witchgrl > 10/30/10 13:23
: . . : . . : . . : . . that's only because more people consume fast foo < d-not-because > 10/30/10 13:29
: . . You're kidding, of course! < Mug-Wump > 10/30/10 13:12
: . . : . . because there's enough science to support that < peoples-best-interest > 10/30/10 13:28
: . . : . . : . . There are NO benefits from smoking... < Mug-Wump > 10/30/10 13:34
: . . : . . : . . : . . not sure about that. i think fewer people are < reliant-upon-nicotine > 10/30/10 13:38
: . . : . . : . . : . . Well, nicotine has some beneficial effects. < Achernar > 10/30/10 13:39 link
: . . Prohibition (learn history) < hazduel > 10/30/10 13:44
: . . : . . youre not making any sense. Sun is a fact of lif § < cigarettes-are-not > 10/30/10 13:56
: . . The real question of your post is if government < DaleT > 10/30/10 13:48
: . . : . . the underlying issue is when one person's behavi < ior-impacts-the > 10/30/10 13:55



this makes it easier to see which post is being responded to.
this would be very useful for long lists with many levels of indentation
perhaps this could be made an option for one of the already existing ways of making lists (: and *)
by using <span class="something">
Just granpa (talk) 21:18, 30 October 2010 (UTC)

See WP:LiquidThreads, coming real soon, maybe. -- Quiddity (talk) 21:21, 30 October 2010 (UTC)
That sounds like a really good idea. But I was hoping to use the indentation on article pages too.Just granpa (talk for an example) 22:04, 30 October 2010 (UTC)

You could also use good 'ol CSS, just as they have implemented over at the French Wikipedia (see fr:Discussion Wikipédia:Accueil principal). –MuZemike 23:31, 30 October 2010 (UTC)

I don't like the craigslist way, but I am using the frwiki way and it rocks. I just wish enwp would adapt that way. /ƒETCHCOMMS/ 02:06, 31 October 2010 (UTC)

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)

There is a template {{od}} Access Denied [FATAL ERROR] 15:46, 9 October 2010 (UTC)
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)
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)
This looks pretty damn ugly. Access Denied [FATAL ERROR] 19:27, 9 October 2010 (UTC)
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)
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)
For me LiquidThreads would be a huge improvement on discussion pages, and I am happy to know it is being tested to be introduced in en.wiki. Access Denied: Misunderstanding of policies notwithstanding, given the outcome of your last attempt to gauge community consensus on interfaces, I would be careful before saying "unwanted by nearly everyone" .--Cyclopiatalk 17:40, 15 October 2010 (UTC)
Agreed that LQT would be an improvement. What sold me on it was the flexible post ordering. I've always considered it a major drawback that discussions go stale and unanswered and ultimately archived and forgotten about. With LQT, replying to a post brings it right to the top again. The ability to watchlist individual threads is another major selling point. -- Ϫ 23:01, 16 October 2010 (UTC)
Would it still be possible for me to have a normal talkpage if LQT was added. Also, I want new messages at the bottom, not top. Access Denied [FATAL ERROR] 23:15, 16 October 2010 (UTC)
Since this seems to be becoming some kind of vote on liquid threads: I was confronted with them over at the strategy wiki and found them extremely confusing. The main problem was that my sense of quasi-geographical orientation in the wiki and its pages broke down completely with the watchlist substitute they have implemented for liquid threads. Threads move around and appear in different places. Then suddenly a thread disappears after I have confirmed that I read it. I think even threads from different talk pages appear on the same page together, with no connection but that I have commented in them at some point and they all got new comments since I last read them. This even got confusing at that mini wiki, where I only ever commented on two pages or so. Maybe it's just stupid default settings or something, but the only chance I see for introducing something like that to the English Wikipedia is through tricks such as initially only converting ANI to liquid threads, which would be reasonable because initially it would at least halve the number of posts.Hans Adler 23:24, 16 October 2010 (UTC)
Well we all have our different tastes I guess. I don't think we'll ever get clear consensus on LQT though, it seems to be split pretty evenly down the line amongst most users. -- Ϫ 04:59, 17 October 2010 (UTC)
…which shows LQT needs more work in the area of usability. --Morn (talk) 14:42, 18 October 2010 (UTC)
Unlike wikithreads, LiquidThreads are configurable to suit the tastes of the individual user. If you sort threads in ascending order by creation time they don't "move around" unexpectedly (I personally prefer the default LQ sort order though). Dcoetzee 11:03, 25 October 2010 (UTC)

There are other usability problems such as giving users the ability to edit the posts of others, that diffs cannot be used to read all new posts on a page, and the general waste of vertical screen space. Talk pages are a bit cumbersome to edit but quite efficient. LQT simply do not match them yet and probably never will, unless there is a major development effort. Still, for pages mainly used by non-editors such as the proposed article discussion forums, LQT might be ideal. --Morn (talk) 14:37, 25 October 2010 (UTC)

I gotta agree with Access denied above. In the example he gives of liquid threads, the messages look completely unrelated, whereas here, indented messages are clearly related to the ones above. Also the outdent is so simple to use, though in my experience of this page not many ppl are aware of its existance. MarkDask 07:38, 31 October 2010 (UTC)

User right modifications

I think that the Reviewer user right should be automatically bundled with the rollback user right because users who are given rollback are obviously trusted enough. Both user rights complement each other, when a rollbacker rolls back edits identified as vandalism on a PC protected page that reversion needs to be reviewed adding a little more unneeded work for existing reviewers. That said for the newer users who are experienced enough for reviewer but not rollback, the reviewer right should also remain separate. Thoughts? —Ғяіᴆaз'§Đøøм • Champagne? • 7:18pm • 08:18, 14 October 2010 (UTC)

It would be easier just to keep it as it is. If the rollbacker wants reviewer, they can apply at WP:PERM. WikiCopter (radio • sorties • images • shot down) 23:36, 14 October 2010 (UTC)
Seems to work in concept, just I have no idea how hard it would be to do that (doesn't seem too hard). Derild4921☼ 23:54, 14 October 2010 (UTC)
It might be time to consider a 'bundled rights' usergroup containing the rights of confirmed, rollback, reviewer, autopatrolled, accountcreator (discussed in brief here), as well as suppressredirect (proposed to be offered to users here) and apihighlimits (a userright that is helpful for AWB users who need to build large lists). –xenotalk 00:09, 15 October 2010 (UTC)
move-subpages as well. –xenotalk 13:20, 15 October 2010 (UTC)
I support a bundled rights group, suppressredirect is a definite must have. —Ғяіᴆaз'§Đøøм • Champagne? • 8:12pm • 09:12, 15 October 2010 (UTC)
I think the reviewer right was handed out far too indiscriminately and that's why I don't bother working there. It's less important than, say, NPP or RCP, where the patrollers don't need any quals at all! We can't revoke it now, and to include confirmed, rollback, reviewer, autopatrolled, accountcreator with it would cheapen those privileges.--Kudpung (talk) 10:13, 15 October 2010 (UTC)
To be clear, my suggestion was to create a new userright, not roll existing userrights together. As far as your statement; I'm not sure how an ability that all users previously had can be handed out "far too indiscriminately". Prior to pending change, every user had the ability to review anonymous changes (passively - by not undoing them). –xenotalk 12:54, 15 October 2010 (UTC)
Definitely support something along the lines of this "bundled rights" proposal. There are certain rights that would greatly assist my contributions, but I don't crave the mop and I don't want to jump through those hoops just to get them. PC78 (talk) 21:08, 15 October 2010 (UTC)

So to be clear I was proposing a separate user right, if all the existing non-admin user rights were bundled it'd cause on-wiki chaos. Suppressredirect would definitely be a plus for most editors, leaving redirects from unused pages to a highly used and highly visible page is pointless and adds unneeded work for admins when they delete such redirects. apihighlimits should be put in a separate AWB for those that use it regularly, this and other individual bits that would help AWB users. —Ғяіᴆaз'§Đøøм • Champagne? • 2:35pm • 03:35, 16 October 2010 (UTC)

So, I'd make names here.
  • Patroller (in want of a better name, would most likely be admin-given with consensus) = suppressredirect, Reviewer, Rollbacker, Autopatrolled, move-subpages
  • Flooder = apihighlimits, bot
Comment. Frozen Windwant to be chilly? 20:43, 16 October 2010 (UTC)
I don't think you understand what apihighlimits and/or bot are for. Killiondude (talk) 19:34, 17 October 2010 (UTC)
I know that: apihighlimits increase result limits from 500 to 5000, and bot hides edits from the normal recent changes, but if you turn on "Show bots" it shows them. Frozen Windwant to be chilly? 21:34, 17 October 2010 (UTC)
I don't see the need to split them up, and I don't agree giving 'bot' to non-automated editors. –xenotalk 13:17, 18 October 2010 (UTC)
Bot should definitely be limited to, well, bots. Apihighlimits, if at all, should only go out on a case-by-case basis to editors that can demonstrate a need for it. The "patroller" bundle sounds workable, though.--Fyre2387 (talk • contribs) 18:38, 18 October 2010 (UTC)
Right now it's not possible to assign apihighlimits outside of the botgroup, which is why I figured it would be best tucked into a bundle. –xenotalk 18:44, 18 October 2010 (UTC)
apihighlimits could be assigned to another usergroup easily though. I don't like the idea of accountcreator being given out to those not in the ACC bit, but bundling reviewer and rollback would be good. What would also be nice is to see a new group specifically for apihighlimits, grantable by anyone above autoconfirmed/confirmed (ie, rollbackers could grant it). I don't see any real danger imposed by this, as people who know what it does/how to use it should understand the issues, and those who don't understand and try to play will probably not figure out what it's for. Just my $0.02. [stwalkerster|talk] 01:22, 19 October 2010 (UTC)

The Patroller bundle is a good idea IMO, though if implemented I'd say that flagging a user as a Patroller should be done sparingly and not liberally as some of those user rights can be abused, eg. creating unreferenced BLPs, rollbacking in edit wars and so forth. Though I agree with Stwalkerster, the Account Creator flag should not be given to users who aren't at all involved with ACC. —Ғяіᴆaз'§Đøøм • Champagne? • 4:13pm • 05:13, 20 October 2010 (UTC)

I think the Patroller right bundle is a very good idea. The suppress redirect flag would be particularly useful moving misplaced Articles for Creation submissions. That way it doesn't leave a redirect from Mainspace to the Wikipedia namespace. It would also be quite useful for undoing page move vandalism. I'm not to keen on the auto-patrolled flag being added to the bundle. That would require the user to have created a suggested 75 articles. I believe there should be standards to receive the tool, however I do not believe the standards to receive the bundle should be greater than a RFA. Maybe a minimum of 3,000 edits, 20 appropriate page moves, proper understanding and use of reliable sources and other policy i.e. creating very few or no unreferenced/inappropriate articles. This is just a rough suggestion though. --Alpha Quadrant talk 14:33, 20 October 2010 (UTC)
Should we start a straw poll? —Ғяіᴆaз'§Đøøм • Champagne? • 11:46am • 00:46, 24 October 2010 (UTC)
No. The community did not find consensus at the last discussion I initiated over this same topic a couple of months ago. A straw poll now wouldn't help, because polls are usually evil. /ƒETCHCOMMS/ 18:03, 25 October 2010 (UTC)
Polls are generally evil, ok that I can't disagree with. These rights would, however, benefit most users. Suppress redirect is useful for those active in AfC, apihighlimits is useful for those who use AWB frequently. It worked at English Wikinews, what's to say it won't work on English Wikipedia? —Ғяіᴆaз'§Đøøм • Champagne? • 7:33pm • 08:33, 26 October 2010 (UTC)

Also I think that creating a new user right that allows users to move files would be a good idea, this right would only be given to users who meet some criteria of some sort, eg. OTRS volunteer etc. —Ғяіᴆaз'§Đøøм • Champagne? • 11:28am • 00:28, 30 October 2010 (UTC)

Personally, I am wary of bundling; I think the benefits of having some granularity in who-is-allowed-to-do-what outweigh the benefits of assigning multiple rights in one go.
At worst, if you bundled together the abilities to do multiple diverse things, then many wikipedians would naturally insist on stricter vetting, to ensure that a candidate can be trusted with all the abilities, even when the candidate only actually wants one of the abilities. Think of the drama that would ensue! ;-)
The idea of a new right to move files, though, sounds interesting. Are there any possible drawbacks?
bobrayner (talk) 08:27, 30 October 2010 (UTC)

I think reviewer, rollbacker, suppressredirect, and move-subpages should be combined. Autopatrolled and acc (if it survives the discussion above) should remain separate as they serve users with different focuses. (vandalism fighting vs content creation vs "user relations")— Train2104 (talk • contribs • count) 18:06, 31 October 2010 (UTC)

SVG with thumb or frameless

This is what should happen when "thumb" or "frameless" is used with SVGs.

Usually when "thumb" or "frameless" is used with a image the width default (220px) or editor's width preference is used for the width of the image, but if the image is smaller than those widths the image width is used instead. When SVGs is used with "thumb" or "frameless" and the SVG is smaller than the width default (mostly 220px), the width of the SVG is used: Although this is correct to do for other images, this is incorrect for SVGs since this goes against what SVG is designed to do, which is to scale. So I propose the image checks should be skipped when dealing with SVGs. -- d'oh! [talk] 15:21, 30 October 2010 (UTC)

Icons are unlikely to be linked as common images anyway, they are always located within a stub or flag template or similar, which is the one to add them into the article. If someone tries to do so directly, such as in "robots in fiction are usually like this one" the image would surely be meant to be shown at this higher size. MBelgrano (talk) 14:21, 31 October 2010 (UTC)
bugzilla:19633. I have a patch for it, but haven't had time to discuss this with others yet. —TheDJ (talk • contribs) 14:24, 31 October 2010 (UTC)
Now implemented, but will take a few months before you can enjoy it here :D —TheDJ (talk • contribs) 22:13, 31 October 2010 (UTC)

TorNodeBot

Hello all, I wanted to raise a note to indicate that an admin bot I developed a while ago, TorNodeBot is up for approval again. This bot was previously approved for trial but then withdrawn by me as the need for it seemed to go away. I'm reopening the approval in response to the recent abuse of Tor that is not being picked up by the TorBlock extension. Any community input is most appreciated. The discussion for approval is at Wikipedia:Bots/Requests for approval/TorNodeBot 2. Thanks, Shirik (Questions or Comments?) 18:18, 31 October 2010 (UTC)

Reverting past SineBot - a suggestion

I have no idea if this is technically possible - but could rollback be tweaked to ignore User:SineBot when reverting? i.e. cause rollback to revert SineBot *and* the preceding edit that it signed at the same time? This might be useful when reverting talkpage vandalism (I'm sure that admins and rollbackers have experienced rollback failures at least once due to a SineBot edit occurring between noticing the vandalism on the watchlist and clicking 'rollback'). Just a minor issue - but something that might be useful (I've been meaning to mention this for a while, actually)... --Kurt Shaped Box (talk) 00:53, 1 November 2010 (UTC)

Twinkle rollback will correctly revert both SineBot and the edit prior to that. Doing that with the normal rollback that's a part of the wikisoftware would be both expensive and fragile, unfortunately. — Gavia immer (talk) 01:28, 1 November 2010 (UTC)
Ah, I did not know Twinkle could do that. Sounds quite useful. Reach Out to the Truth 04:16, 1 November 2010 (UTC)

improve reference-desk section header titles when archived

Let's encourage wikipedians to go into the reference-desk archives and improve the section headers to better reflect the content of the questions. That way, when people type questions into google, they will be more likely to find reference-desk entries that reflect their questions. (For example, the reference-desk often sees headers along the lines of "A question about fishing" but the first sentence will be, "What is the best place to go fishing in Arkansas?" When Wikipidians stumble across "A question about fishing" as a header in the archives, they should revise it to approximates the first sentence, "What is the best place to go fishing in Arkansas?".)

Here my specific proposed implementation.
(1) Whenever a reference-desk page is automatically archived, the archiving bot should automatically supply an {{anchor}} template below the header containing the title of the original header. That way, we don't destroy permalinks to the original header.
(2) It should be our policy to encourage Wikipedians to go into the reference-desk archives and modify the section headers of questions so that those headers better reflect the content of the questions.

Thoughts? user:Agradman editing from the IP address 128.59.179.127 (talk) 07:08, 31 October 2010 (UTC)

Why wait until it is archived? Fix the heading immediately if it is vague. Anomie⚔ 14:48, 31 October 2010 (UTC)
That's great too, but there are thousands of archived questions. Usually, our policy is to not edit archived pages, and that's why I'm proposing a change to existing policy. AGradman / talk / how the subject page looked when I made this edit 16:23, 1 November 2010 (UTC)
Support: There are good reasons why we usually try to avoid editing archives and other people's comments. However, in this case I think those objections would be outweighed by the benefits of easier reference. Rumour has it that wikipedia is an encylopaedia... :-)
Why do we usually avoid editing archives? Because people don't read them or because it may misrepresent what was happening at the time? Well, that's not an issue here. Similarly, there's a stigma to editing other people's comments, but that's because misrepresenting other people or twisting their words is very bad. In this case I think the change is clearly intended to support the author's original intent.
However, it may be difficult getting enough volunteer-hours - for a relatively boring job wading through archives. Editing the header text to make it more accurate/useful is not a bot-able task. bobrayner (talk) 16:40, 1 November 2010 (UTC)
You may want to solicit opinions at Wikipedia talk:Reference Desk. Many RD regulars are fanatically opposed to any editing of others' posts, including fixing useless section headings and correcting obvious typos and errors. Staecker (talk) 16:28, 2 November 2010 (UTC)
Comment In what way is it Orwellian to amend opaque headings to make them more informative and hence to improve searches of the archives? I don't remember anything like that in 1984; quite the opposite, in fact. bobrayner (talk) 22:26, 2 November 2010 (UTC)
Editing archives means they are not archives of actual discussions, but discussions which are still in play. Why bother archiving? Corvus cornixtalk 22:58, 2 November 2010 (UTC)
They were "archived" because the questions were answered at the time. The proposal is to change some headers which would make searching easier, to improve help for future visitors. If you have a fixed definition of the word "archive" which is incompatible with fixing headers in this way, that leaves only four options:
  • (a) change the name to something else instead of "archive";
  • (b) refuse to help people, if one implication of the help is incompatible with a label we applied to things we did when we were less helpful;
  • (c) cast pedantry aside;
  • (d) stop archiving.
Either A, C, or D would be fine with me, though things might start looking messy a month after choosing option D. bobrayner (talk) 03:28, 3 November 2010 (UTC)

I'm not sure if this is a perrenial issue but I could not find it elsewhere. I think that any links to an external website, that have the "external website" logo (such as this link: Google.com) should open in a new brower window or tab. That's all I wanted to say.

The reasons are pretty simple:

  • The user will likely use the external link not as a destination but rather as a reference: they will visit the site to add to their understanding of the content on the wikipedia article. This means that after obtaining information from the external source, they will probably want to return to wikipedia to continue reading the article. This is much easier to do if the new source of information (the external link) is a new window, and not replacing the original article's browser space.
  • As far as my understanding goes, the icon currently used for external links means "This link opens a new window" in other contexts, so it's a bit confusing that wikipedia uses this same icon. See this image search for "Open in a new window" icons - berban
This is an option via user preferences. You will need to create an account to do so. → ROUX ₪ 18:02, 1 November 2010 (UTC)
I understand but doesn't it seem that this behavior should be on by default, and disabled in user preferences? - berban
I don't see any reason why. The default in HTML is not to have links open in new windows/tabs; click on any ten random links anywhere online, and I am willing to bet 8 of them open in the current window. Just register an account and you can set the preference as you please. → ROUX ₪ 18:10, 1 November 2010 (UTC)
Every browser that has tabs has an easy way to open links in a new tab. Typically Ctrl-click or clicking with the center mouse button. However if a link is designed to always open in a new tab, I'm not aware of a quick way to override this. Forcing it to open in a new window might also set off overzealous popup blockers. Mr.Z-man 18:15, 1 November 2010 (UTC)
Personally, I think the sage Mr.Z-man made a good point; if a reader usually has a trivially easy option to open in a new window/tab when the normal link behaviour is to reuse the same window/tab, but not vice versa, I think etiquette would preclude us forcing new windows when most of the internet doesn't. If the the reader wants a new window, they can do it for themselves easily. bobrayner (talk) 12:59, 2 November 2010 (UTC)

Changing "Did you know"

Current proposals at Wikipedia talk:Did you know#Changing DYK:

  • Proposal 1: Slowing down the output rate
  • Proposal 2: More transparent logs
  • Proposal 3: introduce some GA DYKs

Uncle G (talk) 22:17, 1 November 2010 (UTC)

Discuss these

Have note when editing references section

From my time on the help desk, I noticed that a lot of people, especially new users, have trouble editing references because they are trying to edit the "References" section, which only contains {{Reflist}}. Do we want to have a note for those editing this section which says that references need to be edited where they are used in the text? -- Bk314159 (Talk to me and find out what I've done) 13:54, 24 October 2010 (UTC)

There have also been quite a few recently who end up posting an {{editprotected}} request on Template talk:Reflist and on Template talk:Citation needed. I wonder if we should make MediaWiki:Protectedpagetext somehow conditional on this sort of template to say "Go back to the article and make your edit there" instead of offering the easy-to-abuse button, maybe something like this. Anomie⚔ 15:36, 24 October 2010 (UTC)
It's a bit more complicated. If you are using WP:LDR, then the reference is in the reference section, with a small piece up in the main section. While most new editors won't be using LDR, let's be careful about a note which is not universally true.--SPhilbrickT 21:51, 27 October 2010 (UTC)
LDR or not, this is never the correct place to try to edit. But people keep trying anyway. Anomie⚔ 22:53, 27 October 2010 (UTC)
This sounds like a great idea with no obvious downsides, and a relatively simple one to implement too, but discussion seems to have died out. Why? Alzarian16 (talk) 13:08, 3 November 2010 (UTC)
I also think it's a great idea. New editors who care about sources are like gold dust, but the current mechanism is rather counterintuitive; they'll try to edit the references section and may find baffling emptiness.
Template talk:Reflist has this header:
But I'd much rather address the issue at source. bobrayner (talk) 16:03, 3 November 2010 (UTC)

Citation junk

The lead in the Physics article has too many citations. I propose banning citations from the lead as a guideline. Arlen22 (talk) 14:45, 3 November 2010 (UTC)

See WP:LEADCITE. ---— Gadget850 (Ed) talk 16:14, 3 November 2010 (UTC)

In order to create a new article, it must have one Citation or External link, a "Proof of existence" reference, let's call it. Opinions?----occono (talk) 14:22, 1 November 2010 (UTC)

Are you thinking of an automatic mechanism? It won't work, because WP:CITE allows any style of citation, and automation cannot detect all styles of citation. Jc3s5h (talk) 14:26, 1 November 2010 (UTC)
Yes, that was my idea. Hmm, never mind then, I guess. Thanks for the reply.
Just as a matter of curiosity, what style of citation are you thinking would be undetectable? Something like a manually added footnote and number? - Pointillist (talk) 15:03, 4 November 2010 (UTC)
I've seen new editors use all kinds of novel citations. For instance, something that looks like a Harvardesque citation (or part of one), with (John Doe, "History of blah blah", 1991) inline. It would be very difficult to automate detection of all possible variants, and I don't want to bite people who are making a genuine effort to create sourced articles. bobrayner (talk) 15:47, 4 November 2010 (UTC)
Other examples of valid citations are all articles about books and films, which implicitly cite the book or film that is the subject of the article. Jc3s5h (talk) 16:00, 4 November 2010 (UTC)
Well, no-one wants to be BITEy but it would be helpful to encourage article creators to get the hang of referencing sooner rather than later. How about if the (bot?) message to the creator was couched in helpful terms, something like "Thanks for contributing the new article Whateveritwas. I couldn't detect any references to outside sources in the article, perhaps because I didn't recognize the way they were formatted. If you would like help with this, or any other aspect of sourcing, please see Wikipedia:Citing sources." The fiction MoS and film MoS both ask for secondary sources, so ignoring the implicit citation of the source work needn't be an exception. - Pointillist (talk) 17:06, 4 November 2010 (UTC)
It is wrong for bots to criticize correct articles. Articles that use parenthetical referencing are one example of fully correct articles that can't be detected by a bot. You should abandon your idea. Jc3s5h (talk) 17:13, 4 November 2010 (UTC)
Personally, I would be happy with a bot sending a friendly reminder to people who have created apparently-unreferenced articles, if the rules are drawn sufficiently generously to include anything that looks parenthetical (more generally: rules generous enough that false-positives will be rare). But that would require somebody to write a bot. If there isn't already one technically capable of that task. bobrayner (talk) 17:45, 4 November 2010 (UTC)
A less offensive alternative to a bot might be a filter tag on Special:Newpages to flag possibly unreferenced pages ...a proportion of false positives wouldn't matter in that context (with parenthetical referencing the filter could accept a section named "Notes", "References," "Bibliography," or "Works cited" as evidence of references). Another step would be for new page patrollers to post {{Uw-refimprove}} onto the creator's talk page whenever they flag a new article as unreferenced. BTW, it's not really my idea—I was just intrigued by the possibilities (or impossibilities) of making citations easier and the referencing culture more widespread, and so this caught my eye. Thanks anyway - Pointillist (talk) 17:59, 4 November 2010 (UTC)

(od)WP:Twinkle has a "notify if possible" box for Prodding. It could perhaps do a similar thing with {{Uw-refimprove}} to the article creator when tagging a page as unreferenced. Rd232 talk 18:05, 4 November 2010 (UTC)

Large scale update

Per Wikipedia:Requests_for_arbitration/Betacommand_2#Community-imposed_restrictions I need to post a notice here, my plans are to mass update external links/references that use IP addresses and replace it with the actual domain name, one example: [3]. The main reason to do this is that IP addresses change while domain names don't. ΔT The only constant 18:49, 2 November 2010 (UTC)

Don't suppose you could check for "no longer in cache" messages while you're at it? Because if you're just replacing one set of dead links with another set of dead links, this isn't going to help much.--SarekOfVulcan (talk) 19:14, 2 November 2010 (UTC)
Do you have an example of a "Not in cache"? also they may or may not be dead links, Im just converting them to hostnames to prevent breaking if/when the servers get a new IP address. This may or may not be just google either. The first I ran across was google. ΔT The only constant 19:26, 2 November 2010 (UTC)
Umm, the exact example you gave is the example I have. I fixed one of them, but didn't chase down the other yet. --SarekOfVulcan (talk) 19:27, 2 November 2010 (UTC)
If its dead, and used in a reference Ill tag it with {{dead link}} see [4] for another example. ΔT The only constant 20:05, 2 November 2010 (UTC)
Thanks, that'll be helpful going forward. Do the two links in your first example meet your criteria for tagging?--SarekOfVulcan (talk) 20:09, 2 November 2010 (UTC)
Moved it to a sandbox to show full details, since you requested more than I was initially going to do, Im going to throw it through all my general cleanup fixes, see [5] for what that would have been. ΔT The only constant 20:18, 2 November 2010 (UTC)
You broke the third link by changing it from the IP to google.com. I'd suggest this might not be the best automated run to do at the moment. --SarekOfVulcan (talk) 20:22, 2 November 2010 (UTC)
Which one? The third one, India 1993 works for me. ΔT The only constant 20:26, 2 November 2010 (UTC)
And now it works for me too. Weird. Sorry about that. --SarekOfVulcan (talk) 20:30, 2 November 2010 (UTC)
Ok, then, if it works, why the deadlink template? --SarekOfVulcan (talk) 20:32, 2 November 2010 (UTC)
I F*sking hate google, So durring the process to figure out what the issues are google blocks my ip address from the cache servers..... Im not sure if it was a temporary issue or exactly what the problem was, it could have been the same thing that your experiencing with intermittent google failure. ΔT The only constant 20:52, 2 November 2010 (UTC)
  • Support - And while we're at it, ditch the editing restrictions too. It has been over two years since they were imposed, they are now pointless and unconstructive. --Alpha Quadrant talk 19:28, 2 November 2010 (UTC)
  • Should we be using Google cache links in articles at all? Anomie⚔ 20:19, 2 November 2010 (UTC)
    • personally I dont think so, I think all IP based URLs should be added to the WP:SBL but thats another debate for the wiki to solve, My goal is just to convert the IPs to domainnames before they break and we cant figure out where they point to. ΔT The only constant 20:22, 2 November 2010 (UTC)
      • Google cache links do not seem like a good idea to me, but it's possible that somebody had a good reason for using one so I'd be wary of ruling them all out automatically. (Since using a google cache link generally takes an extra step beyond using the native URL and is non-obvious; there must have been some reason why the editor chose to do that) bobrayner (talk) 03:07, 3 November 2010 (UTC)
  • My only concern with doing this full-scale is for IP addresses that may have already changed hands and, thus, point to irrelevant websites. Changing the IP to a domain name won't fix it, nor will making sure it's not a dead link. — The Hand That Feeds You:Bite 21:03, 2 November 2010 (UTC)
  • The above comment is the only major problem I can think of. Although I do not think it is that major. If the IP has a different domain now, then it points to the wrong web-site anyway. One way or another, it is dead, so might as well replace occasional false positives with a domain name and in turn fix hundreds of valid links. I support this, although I do think a mark-up comment about this being automatically converted should be placed. —  HELLKNOWZ  ▎TALK 21:16, 2 November 2010 (UTC)
    • Following the reply above, I've clarified with the editor that he manually verifies several links of the same IP and makes sure they point to the right location and then automatically replaces the remaining occurances of this IP. So no issues I can see at all then. —  HELLKNOWZ  ▎TALK 21:38, 2 November 2010 (UTC)

Image annotator

I'd like to invite the comments for this proposal. It was implemented on German Wikipedia, and I believe it should be implemented on English wikipedia too.--Mbz1 (talk) 16:30, 3 November 2010 (UTC)

Image annotations are already available through Preferences → Gadgets → Browsing gadgets. If you're proposing to turn annotations on for everyone, I would oppose that, as I have before. — Gavia immer (talk) 19:38, 4 November 2010 (UTC)

Reader engagement with regard to image maps

An image map is an image, with a linked overlay (kind of cool). However, they might go unnoticed — would anyone support an {{Image map}} tag, similar in style to this? ǝɥʇM0N0 02:54, 5 November 2010 (UTC)

Forum

Moved from WT:Contact us § Forum

Hello. I wanted to contact someone involved with wikipedia about the discussion tab in the articles. Ive been posting sections in the tabs and people have been getting onto me cause Im not saying the "right" things. They say "This is NOT a forum. This is about the article only." Ok. So why cant their be some kind of forum tab on each article like the discussion tab but where people can REALLY talk about the subject without having to worry about saying the wrong things or getting told off by wikipurists. Seriously if there was just a "Forum" tab to the right of the "Discussion" tab, there would be alot more freedom to "discuss" the topic. I hope this gets to the right people. Cathys Son (talk) 21:52, 19 October 2010 (UTC)

See WP:NOT#FORUM. Wikipedia is an encyclopedia project. There are several forums around the internet that are for dicussion of a general topic. A quick search should something up. Try searching google and using the discussions option in the side bar. --nn123645 (talk) 15:13, 20 October 2010 (UTC)
The proposal of Cathys Son is exactly to weaken WP:NOT#FORUM, and to allow such more free discussions on an additional, dedicated talk page.
That would create several problems, but it would also have one advantage: More people actively editing Wikipedia pages, and it's likely that some of them will start making constructive edits to articles. Amalthea 15:28, 20 October 2010 (UTC)
Indeed, I wonder if a forum-type system would help foster the community. We sometimes complain about needing fresh blood; perhaps this would be a good way of getting people involved? Wikinews has a Comments namespace in addition to the Talk namespace; the former is used for discussion of the subject (chit-chat), while the latter is for discussion of the article (editing-oriented), and it seems to have worked out fairly well for them. I'll admit that there have been times where I've wished to discuss the topic of an article, not just the article itself; after all, Wikipedia allows people to find like-minded people about whatever niche subject you're interested in. It's not encyclopedic editing per se, but still, getting people more actively participating in Wikipedia isn't a bad thing. EVula // talk // ☯ // 15:51, 20 October 2010 (UTC)
I know over at Wikinews they have the Opinion namespace. I kind of worry opening something like that up on wikipedia might encourage a myspacey type of atmosphere by non-editors. I think what you'd see is high profile articles being heavily commented on, with pretty much everything else going by the way side. One major issue would be adherance to policies like WP:CIVIL and WP:NPA from readers on controversial articles, like Abortion and Isreali-Palentinian conflict. --nn123645 (talk) 16:13, 20 October 2010 (UTC)
I imagine many people will bring up old issues like WP:Esperanza and stuff like that. I think it probably won't happen, mainly, I think, because opinions can often get heated and will cause admins to bitch about having to do extra work they didn't 'sign up' for, etc. In other words, I agree that on the one hand I do agree that chatting about topics outside of framework of the article isn't necessarily a bad idea, but on the other I would imagine that it just won't work for various reasons. ♫ Melodia Chaconne ♫ (talk) 16:16, 20 October 2010 (UTC)
Topics that are known to be controversial (not least because of edit warring in the article) could be excluded from having a forum, e.g. the major religions, evolution, intelligent design, abortion, same-sex marriage, etc. But articles about scientific concepts, persons, books, films, languages, music, countries, hobbies, and everything else that is relatively uncontroversial might benefit from discussion forums. It would also be a good opportunity for some larger-scale usability testing of Liquid Threads. Just do it like Google: tag the new feature clearly as Beta and make it clear to everyone that it can be yanked anytime without notice if problems develop. --Morn (talk) 16:44, 20 October 2010 (UTC)
That brings up the issue of WP:NOT#CENSORED. Redirecting the Forum page to the talk page would likely be confusing to readers while putting a notice that such issues are not acceptable to dicuss might draw hostility, or have people just ignore the notice and discuss it on the talk page. Generally it is much easier to add something than it is to get it removed, and it is likely to be something which would stick around with us indefinately, much like the Image: namespace. Mediawiki was never really designed to be a forum and as mentioned by Melodia that brings up problems with standard forum features, such as locking a thread, being nonexistant. Liquid threads is an improvement, but ultimately it is a hack to try to fix what should have been included in Mediawiki from the beginning. --nn123645 (talk) 01:57, 21 October 2010 (UTC)

Agree or disagree, I really appreciate the feedback. I understand that this is an encyclopedia site, and not a forum site. But people come here for information. If they dont find what theyre looking for in the article, how could they ask without being continuously corrected for asking a simple question. Again, this IS an encyclopedia site but most people come to THIS SITE to get answers, not some forum site. Cathys Son (talk) 19:14, 20 October 2010 (UTC)

That is exactly why we have the reference desks. Usually wikipedians are more than willing to help newcomers, we even have a policy about it (WP:BITE). What WP:NOT#FORUM is about is more discussing things that are totally unrelated to the article. For instance if you were to discuss how cute the color of <actor/singer/general famous person x>'s hair is (which on an article like Justian Beber I'd imagine that you'd get alot of) that would be a forumish type of discussion that would be inappropiate for the talk page. --nn123645 (talk) 19:40, 20 October 2010 (UTC)

Whether new users understand wikipedias policies or not, isnt the point Im trying to make. Im saying that users should be able to talk about the subject freely. Maybe it would be nice for fans to talk about how cute Justin Beibers hair is on this site, keeping it off the record, off the "Discussion" section and off the article. (FYI: Not a fan) Cathys Son (talk) 20:18, 20 October 2010 (UTC)

The point is that WP is not the place for that. A lot of things "would be nice", but there's plenty of places online for "users able to talk about the subject freely" for the majority of topics. ♫ Melodia Chaconne ♫ (talk) 22:35, 20 October 2010 (UTC)
Anathea and Evula have a point: allowing this type of things may help in bringing in new users, that would eventually become editors, and the project will always need new hands. I suggest to avoid staying in "policy does not allow it" or "this is not the place" just by mere conservatism, and discuss instead which would be the potencial problems with this proposal --MBelgrano (talk) 23:02, 20 October 2010 (UTC)
Well, it's not so much being conservative as it is looking at the pros and cons combined with knowing what the current situation is. I woul;d agree that it's quite possible something like this may bring in people, and there's certainly plenty of topics I wouldn't mind seeing interesting conversation on that I either wouldn't seek out otherwise or wouldn't expect any response to, but consider something else -- with the openness of WP it'd be so easy for people to control the pages and piss people off, even more than in normal talk pages. Considering the type of flame wars that happen on places like Gamefaqs, with its censor filter (you can't even use, say, 'Hancock' in a topic title) and sometimes heavy handed mods, a forum where ANYONE can 'delete' a post (even though it can be restored), or say "discussion's closed, shut up" (to paraphrase), etc etc...well it may be a lot more trouble than it's worth. Plus, again I add the issue of admins being forced (at least in their minds, noone's REALLY forced to do anything on WP) to play moderator, when it's not what they 'signed up' for. People have enough trouble being civil to each other when talking about the encyclopedia, it'd get far far worse if people are free to ignore that requirement, I'd imagine. ♫ Melodia Chaconne ♫ (talk) 00:20, 21 October 2010 (UTC)
And I can think of many more problems; for example, WP:BLP applies to all namespaces, so we'd have to patrol forums for BLP violations; but if BLP applied to a forum, I can't think of how someone could possibly express an opinion about a living person. And I would be quite opposed to allowing the forums to not follow BLP rules; I can't even imagine the hassle of trying to develop a secondary set of conduct rules appropriate to only to the forums. Also, we'd end up having discussions migrating back and forth between Talk and Forum, and it would get confusing (say, Forum gets an unsubstantiated rumor, then it goes over to Talk for inclusion in the article, then it's rejected, then maybe a source comes, so it's back....blah blah blah). Finally, we'd be massively increasing server usage for something that really isn't part of our mission--we're here to collect the world's "knowledge" (whatever that is), not chat. And I'm not so sure it would even accomplish the idea of bringing in new users, as we don't just want "new users," we want new users willing to work within our guidelines. I can easily imagine people starting to "chat" on the forums, then trying to move their "chat" into the article, only to have to be taught how that isn't allowed, then they get bitter and angry; they'll get extra bitter when other information does legitimately migrate from forum to talk to article, because it is sourced (they won't see the distinction, however). Finally, forums would, in many cases, become places to develop bad faith editing cabals.
tl:dr:It's not we do, and I don't even think they'll achieve the goals others have said they might be useful for. Qwyrxian (talk) 01:11, 21 October 2010 (UTC)

Ok. ANYONE and EVERYONE with access to the internet can edit an article and post things in the "Discussion" tab. With that ease of access to editing, wouldnt members of forums and message boards come over to this site anyway and post what they want to post? If they were going to? Especially if theyre not even registered users, anyone can post anything in the "Discussion" tab. And if they REALLY wanted to, they could turn the "Discussion" section into some kind of forum. Ive seen it on many articles. People are going to say what they want anyway, why can't there be a section for that very purpose? Cathys Son (talk) 01:50, 21 October 2010 (UTC)

We are not talking about what people could do, we are talking about what is allowed under policy. The same can be said of the mainspace and vandalism. By the same logic we should create a Vandalism: namespace just because it is technically possible to post something not in adherence with content policies. Just because there are no technical restrictions preventing you from doing something doesn't mean it's okay to do (see Don't Delete the Main Page). Mediawiki is open with very little technical restrictions by design. People who are continuely disruptive and make bad faith edits ignoring policy are likely to find themselves blocked and their edits reverted (see WP:DE and WP:GAME). You know I think we could steal apple's slogan, "There's a policy for that". --nn123645 (talk) 08:15, 21 October 2010 (UTC)

This is a well meaning, but ultimately detrimental proposal. Largely because it undermines the idea of verifiability. An argument above is that it might bring more contributors; which would rock. But my concern is that such contributors would be here to discuss their own view of articles (which they are entitled to of course) and we risk a ground swell of OR and opinion going into articles based on "forum" type talk. --Errant [tmorton166] (chat!) 09:42, 21 October 2010 (UTC)

That's why a rollout should start with more highbrow articles. A forum about e.g. the Well-Tempered Clavier would be more useful to WP than one about Justin Bieber. The latter already has dedicated forums elsewhere, while a more specific topic like the former does not. The kind of articles that are opened for forum discussion would largely determine what kind of contributors (and article contributions) we attract. --Morn (talk) 10:22, 21 October 2010 (UTC)
If I may propose a new project wikiforum.org, although how to integrate it into existing projects would need to be decided. 930913 (Congratulate/Complaints) 12:21, 25 October 2010 (UTC)

As someone who ([| unknowingly ]) probably contravened wiki policy in this regard, I am in total agreement with the proposal to attach a forum to each wiki page. One of the biggest advantages would be making it easier to exchange ideas instead of concentrating on format, adding special characters, proper indentation, and positioning everything just perfectly so that the machines would understand what we are trying to accomplish. Just my $.02 Ottawahitech (talk) 11:44, 1 November 2010 (UTC)

Discussion

  • Real strong support: Wikipedia is quite a popular site in general. To be more precise, one of the top ten most visited websites on the internet. I always wanted to propose a new wiki (yes you read right, new wiki) at Incubator to actually start up a forum website as part of the network of sites owned by Wikimedia Foundation. But I never found enough reasons of why it would succeed, (the above proposal will actually kill my plan of starting it).

    Cathys puts up a very good point on the fact that, even at present, a large number of editors from outside and inside Wikipedia do posts things on the talkpage that are quite off the article scope. Adding a "Forum" tab would not only eventually make Wikimedia Foundation the conquer in online forums (as it is for online encyclopedias), it would also attract a large number of more people of which a significant percentage of whom could be good editors.

    For now, the main issue in the above proposal is that, if you add a "Forum" page, and also follow "the free encyclopedia" policy (where anyone including IP's can edit), then I'd say Wikipedia will also rocket into the top ten spam sites. To overcome this issue, we could disable/hide the forums for users who are not logged in.

    If for any reason, community decision is to never allow a fully fledged online forum to develop alongside the encyclopedia, but to allow forums just for the minor Wikipedia community (no offence of any kind meant there), then we could implement a two-week maturity period and about a 100-edit requirement before forums could be enabled for the respective editor, just to avoid people registering just for forums.

    Either way, I definitely support forums. Rehman(+) 12:34, 1 November 2010 (UTC)

  • Oppose - for a wide variety of reasons. BLP is a big one; forum pages would need to be patrolled to ensure there are no BLP violations (they're bad enough on article talk pages as it is). We don't have enough admins to handle that. Next is the concern about arguments in general; discussions here get heated enough when talking about article content. Open that up to discussion about anything even vaguely related to the topic, and suddenly we have a hornet's nest requiring constant moderation (all forums online require moderation; look at /b/ for an example of an unmoderated forum style), and we don't have enough admins to handle moderation duties. Even if moderation duties weren't an admin-only function, that simply opens up a whole other set of problems: who gets to be a moderator? How are they chosen? The last thing we need is yet another RFA-style hellhole. To say nothing of the inevitable interminable arguments about how to define the scope of a forum, what is and is not on-topic, and "waaaah you deleted my post" nonsense. Further, having editors moderate forums takes time and energy away from the whole reason this place exists. Spam is also an obvious concern, and again, we simply do not have enough admins to tackle that problem. I find arguments indicating that forums will attract more editors unpersuasive; more likely we will attract to the forums people who want to talk on forums. If you want to create forums related to Wikipedia, your best two options are either to fork the database to your own domain and have forums to your hearts' content, or use any of the many forum software packages out there to create your own wherever you like. The bottom line, however, is simple: Wikipedia is an encyclopedia, and anything which detracts from that purpose is simply not a good idea. We have a narrow scope for a reason: it provides focus. Softening that focus is a net detriment to the project. → ROUX ₪ 12:47, 1 November 2010 (UTC)
You definitely have a strong point there, no doubt. But the thing is, as I recalled what Cathys said in my comment above, talkpages are already somethat turning into forums, and RecentChanges dudes don't seem to keep up in reviewing all the IP comments. And this will only get worse, Wikipedia is growing.

On the WP:BLP issue, I don't know how far it's possible but, maybe we should put out an idea to the Foundation on creating a new policy on Forums? That contents are not monitored, bla, bla, bla? We already have WP:NOTCENSORED, so swearings and stuff like that might not be that of an issue, although we should restrict any sort of image displays there as it would boost copyright violations uploads and many other issues. In the mean time, forum could also function like "Discussions" as you see on Facebook (where you can post a topic and have comments in it), or just one mega stream of comments (which I don't think anyone would like). We also could add a universal "Report" button, where users could report inappropriate comments to one ForumCenter of some sort, (this way, the users call the admins when needed, rather than the admin being there always). We could maybe base it on LiquidThreads? Rehman(+) 13:11, 1 November 2010 (UTC)

(edit conflict)I don't understand; you say the problem will only get worse, so let's provide an arena to speed that up? That makes no sense. The WMF directive on BLP is, I suspect, unlikely to change or be relaxed for any sites under WMF purview, for very good reasons. Talk to MGodwin if you would like a definitive response; he is WMF legal counsel. Who would cover this ForumCenter you propose? The admins we already don't have enough of? The potential mods whose selection would raise a whole new set of problems? Any way you slice it, the idea of forums increases admin responsibilities without increasing the number of admins, or quasi-admin moderators (who would need the ability to block users from editing anyway, meaning they'd need to be admins). → ROUX ₪ 13:19, 1 November 2010 (UTC)
Well, this is in fact a proposal, meaning its still not implemented. So yes, this proposal will increase the workload, like any other new development. "Lack of admins" or "Inefficient admins" should be dealt with somewhere other than this discussion. Rehman(+) 13:32, 1 November 2010 (UTC)
Insufficient admins is a hurdle you need to get over before this proposal (which I oppose anyway) could get off the ground. You need to address the increased workload and how it will be dealt with. → ROUX ₪ 13:38, 1 November 2010 (UTC)
Well as almost all of the "forum like" discussion I have seen has been disruptive/abusive etc. I don't see it as a sustainable thing to encourage. Particularly as it would require entirely different rules from a normal talk page (to allow proper "moderation"). We already have enough trouble with POV on talk pages, why encourage it! --Errant [tmorton166] (chat!) 13:14, 1 November 2010 (UTC)
Well lets just say, to get good, we have to free the evil a bit. We should consider new policies if forums are ever to be implemented. Rehman(+) 13:32, 1 November 2010 (UTC)
This is not a statement that makes any sense; "we had to destroy the village to save it." → ROUX ₪ 13:38, 1 November 2010 (UTC)
I'm not quite sure I see Rehman's observation that talkpages are "turning into" forums. If anything, forum-type questions/discussions are less than they used to be. I'll grant I don't watch really popular pages most of the time, but I often watch the FA of the day (and keep it watched) and pretty much never see it there. Half the time when such questions/comment ARE added to stuff I'm watching they are deleted as off topic anyway (without further complaint). ♫ Melodia Chaconne ♫ (talk) 13:43, 1 November 2010 (UTC)

If limited observers and controversial subjects are an issue, we could limit the amount of articles that have the forum feature. If articles were run through or voted as an appropriate article to have the feature, they will have it. If theyre sensitive subjects such as religion or abortion, it will only have the "Discussion" tab. Cathys Son (talk) 03:19, 2 November 2010 (UTC)

And who decides which articles should have fora? And how? I think, and I say this without being insulting, you must be very new around here, and thus unfamiliar with the truly mindbogglingly insane things that Wikipedia editors will find to fight over. (See WP:LAME for some excellent examples). This entire proposal brings a host of new or exacerbated problems without displaying any kind of net benefit. → ROUX ₪ 03:23, 2 November 2010 (UTC)

In Wikia there is a forum namespace, but because forums generally deal with the subject matter of the respective Wikia, they're a bit more manageable. A bit. Even then, I think it's a bit too much of a distraction...they're too readily abused by random commenters. It takes time and resources to maintain a forum, and I'm not sure it would be the best thing in the end. bibliomaniac15 03:37, 2 November 2010 (UTC)

Ok. "Distracting" from what? The article? When its a forum specifically on that subject? I don't see how a forum would make random commenting any worse than it already is. Seeing as how anyone would still have the same freedom of doing so, with or without a forum. A forum would not distract from the goal of editing the article, then again, that wouldnt be the main purpose of a forum. The forum would be a whole seperate section. As someone said before, there are many forums on the internet covering many subjects. Thousands upon thousands of forums and forum based sites on the internet. Im sure many moderators that do THOSE SAME forums would be more than glad to work on a forum on Wikipedia. What would be so hard about doing it here? Cathys Son (talk) 17:44, 2 November 2010 (UTC)

We're kind of getting to the point where you're just not listening to what we are telling you. You're really not demonstrating any kind of net benefit to Wikipedia from this proposal, and you're certainly not showing how it isn't in direct contravention of why we're here, and what we do. Can you please respond directly to the points which are actually being made as to why this a) won't work, and b) is totally against policy and mission? → ROUX ₪ 17:49, 2 November 2010 (UTC)

Theres no reason a forum "won't work". Im not even sure what you mean by that. The only benefit of having a forum is for users to speak about the subject freely. It seems to me that the only reason this idea "won't work" is because of the policies it breaks. Im ignoring these policies because I want this particular feature to not have those bounderies. Thats been my goal this whole time. Cathys Son (talk) 18:28, 2 November 2010 (UTC)

There are plenty of reasons, actually. I've enumerated several, and you have yet to show how those problems could be overcome. → ROUX ₪ 18:29, 2 November 2010 (UTC)

Is there a way you could list these problems, without addressing policies? Cathys Son (talk) 19:05, 2 November 2010 (UTC)

Read my comments above. And no, I am not going to ignore policies; you need to demonstrate that there is a net benefit in changing policy in order to add the forum capability. You can't just handwave them away. The living persons policy is the most important one you need to address, and cannot under any circumstances be ignored; it is a directive from the Wikimedia Foundation. → ROUX ₪ 19:09, 2 November 2010 (UTC)

This would be the idea of approving articles to have the feature. Articles that cross to any of the suggested boundaries in BLP, would not be allowed to have a forum. Cathys Son (talk) 02:13, 3 November 2010 (UTC)

I think you have missed the point... let's take, oh, Oprah Winfrey. Everybody loves Oprah. How do you propose to deal with people violating BLP in the forum about her article? Or the forum about starfish? How do you suggest, with millions of articles, we decide which articles get fora and which don't? How do you address and overcome the whole reason we're here, as well as why we're not here (especially this bit)? How do you suggest we find and pick moderators (hint: you can't just ask random moderators from other websites to come do it; they have their own headaches to worry about and, if they're not already Wikipedians, won't understand Wikipedia culture)? How do you suggest we give moderators the power to delete and block? How do you suggest we deal with spam? ...and oh, I've just looked at your contributions. I'd made the mistake of thinking you were acting in good faith here; it turns out you just want to be able to use Wikipedia as a forum after being told you weren't allowed to. I see no reason to entertain this further. → ROUX ₪ 11:58, 3 November 2010 (UTC)
Roux, I don't think it's anywhere near correct for you to comment "I'd made the mistake of thinking you were acting in good faith here; it turns out you just want to be able to use Wikipedia as a forum after being told you weren't allowed to. I see no reason to entertain this further". Please remember to be civil. The things that other users say about Cathys doesn't a bit change the freedom s/he has in running this proposal. With respect. Rehman(+) 12:41, 3 November 2010 (UTC)
This has nothing to do with that other people said about Cathys; look at the contribs: Cathys has tried to use more than one article talkpage as a forum, and has been told it's not allowed. And reacted poorly when told so. This entire proposal is, in essence "I wanna change everything so I can do what I want," and not any attempt to actually improve the encyclopedia. → ROUX ₪ 13:04, 3 November 2010 (UTC)
  • Oppose, with a shortage of good admins to police, these forums is a disaster waiting to happen. -- d'oh! [talk] 12:39, 3 November 2010 (UTC)
  • Real strong support: The reason I believe that Wikipedia should add a discussion forum to each of its pages is that it will provide an essential service which currently does not exist anywhere else in a centralized form, and by doing so may help build up the ranks of Wikipedians. Think about all the people who are, for example, dissatisfied with the post office. Wouldn’t it be nice for them to congregate in one spot and exchange “horror” stories? Or people whose house is being foreclosed? Or those who had a bad experience dealing with an airline? – and on and on. Yes, there will be false reports, but there are many UNMODERATED forums in existence where people participate in discussion and do so in a civilized and productive atmosphere. Of course it would help if everyone gets their say, including the representatives of the Post Office, bank, airline or who have you. Some institutions may even appreciate the opportunity to hear what their customers have to say in public instead of dealing with each individual complaint separately behind closed doors. Ottawahitech (talk) 19:49, 5 November 2010 (UTC)
  • The forum page would be convenient for the editors who want to discuss the associated topic, but this has little to nothing to do with improving the encyclopaedia itself. There are too few topics that attract genuine, stimulating discussions; and I don't think WP needs more space to argue. I rather see people stop shoving WP:NOTFORUM and assume some good faith when one is starting or responding to less than relevant discussions. —  HELLKNOWZ  ▎TALK 13:36, 3 November 2010 (UTC)


A majority of those "contributions" are from when I started my username (when I was 13). The last "contribution" is what influenced me to suggest my idea on here (and no, I didn't act very mature about the situation). I don't need to change everything to do what I want, I can do/say anything regardless (As you can see in my last contribution). I agree with the above post. I believe that certain people make a hobby out of correcting people on here and with a forum where they wouldnt have that power, they wouldn't have much to do. And we can't have that now, can we? Cathys Son (talk) 15:01, 3 November 2010 (UTC)

Sigh. That has nothing to do with why this is a bad idea. Many, many reasons have been given to you as to why this is a bad idea. If you want us to change our minds, you actually have to respond to the points we are making, and not just handwave them away or ignore them. So, again: Everybody loves Oprah. How do you propose to deal with people violating BLP in the forum about her article? Or the forum about starfish? How do you suggest, with millions of articles, we decide which articles get fora and which don't? How do you address and overcome the whole reason we're here, as well as why we're not here (especially this bit)? How do you suggest we find and pick moderators (hint: you can't just ask random moderators from other websites to come do it; they have their own headaches to worry about and, if they're not already Wikipedians, won't understand Wikipedia culture)? How do you suggest we give moderators the power to delete and block? How do you suggest we deal with spam? If you want us to believe you're actually acting in good faith, trying to propose something that you think will improve the encyclopedia, you need to address those point. And others, but let's start with you actually addressing those to begin with. → ROUX ₪ 15:07, 3 November 2010 (UTC)

Ok. Oprah Winfrey is a living person so her article would obviously not have the feature. As for mentions on other articles, it would be treated the same way as it would be in the "Discussion" tab. Articles based on or pertaining to sensitive subjects such as religion, sex, living persons, abortion or gay rights would not be able to have a forum. Thus limiting the amount of forums to keep up with considering the amount of articles that are related to the suggested subjects. Mentions on other articles would also be treated as they would be in the "Discussion" tab. Articles will be voted or decided to be allowed a forum by administrators. And by voting, they also volunteer to be moderators for the forum. Limiting the amount of forums even more, considering administrators that don't want the responsibility or not familiar with moderating forums. The only benifit this proposal has is the freedom of recreational conversation on subjects of which Wikipedia articles are based on.

I refer to the "Discussion" tab because its an existing feature on Wikipedia.Cathys Son (talk) 23:43, 3 November 2010 (UTC)

Again, none of that is really feasible, and you don't seem to be aware of the vast multiplicity of things that Wikipedians can find 'sensitive.' (Seriously, it's mindboggling.) But in summary: this proposal does nothing to improve the encyclopedia, and thus simply should not, and will not ever, happen. → ROUX ₪ 23:46, 3 November 2010 (UTC)

So youre saying conversing freely isnt an improvement?Cathys Son (talk) 23:51, 3 November 2010 (UTC)

If you're really that intent on starting a forum using Wikipedia articles as a starting point for a discussion, go do it! You can set up forum software, have it slurp up articles as the "initial post" in individual thread topics or what have you, and let people discuss away. The content is all Creative Commons licensed, so as long as you follow the attribution requirements, you're good. No one's saying you can't base a forum on Wikipedia articles, and I think it'd be an interesting project, really. But that's not what this project is for. So if you think it's that great an idea, you can go do it. It just won't be with the devs here writing it for you and the admins here policing it for you. But if it's that good an idea, you should be able to arrange people who are interested in helping with those tasks. Seraphimblade Talk to me 23:55, 3 November 2010 (UTC)
I'm saying that it does nothing to improve the encyclopedia, and would almost certainly actively harm it, given the vast amounts of time and attention it would take to moderate. Look at MetaFilter for example. Active userbase in the tens of thousands, and far, far fewer pages to keep an eye on. There are three full time (as in, it is their paid job) moderators. And their moderating style is extremely light, plus they have the equivalent of Checkuser permissions and are able to head off problematic users before they start becoming problems. The moderation style that would be required here would be extremely heavy, and require even more time and personpower, detracting from the whole point of why we are here: building an encyclopedia. The only benefit you cite is recreation. That does not contribute to building an encyclopedia. I don't honestly know how to make it clearer to you; this site has one purpose, and one purpose only. There are uncounted thousands of fora out there where you can talk to your hearts' content. You can even build your own. What will not happen is fora becoming part of the Wikipedia framework. → ROUX ₪ 23:59, 3 November 2010 (UTC)

The End Cathys Son (talk) 00:05, 4 November 2010 (UTC)

I know this discussion/proposal is long dead, but in any point during this arguement, why wasnt this mentioned? WP:LiquidThreads Cathys Son (talk) 00:26, 21 December 2010 (UTC)

Because that is a format for displaying discussions which actually improve the encyclopedia, and is not a way to put fora into a place where they simply do not fit. → ROUX ₪ 03:39, 21 December 2010 (UTC)

"LiquidThreads replaces discussion pages with actual forums." With every articles discussion tab being converted to the format of a forum, wouldnt you say that policies would be any harder to enforce? And I was just talking about certain articles here and there, or possibly a feature, but its actually replacing the discussion tab on every article with a forum, even ones on sensitive subjects. This would seem to do more damage to articles than my propsal would. Cathys Son (talk) 07:21, 21 December 2010 (UTC)

Cities

Short title for an incredibly complicated situation. I started a tread on this subject, and there was a mixed reaction. Some people hated the idea of deleting the city articles, even if the article didn't have a reference. Their main argument was Outcomes, and the fact that someday someone might want to expand the article. Arguments against keeping the articles include if we can't find any sources, then the place isn't notable enough to be included in the encyclopedia.

My proposal is to require new articles about a city or an incorporated place to have at least one reference. I also propose a Sticky prod like the unsourced BLP PROD. (ie only for articles created after a certain date) What do you think?--intelatitalk 01:51, 31 October 2010 (UTC)

I would be happy with requiring a source. However, it may not be so simple.
My understanding was that a very large number of these settlement articles were created by some bot which read a long boring government gazetteer or census. If that is the case, then the gazetteer or census counts as a source, surely..? Whether or not that is always added to the article at the time of creation is another question - presumably there's a very large number of such settlement stubs which were created on the basis of some source or other, but which do not currently have any refs in the article. PRODding those en masse is likely to create a lot of noise. ;-)
bobrayner (talk) 02:17, 31 October 2010 (UTC)
By similar to the BLP Prod, I mean only applicable for articles created after the proposal takes effect. for the others a similar process like the Unsourced BLP problem.
By sourced means just that, linked to a verifiable source one way or another.--intelatitalk 02:20, 31 October 2010 (UTC)
  • I see no reason to use any standard short of WP:N for cities: a direct and detailed examination of the topic in multiple reliable sources that are independent of the city itself. I don't care that sources may exist that we haven't found. I don't care if people believe that it is highly likely that a source exists. Multiple independent sources have to be found prior to article creation. I think it is also clear that an entry in a census or a speck on a map (or the cyber-equivalent of an entry in a geographic database) doesn't constitute a direct and detailed examination of the topic.—Kww(talk) 02:40, 31 October 2010 (UTC)
WP:N is not WP:GNG. As we are discussing in WT:N#What is the consensus on City articles?, multiple reliable sources that are independent of the city itself have never been required for a stand-alone article on a city to be created. patsw (talk) 03:17, 31 October 2010 (UTC)
Always should have been. The GNG was bypassed for no good reason, and there remains no good reason to do so. A direct and detailed examination of the topic in multiple reliable sources that are independent of the city itself is the standard that should be applied, even if we have failed to have an inclusion standard in the past.—Kww(talk) 03:56, 31 October 2010 (UTC)
Well, not just bypassed. A lot of those were created before there was the clear requirement that every article pass the GNG, so I won't say the people who created them weren't acting in good faith. That being said, however, they are there, a lot of them do fail the GNG, and so cleanup is necessary. I would tend to suggest the creation of a "list of places in Example County" (or similar administrative division for the country in question), with a table for population, coordinates, etc., the main stuff in the geo-stubs, and then bluelinks to the genuinely notable place articles. The non-notable place articles can redirect to the list. Seraphimblade Talk to me 09:49, 31 October 2010 (UTC)
What does it mean "sources that are independent of the city itself"? Cities do not have a need to "achieve notability" as garage rock bands or amateur actors have, cities are notable just by their very existence. Even if at stadistics levels (such as population, income or other things), we will always be able to find sources to provide information about them. Local media is also likely to be helpful to find information about who and how rules in that city, urban developments, etc. And just by being from the city does not mean that they are dependent of it (in the sense meant by the notability criteria), otherwise, we couldn't have articles about Earth or Human.
In any case, if we delete unsourced articles about cities, we would face the problem that takes place when articles on notable things are deleted after a technical restrictive interpretation of the notability guideline: someone else will notice the absense of the article and write it again (unlike rock bands or amateur articles, unlikely to ever been considered by anyone besides their subjects themselves or close people). The whole deletion process would become pointless, and it's certainly a very bad way to try to encourage people into adding references. MBelgrano (talk) 13:56, 31 October 2010 (UTC)
Can we please get the terminology right? Do we mean (in descending order) cities, towns, suburbs, villages, hamlets, or all settlements in general? The question is rhetorical, because there is already a consensus somewhere (I haven't had time to dig it out) that all inhabited settlements are de facto notable, especially if they are shown on, say, a British OS map. Nevertheless, we might have to draw the line at a forrester's hut in a clearing in the jungle. --Kudpung (talk) 14:11, 31 October 2010 (UTC)
Yes, MBelgrano, I mean that people not connected with the geographical place need to have written about it, and not just the census data. To get an independent, standalone article, there need to be sources that discuss some aspect of the place in reasonable depth, and that can't just be a Chamber of Commerce release: WP:V demands that articles be based on sources independent of the subject, and geographic locations haven't got immunity from that requirement. Kudpung, that previous consensus is exactly what was being challenged: it was misguided and wrong, though, as Seraphimblade points out, probably not intended to be harmful.—Kww(talk) 15:30, 31 October 2010 (UTC)
Adding on to clarify, since I reread MBelgrano's point. Generally, I would consider local newspapers to be independent of the city. My concern would be more with Chamber of Commerce releases or with publicity by a small town that is owned by one or two people. The problem we have here is cities that are only specks on a map, and not many of those are going to be found to have independent newspapers.—Kww(talk) 16:00, 31 October 2010 (UTC)
Whether something is "only a speck on a map" depends on where you are. If you go there, you'll find it's a lot more than a speck, and there are almost certainly local books and newspapers that contain substantial information about the place. We just have to wait patiently until people come along and start adding the information to the article. Cities aren't going to sue for libel, so we don't have the problems that were behind the special treatment for BLP articles. In fact, I don't know what problem these discussions are supposed to solve, at all. The people who write and use Wikipedia are very happy that it includes detailed geographical information - I agree that in some cases articles on very small places could be merged into larger ones, but I don't see any reason not to maintain stub articles on places that could have (but haven't yet had) significant amounts written about them, just as we maintain such stubs on many other subjects.--Kotniski (talk) 16:20, 31 October 2010 (UTC)
The patience is required before article creation, not after. Stub articles are acceptable when there is no other alternative, but 99% of the time, we would be better served by a redirect to a larger article where that larger article stands a chance of providing useful information. That's my objection: stubs are generally the worst method of presenting information, but people fight to have a stub as if not having one is reducing the information quality. A redirect from a flyspeck town name to a good article about the county it is in is better than a stub, not worse.—Kww(talk) 17:10, 31 October 2010 (UTC)
Again, it depends what you mean by a "flyspeck". If it really is a tiny hamlet, I might agree. But if it's actually a fully-fledged town or village (which means that it almost certainly has the potential to be a reasonable article), then I think we should keep the stub - this always having been one of the principle ways in which Wikipedia encourages people to add new information. (And in some ways, having a stub is useful for the reader too - it confirms straight up that this really is the limit of the information Wikipedia has on the subject.)--Kotniski (talk) 20:31, 31 October 2010 (UTC)
  • I'm going to be going on a month long hiatus starting tomorrow, so I just wanted to put forth my opinion here now. Note that I will not be able to respond to you if you are responding tomorrow to this. As I stated in the discussion on the Notability talk page, and as expertly outlined by MBelgrano above, the notability requirements for cities, towns, and villages are quite different from notability requirements for other articles. A comparison can be made between articles on places and the numerous articles on biological species on Wikipedia.
The point of Notability, when it was created, was to make sure that there was a limit on what sort of articles could be made, so we didn't end up with articles on people who have never done anything or articles on garage bands or articles on every car accident ever. However, places are different. As long as they have been verified to exist, they are notable. Every place on Earth, when following Wikipedia's role as a gazetteer as outlined in the Five Pillars, is notable as long as it can be verified to exist. I do agree with the fact that every place should have at minimum one source, whether it be to a government census agency or not, that verifies it's existence, but I do not agree that it should have to match up to the requirements of "multiple sources of non-trivial coverage" because it is assumed that every single place has coverage of it somewhere.
Every place over its history has been covered in print somewhere, whether it be in a local history book or something else. It is for these reasons that consensus in the community has long held that places are always considered notable as long as it can be verified that they exist. And that's all for me, i'm out. Have a good November everyone. SilverserenC 18:05, 31 October 2010 (UTC)
Thank you. That matches my position. :)--intelatitalk 18:08, 31 October 2010 (UTC)
No problem. Though, I would note that I do not really agree with the Sticky Prod idea, since so many of these place articles are not watchlisted, many of them would end up being deleted because no one tried to look for a source. Because it is assumed that every place is notable once it is verified it exists, it really shouldn't be that difficult to go on Google and find a census report or something else. I think something else should be used to help source these articles, something that doesn't have the threat of imminent deletion hovering over it. We want to conserve the content on here, not remove it, so we should be looking for options that help us match that goal. (And now I really am out for the month) SilverserenC 18:21, 31 October 2010 (UTC)
You are making a very shaky assumption: there is no reason at all to believe that there are written reliable sources about every place that anyone ever gave a name. That simply isn't true: oral history is common for most of the world for most of time. Most places have only census data, and there's no reason to place census data in a separate article.—Kww(talk) 21:40, 31 October 2010 (UTC)
If there is no reason at all to believe that there are written reliable sources, how did bots create so many articles? I think it unlikely that bots created random articles on a whim.
They would have been based on some kind of official listings - unlikely to be raw census data although there will be variation from country to country. Speaking of shaky assumptions: There seems to be an assumption that all these settlement articles are a homogenous mass and that they were created in the same way from the same source material.
If proposing drastic measures for a very large number of articles I would think it more appropriate to stick closely to policy and think carefully about the nature and the origin of all these articles.
bobrayner (talk) 21:50, 31 October 2010 (UTC)
The stub articles were based on census and map data, hardly an in-depth discussion of the places in question, and not enough to generate a reasonable article on. They are fairly homogeneous: that's the sole advantage of bot-created articles.—Kww(talk) 22:19, 31 October 2010 (UTC)

Why can't we just merge the stubs where there's not much verifiable content to write anything meaningful? Some specks are meaningful by themselves. Some specks are only meaningful when combined with many other specks into a county, town, region, etc. That's a sane and rational policy that's consistent with WP:V and WP:N and also leads to more useful and reliable content too. Shooterwalker (talk) 06:41, 1 November 2010 (UTC)

We both can and should. The problem is that people tend to undo those redirects because of the every habitation deserves its own article theory. We have numerous editors that tend to view anything less than a standalone article as some kind of insult to the topic at hand, instead of considering the issue of what makes for the best presentation of the information.—Kww(talk) 21:19, 2 November 2010 (UTC)
(Silver seren) Um, you probably shouldn't until you're able to get a community consensus to do so? If you try to do it vigilante style, you're just going to make a lot of people angry and end up at ANI down the line for it. I've actually seen that before as well. 165.91.173.45 (talk) 04:51, 3 November 2010 (UTC)
Only because we have misguided people that insist on separate articles instead of the best presentation of information. It's a shame that they exist, but there's no getting past them.—Kww(talk) 14:08, 3 November 2010 (UTC)
(Silver seren) It's called consensus, Kww, you just have to get used to abiding by it if you want to do anything on Wikipedia. That's how it works. 165.91.174.83 (talk) 21:52, 3 November 2010 (UTC)
Right now there appears to be NO consensus. We're trying to build one. The current situation is chaotic, with edit wars, AFDs that go the wrong way (delete and keep)... Why not try to reach out and build a common understanding of the best way to handle these articles? Shooterwalker (talk) 16:14, 5 November 2010 (UTC)
I never said that you shouldn't try to find consensus. I was explaining to Kww how you shouldn't just try to merge city stub articles without finding consensus, since you would be going against the prior long-standing consensus without any resolution. Also, maybe this discussion should be moved to some more public venue or something? We're not getting very many users involved here. Maybe inform some wikiprojects about this or something? 165.91.173.45 (talk) 22:04, 5 November 2010 (UTC)
The Village Pumps are about as public as it gets.. your only other option is a formal RfC. -- Ϫ 13:54, 6 November 2010 (UTC)
I suppose so, but we need a way to get more people involved then, since the only real discussion here is between the same four or five people that were originally discussing it. Not really a consensus, there. :/ 165.91.173.213 (talk) 20:03, 6 November 2010 (UTC)

Examples TAB beside Article tab and discussion tab

GidaY! You guys are doing a fantastic job, but the functionality of many of the articles is limited by their purely theoretical nature, or use of complex, precision examples and definitions which have probably been settled upon by debate between editing University Professors and those with a high understanding in the specific field. This generates copious amounts of articles that are difficult for students and the average reader to relate to and understand. To address this problem, i suggest an examples tab be created to sit beside the article and discussion tabs.

This would allow people to add practical examples to articles without needing to change the content of the articles themselves. As you know, most people learn practically, with examples, exercises and participation being a far faster teacher than theory alone. Having a page of graduated difficulty examples for all the pages would allow people to understand the theory encompassed in the article section far better and faster.

In order to construct this extra section, I may naively assume that you should just be able to allocate a an extra region of storage space as editable space to each wikipedia entry in parallel with those that already exist, and apply the same rules and programming used for the article section. The fact that space already exist for a tab on the bar beside the article button would mean that other code shouldnt need to be changed either. This is probably a gross underestimation, but the benefit to the quality of wikipedia, a 10 to 30% improvement in the whole experience would be well worth the effort.

Cheers and good luck Hamish New Zealand

Examples of what would greatly benefit from an examples tab:

All maths artices, physics, science in general Economics, accounting, art - techinques and painting exampes. Animal species, examples of their charachteristics and locations Car parts, installation exampes Cooking, recipes, where to source ingredients, famous times dish was served People, examples of their speeches, music, art, deeds etc Programming, codeing examples Etc. Unlimited examples. I contend that almost every article on wikipedia would benefit from an examples tab. — Preceding unsigned comment added by 115.188.181.7 (talk • contribs)

  • Have you tried Simple English Wikipedia instead? It is designed to have easier to understand articles... --Jayron32 03:33, 7 November 2010 (UTC)
  • Wikipedia is not a textbook or an academic course of study, it is an encyclopedia; does Brittanica include extra collections of examples or exercises? I think not. However, there are already Wikibooks and Wikiversity, where collections of worked examples would be entirely appropriate and welcomed; I encourage you to contribute to them. --Cybercobra (talk) 05:12, 7 November 2010 (UTC)
  • Wiktionary has something similar in the 'Citations' tab. I think it's a worthy idea. But why couldn't examples just be integrated into the text itself? It shouldn't have to have its own separate page. -- œ™ 05:49, 7 November 2010 (UTC)
  • Here's how I always think about this thorny issue: a) Work out who reads any given article b) Write the best article for that issue with examples if need be. IMHO, no article needs to be both extremely detailed and popularly understandable with the incorporation of examples at every step (*waits for list of counterexamples*). No experienced programmer needs Computer programming to be a detailed article and so it can incorporate examples; if they want detail, they can find a more detailed article such as Abstraction (computer science) and read that instead. Likewise the lay-person is unlikely to want or need to read directly about Abstraction in CS, but would prefer to have it placed in context in a wider reach article with examples such as Computer programming. Now, for my money, properly implementing that theory - if it were to be and I don't believe it has been yet - is a two way street, but ultimately, examples need not be contentious in any circumstances and likewise need not be in a separate tab. But there you go. - Jarry1250 [Who? Discuss.] 13:07, 7 November 2010 (UTC)

Software coding change for use of RevDel

Please see this discussion; is it possible to code into the edit summary use of WP:REVDEL a link to that page, since editors who have edit summaries struck may not know why or where to find this info? SandyGeorgia (Talk) 18:35, 7 November 2010 (UTC)

It may be possible to do this by editing MediaWiki:Rev-deleted-comment. Ucucha 18:40, 7 November 2010 (UTC)
Aha, good. MediaWiki:Rev-deleted-no-diff and MediaWiki:Rev-deleted-text-permission link to the policy. MediaWiki:Rev-deleted-comment, MediaWiki:Rev-deleted-user and MediaWiki:Rev-deleted-user-contribs don't. I think they all should, even if it's just wikilinked "removed" to the policy. Rd232 talk 18:46, 7 November 2010 (UTC)
I just tried Rev-deleted-comment—unfortunately, it does not accept wikilinks, so the text that appears is 
(edit summary [[Wikipedia:Revision deletion|removed]])
Ucucha 18:53, 7 November 2010 (UTC)
And I wasn't the first to discover that. Ucucha 18:57, 7 November 2010 (UTC)
That's annoying. Can anyone illuminate the feasibility of getting this done? May need a software change after all? Rd232 talk 21:39, 7 November 2010 (UTC)
File a bug, probably, though IDK if this is a technically feasible change. /ƒETCHCOMMS/ 02:54, 8 November 2010 (UTC)
I suppose the other possibility would be to make up a template to place on the user's talk page or article talk page, saying "an administrator has just deleted revisions" with a link to the policy. Elen of the Roads (talk) 00:13, 9 November 2010 (UTC)
I'm not sure it makes sense on the article talk page, and I'm not sure how often a user talk template will actually be relevant. I've just spent a few minutes trying and failing to come up with an amendment to WP:REVDEL on the possible role of notifying users. The problem is that in general notifying users is either unnecessary or counter-productive; an admin thinking "a note here might be helpful" should see it as a bit of a warning sign that maybe they shouldn't do the RevDel. Or if they do, better to ask for review at AN than do a dubious RevDel and then post a link to the policy. You see my point? An automatic link to the policy is just generically informative, but thinking about it in terms of notifying or warning with the subtext of flagging for possible appeal or review is wrong, because RevDel shouldn't be controversial, and where it possibly is, review should be requested at AN. Rd232 talk 00:48, 9 November 2010 (UTC)

Creation of Wikipedia:Revision requests for redaction

Hi. I'm thinking of creating a new project page for Wikipedia, called Wikipedia:Revision Requests For Redaction. Basically, its a request page for any revisions that users can request to be deleted (A bit similar in context to WP:AIV except that revisions get reported). Now that the RevDelete tool has been granted (although not given by default) to administrators, I feel that the same Administrator intervention should work there as well as AIV and UFAA. I know that there's WP:Requests for oversight, but those requests can only be done by a private email. WP:RRFR is a more "public" project which the revision deletion process can be done a lot faster with the many number of administrators around the project that can deal with them. Minimac (talk) 20:02, 8 November 2010 (UTC)

See Wikipedia:Administrators' noticeboard/Archive217#Time for WP:RFRD? and Wikipedia:Administrators' noticeboard/Archive218#TIme for WP:RFRD? for some previous discussion on this topic. Anomie⚔ 20:53, 8 November 2010 (UTC)
See also the recent note added to WP:REVDEL and CAT:RFRD. Rd232 talk 21:20, 8 November 2010 (UTC)
FWIW, it looked like there was a rough consensus to at least try it out and see how it works (though I personally disagreed with the proposal). –MuZemike 06:31, 9 November 2010 (UTC)

Quick comment, "Now that the RevDelete tool has been granted (although not given by default) to administrators" doesn't make sense to me as RevDel is something any admin can do. It's part of the standard package, like block/protect/delete. Abusefilter-edit is the one that's not given by default. /ƒETCHCOMMS/ 01:05, 9 November 2010 (UTC)

Hi all,
Experienced wikipedians may know their way around - or at least know where to look - but I think that newcomers are not very well catered to. For a newbie using the default skin &c, I believe "Help" is the twelfth link down the sidebar on the left-hand side of the main page, in the "interaction" section; and the visual design of the main page tends to draw eyeballs away from the sidebar.
I think it would be good to make the link more prominent, by moving the help link further up in the sidebar. I think it would be better in the top section, (which is currently called "Navigation" in Monobook (not sure that's the best name even with existing content, but let's not get sidetracked...)). This would improve the visibility of help, just a little, for the people who most need assistance finding their way round wikipedia. What does the community think? Yes or no?
bobrayner (talk) 09:01, 30 October 2010 (UTC)

As an aside: This idea was inspired by an earlier discussion on Help talk:Contents/draft about other improvements to Help, and there was some support there, but I'd like to put this idea before a wider audience. Apparently the last sidebar redesign did involve a help link further up, but that didn't make it into the final cut; I do not know why. bobrayner (talk) 10:19, 30 October 2010 (UTC)
  • Support. Move the "Help" link to the top of the "Interaction" section, above the "About Wikipedia" link. (But not in the top section, which is for linking to encyclopedic-content. The Interaction section is for linking to meta-content.) -- Quiddity (talk) 19:13, 30 October 2010 (UTC)
  • Move the "Help" link to the top of the "Interaction" section, per Quiddity, above. The top section is for readers/browsing. The interaction section is for editors (the community). The top of the interaction section would be a perfect place for it. The Transhumanist 02:47, 31 October 2010 (UTC)
  • Support I point out that by default, the Interaction tab is collapsed, so not even visible to users. Perhaps we should move it up to Navigation... Though that really messes up the usefulness of the naming of the sections. —TheDJ (talk • contribs) 14:19, 31 October 2010 (UTC)
  • Support. Sounds like a sensible proposal. Although it probably would have only minimal effect - it doesn't take a whole lot of searching to find it, and moving it might even confuse some readers who are used to finding it in the place it's currently in. -- œ™ 12:24, 5 November 2010 (UTC)
  • Support, move it out of the 'Interaction' tab, and place it just under 'Donate'. -- d'oh! [talk] 12:56, 5 November 2010 (UTC)
  • Per request on MediaWiki talk:Sidebar I have moved the help link up to the top of the navigation section. If this is not the best solution, please continue the discussion, because you were all suggesting different places. Cheers — Martin (MSGJ · talk) 13:16, 8 November 2010 (UTC)
    You meant to the top of interaction section? Ruslik_Zero 19:55, 8 November 2010 (UTC)
    That's it. — Martin (MSGJ · talk) 09:17, 9 November 2010 (UTC)

Edit summary reports

Should there be a page, similar to AIV or SPI were one can report edit summary vandalism? Something like 'Wikipedia:Edit summaries for administrator attention' or 'Wikipedia:Diffs for administrator attention'? I can create this, but I wanted to get others opinions first. --The High Fin Sperm Whale 21:33, 9 November 2010 (UTC)

Why? Ucucha 21:37, 9 November 2010 (UTC)
There's no such thing as 'edit summary vandalism'. There may be 'edit summary personal attacks', edit summary racist abuse' 'general edit summary bollocking about' etc etc, which can be reported to ANI in the usual manner. --Elen of the Roads (talk) 21:40, 9 November 2010 (UTC)
I think a spam link or an extremely libelous edit summary deserves to be removed. And I think there is too much of it to write an ANI report every time you see it or ask an admin. Since only admins can remove it, then we commoners have to have some way to report it. And can it do any damage? --The High Fin Sperm Whale 21:48, 9 November 2010 (UTC)
So essentially you want a "requests for RevDel"? See the section immediately above this one for that. Ucucha 21:52, 9 November 2010 (UTC)

Wikipedia Manual

As a novice registered editor I am having difficulty assimilating - learning markup/tags/sites/communities - its all of a mersh - like Wikipedia lacks a front door. I propose an official hard copy Wikipedia Manual be published to assist and promote Wikipedia. I searched online for somesuch and found this; Wikipedia; The missing Manual by John Broughton - hah - love the irony. I'll buy a copy, but why is there no official Manual, to enable novice editors, and spare them the trial and error baptism of fire. (?) An official manual could net the project some useful pennies, so why don't it exist? MarkDask 13:35, 3 November 2010 (UTC)

Zeno has since sent me the link to the online manual, entitled The missing Manual - thank you Zeno but I want a hard copy. Why doesn't one exist? MarkDask 13:48, 3 November 2010 (UTC)
Wikipedia changes too often for a hardcopy manual to make any sense. Plus, a hardcopy manual is hard to update. If you're having difficulty, some of the lessons here may be of use to you. → ROUX ₪ 13:51, 3 November 2010 (UTC)
The hardcopy does exist; see Wikipedia – The Missing Manual. Understand that it is a 2008 edition and does not include the multitude of updates over the last two years. ---— Gadget850 (Ed) talk 16:17, 3 November 2010 (UTC)
I am quite aware of that, thank you. Given your own point about it being a 2008 version, that is.. well that is exactly proof of what I was saying, so I'm not really sure what you thought you were adding here. → ROUX ₪ 16:19, 3 November 2010 (UTC)

Roux and Gadget, thanks. Clearly Wikipedia – The Missing Manual is in fact the official manual given it exists on Wiki as well as in hard copy. I would say to Roux though, the fact that the hard copy is two years old does not detract from its worth to new editors as a comprehensive introduction to how wiki works. It has answered a lot of questions for me in the 24 hours I have known of its existence. MarkDask 14:18, 4 November 2010 (UTC)

I wouldn't call it "official" in any way. The Missing Manual series is created by a third-party and covers a wide variety of subjects. — The Hand That Feeds You:Bite 19:17, 4 November 2010 (UTC)
Okay Hand, I'll rephrase. Based on some small reasearch on my part, and in the absence of an official manual, Wikipedia – The Missing Manual would appear to be the most appropriate introductory guide for new editors to how Wikipedia works, particularly given it is available within wikipedia itself, (public domain), as well as in hard copy. MarkDask 05:25, 5 November 2010 (UTC)


As a note, you can find an always up-to-date version at Book:Wikipedia: The Missing Manual. You can have it printed, or download the PDF, whichever suits you best. Headbomb {talk / contribs / physics / books} 05:55, 5 November 2010 (UTC)

Thank you Headbomb. The printers are Pediapress - is that a wiki project or a third party? MarkDask 15:30, 5 November 2010 (UTC)

PediaPress is the company that created the book tool. They have a partnership with the Wikimedia Foundation. Reach Out to the Truth 18:52, 5 November 2010 (UTC)
Pretty much what ROttT said. PediaPress and the Wikimedia Foundation have a partnership. Pediapress develops the book tool ("Create a book" in the "print/export" toolbox on the left) and PDF rendering tools ("Download PDF" in the same toolbox), and will also print books on demand. 10% of the price of these books goes directly to the Wikimedia Foundation. You can read more about it in the Signpost. (Disclaimer: I'm with Pediapress.)
Headbomb {talk / contribs / physics / books} 19:05, 5 November 2010 (UTC)

Given the above, perhaps Wikipedia – The Missing Manual, or some form of Manual, would fit well if directly accessible in the Main Page Toolbox section - where else to find a manual but in a toolbox? Wiki documentation is simply too vast and unstructured for new editors to regard it as most newuser friendly. Aspiring editors might more readily go to a manual, structured learning. How easy would it be to do this I wonder? MarkDask 21:07, 5 November 2010 (UTC)

It is linked from the main help page, Help:Contents ("Help" in the sidebar), but not very prominently. If our onwiki version of The Missing Manual had a few of its major problems fixed, I'd agree with making it more prominent.
(Major problems include: images and prose that refer to the old siteskin (monobook), and incomplete section links (it says "the section about xx" where the original book version had page numbers. See also Help talk:Wikipedia: The Missing Manual#Known problems for a few more). -- Quiddity (talk) 19:33, 6 November 2010 (UTC)
Thanks Quiddity - I've noticed each of the problems you refer to. If the Help:Contents page were linked from the Main Page Toolbox section, even that would be a vast improvement, and soo easy to do. As it is the word "Help" does not even appear on the main page. Also, the [[help:Contents] page is very user-friendly, but might benefit from a "Go back to Main menu" button at the bottom throughout the section, as it is possible as is to get completely lost in the section. Is that doable? MarkDask 07:15, 7 November 2010 (UTC)
Adding a link to [help:Contents] on the mainpage in the "Other areas of Wikipedia" section might be possible. You'd have to ask there. (I recommend waiting a few days, as they're currently in heavy discussion about another aspect of the mainpage design: the "number of articles" shown at the top)
Bottom links, like [#Top] links, aren't recommended. Also, we already have the auto-generated breadcrumb links just below the header, which is fairly standard in UI.
Fyi, there's discussion at Help talk:Contents/draft about some potential changes to the main help:contents menu. -- Quiddity (talk) 20:42, 9 November 2010 (UTC)
Thanks for the link - A lot to read there - let alone comprehend. I will study the draft and see if I can contribute in some way. It had occured to me, why not simply relabel the Interaction section Help? Then relabel the subsection Help as Help: Content. The word interaction is vague, bland, almost decontextualised. It is not clear to the newbie as the place to go to for help. Thanks again.MarkDask 20:00, 10 November 2010 (UTC)

We need a Village Pump for policy problems

You know, if someone sees a possible policy violation but is unsure about how to proceed.Vchimpanzee · talk · contributions · 21:53, 10 November 2010 (UTC)

There are numerous noticeboards (which are listed at the top of WP:AN and others) that exist for various breaches and concerns about policy. Is there a specific policy you are concerned about? Resolute 21:55, 10 November 2010 (UTC)
I thought this was appropriate for The Policy Village Pump because it appeared to violate several policies at once: "Her own Wikipedia page" in a list of publications by a living person. Or it could have been a dead person. Either way, it was potentially both WP:OWN or WP:COI.It could have happened in any article (making it a general problem), but who exactly will see my concern on the article's talk page in the next six months? So which of the WP:AN would that be?Vchimpanzee · talk · contributions · 22:03, 10 November 2010 (UTC)
You need to say more about the actual case, or we won't know how to advise you. EdJohnston (talk)22:16, 10 November 2010 (UTC)
This isn't helping. Every time I try to be specific, I get yelled at.Vchimpanzee · talk · contributions · 22:20, 10 November 2010 (UTC)
I'll give two more examples. Adisambiguation page where to me, the words appear to be unrelated and yet someone wants to put both words on the page. I was told the article's talk page was the place to go, but I feel no one would have noticed had I not started on the Policy Village Pump. Also, I needed advice on the proper procedure (policy?) for contacting a German speaker for possible contributions to an article that was much better in German Again, the Policy Village Pump attracted just the person I needed. And yet in those cases as well, I got yelled at for where I posted.
The specific articles are Betty Diamond, Whopper (disambiguation) and Voestalpine. And now that I've gotten that specific it seems like it's not a policy discussion.Vchimpanzee · talk · contributions · 22:36, 10 November 2010 (UTC)
I just looked over at WP:Village pump (policy). The problem isn't so much that you brought your question to the pump, it's that you didn't start on the article's talk page. Even though you feel that no one would notice, that's not the issue. In order to maintain a semblance of order, we need to always start on the article's talk page when the question is about the article itself. Well, that's not 100% true, but it's true more often than not. For example, on the Betty Diamond issue, you could have started on the talk page of the article. Then, if you didn't get a response, or you got a response in your favor, you can go ahead and make the edits. Heck, you didn't even have to do that--you could have just started making the edits, and then had a discussion afterward. You only really need to discuss first if you know your changes are potentially controversial (or the topic itself is). If you weren't sure what changes to make, then asking first is also a good plan. The idea is that the regular editors of the article, if it has any, will be the most likely to have a good answer. Then, if you have a disagreement, you can bring the issue to the relevant board. Now, where I do agree is that it can be very difficult to decide which board to go to. My guess is that for the things you're asking about, it's best not to go to the Village pump, but to one of the noticeboards, like WP:RSN, the notice board on reliable sources, or WP:BLPN, the notice board on biographies of living persons. The latter may have been a good place to go on Betty Diamond. Even if she was dead, the policy applies partially, and they could at least help you out. Which brings us to the final issue--if you need help using Wikipedia (you don't know where to take an issue), you can either ask a user you've already had good interactions with on their talk page, or you can ask at the Help Desk, and they can point you to the right place. But, in the middle of your specific concerns, perhaps your core notion--that we need a better organization for all of our noticeboards to help out new users--is worth looking into. 202.246.44.5 (talk) 01:07, 11 November 2010 (UTC) sorry, that was me, logged out by mistake. Qwyrxian (talk) 23:43, 11 November 2010 (UTC)
And I just remembered one more place to look. If you need help on a specific subject, try the WP:Wikiprojects. Not all of them are active enough to be helpful, but they can be a good place to get help from subject level experts, like when you were looking for the German speaker. 202.246.44.5 (talk) 01:07, 11 November 2010 (UTC) sorry, that was me, logged out by mistake. Qwyrxian (talk) 23:43, 11 November 2010 (UTC)
Ditto, what 202.246.44.5 said.
See Wikipedia:Noticeboards for details, and Template:Noticeboard links for the quick list. -- Quiddity (talk) 02:04, 11 November 2010 (UTC)
Noticeboards are just a tool to centralize disputes or discussions, they are not meant to deal with only a specific aspect of an article and dismiss the others. If an article has many potencial problems, simply define which is really the biggest problem, go to the specific noticeboard, and explain the whole thing. For example, original research and POV pushing are usually employed toguether MBelgrano (talk) 02:26, 11 November 2010 (UTC)

I appreciate all the help. But it's still all as confusing as if I were a newbie.Vchimpanzee · talk · contributions · 17:08, 11 November 2010 (UTC)

Step 1: Ask at the connected talkpage. Step 2: If in doubt, ask at WP:Help desk. Step 3: Profit!
("If you're not confused, then you're not paying attention." - attributed to Tom Peters). -- Quiddity (talk) 20:03, 12 November 2010 (UTC)

watchlist for all days really is for 30 days so relabel or recode

Watchlists seem to have a 30-day limit, in both Wikipedia and Wikiquote. Therefore, what it says on the watchlist page as "[s]how last 1 | 2 | 6 | 12 hours 1 | 3 | 7 days all" should be amended so "all" becomes "30". Even better would be offering a much longer, or infinite, time frame, but this edit is probably easier to implement. This affects me since I edit a lot on WP and check that watchlist often but hardly edit at all in any other project, so I don't want to check their watchlists very often. Thanks. Nick Levinson (talk) 05:35, 11 November 2010 (UTC)

The recentchanges table only keeps stuff for thirty days, so 30 days is all. But it's not guaranteed to be 30 days either; see the documentation for $wgRCMaxAge. The value in $wgRCMaxAge is seconds, not days, and is therefore not suitable for display. And it's also totally safe to clear out the table entirely, and it will only then contain edits made after that point and not the full thirty days worth. Reach Out to the Truth 05:51, 11 November 2010 (UTC)
Okay, how about "up to 30"? That would be accurate and not misleading, unlike "all". We see "all" and no edits and we assume there must not have been any. Nick Levinson (talk) 06:23, 11 November 2010 (UTC)
Patches are welcome in bugzilla: —TheDJ (talk • contribs) 23:46, 17 November 2010 (UTC)
Thanks; good idea, so I reported it there, as Bug 26022. Nick Levinson (talk) 04:56, 20 November 2010 (UTC)

ranking of english words used in wikipedia

Hello

The huge amount articles in wikipedia.org is written in English language. It is good reason to learn this language. I want learn English in smart way. So I think the best start point for learning words is get knowledge about words popularity in today English language. I googled for such words ranking list and finally I found http://en.wiktionary.org/wiki/Wiktionary:Frequency_lists. On this page are two noticeable lists: "TV and movie scripts", and "Project Gutenberg". But I think that former is inadequate due to orientation on dialogs instead on description, and latter is inadequate due to ancient English language version used for ranking.

So I think there is huge necessity for create "Most common english words in Wikipedia". Because then huge number of nations can learn English words in rational way.

I think that list with at least 10000 most popular words should be published. File format should be plain text file with every row like this: [row number][tab character][word][tab char.][apearance counter]

I think there can be two ways to acomplish this task: 1. As I am programer I can write script or program which produce such list. This require access to some API (can be dummy/fake). Then I will give this program to you, and you will invoke them on real Wikipedia database (in read only mode). 2. For security (or other) reasons this project can be acomplished by wikipedia staff.

In either way I can make small donation to quick acomplish this project. I can donate 100$. I think that should be enought for hiring programmer for one day. If this sum is not enought please tell me how many money is needed to acomplish this project.

regards Bobas

ps. It will be nice when similiar rankings of words popularity will be created for other nations. But I think this is not as urgent as english words ranking.

—Preceding unsigned comment added by Bobaskonto (talk • contribs) 16:50, 12 November 2010 (UTC)

Have you had a look at Most common words in English or searched for something like that on the web? Dmcq (talk) 22:35, 12 November 2010 (UTC)
Hello Bobas, Wikipedia:Database download tells you how to download a copy of wikipedia. You may have to wait a few days because of server maintenance, and you will need a lot of space on your hard disk. But remember that articles on en.wikipedia are created using the Wisdom of the crowd. There isn't a master plan of what is important, instead, articles are created and maintained because of what individual people think should be in the encyclopedia. That doesn't produce an arithmetically natural distribution of articles. For example, there's a lot of material about popular culture (films, songs, TV series, trading cards etc) because many editors are interested in those things. If you analyse that, you will see a lot of references to Pokémon, Harry Potter, Lost etc. That's not so helpful if you want to visit English-speaking countries and buy food, arrange your travel or talk to someone you like. You will learn English more quickly if you use the lists provided by your teachers and textbook publishers! - Pointillist (talk) 01:20, 13 November 2010 (UTC)
@Dmcq

I don't known about Most common words in English, but it is useless to me because it contains only 100 most popular words - I need 100 times more (10000).

@Pointillist

As you can se I have some english basic knowledge already. But I want understand well what people writing in articles (especially non profesional writters like Wikipedia wolounters) and I want understand other documents in english which I consider important or promising. I have not much troubles with understanding english articles, but I want some thing more - one of my targets is almost eliminate dictionary usage. In oposite to you I think that Wikipedia english articles perfectly fits learning purposes, because it is great probe of today english. More - this is probe of language used by motivated english spokens.

I have already done this, for single words and collocations. I'll see if I can find the results. Rich Farmbrough, 10:06, 19 November 2010 (UTC).
Hm I had actually done it for specific bigrams but a rough and ready change gives User:Rich Farmbrough/temp110. Rich Farmbrough, 21:12, 19 November 2010 (UTC).

Category:Articles that are likely to be improvable

How about we create a category for articles that are likely to be able to be improved? This category would be for articles that have a new unused source, or they are missing information that can probably be easily found, or they are notable enough that more sources can probably be found, or article whose existing sources have not been completely juiced for content. This means that instead of having to search all over for articles that might have a chance for growth, all of them are already rounded up, and writers can pick from a list of articles that they know can be expanded. --vgmddg (look | talk | do) 02:26, 14 November 2010 (UTC)

That would describe every article we have. Resolute 02:29, 14 November 2010 (UTC)
No matter the good intentions of such a category, sooner or later someone would start to add it to every single article out there. --Conti|✉ 22:41, 14 November 2010 (UTC)

There are already article on similar things - for example, there is already a category on articles with unsourced statements. I think that it is worth pointing out that the clean-up tag heads some articles. ACEOREVIVED (talk) 22:29, 14 November 2010 (UTC)

Tags like the {{Cleanup}} tag or the {{Unreferenced}} tag indicate articles that HAVE to be cleaned up, regardless of the difficulty of doing so. Unfortunately, there may be some cases where the problem is hard or even impossible to fix. What I want to do is separate out those articles so that people can focus on the ones that can be easily improved to maximize growth. I have posted a similar request on the talk page of WikiProject Unreferenced articles, but here I'm asking for a general category for ANY article that has sufficient opportunity for growth. Resolute and Conti do have good points though, and there should be specific criteria for being in the category though. For example, articles that are well enough on their own, like FaceBook, should not appear on the list. --vgmddg (look | talk | do) 01:18, 15 November 2010 (UTC)

We have Wikipedia:Vital articles, which list some of the most important articles and their current level of development. It provides a similar help: although all articles may be improved, and in an ideal world all articles should be featured, it allows to locate the ones that would be more benefited from an improvement. Another alternative is to join a wikiproject and make a similar list about the articles within the scope of the project. MBelgrano (talk) 01:51, 15 November 2010 (UTC)
Wikipedia:Vital articles only tracks essential articles. I'm talking about ANY* article that stands a chance of being able to be improved. For example, a little under 2 weeks ago, I added a source to the article Blue Meanies (Apple Computer). The new source means more information can be added to the article, and that it can be expanded. However, since there aren't many links to the article though, not many people have found it and actually gotten around to incorporating the information into it. If we created a category to round up other articles like this though, then people would more likely to be able to find it and expand it. If enough articles are expanded this way, then Wikipedia will become much more comprehensive over time, and people don't have to waste time looking for an article that is expandable.
Note: "Any" means any article that isn't good enough to be comprehensive on its own. (i.e. Start Class article or lower, like Blue Meanies (Apple Computer), not something like FaceBook.) --vgmddg (look | talk | do) 23:03, 17 November 2010 (UTC)

This sounds a lot like it's covered by {{expand}}, which categorises articles into Category:Articles to be expanded. Rd232 talk 15:50, 18 November 2010 (UTC)

Or indeed Category:Start-Class articles and Category:Stubs. Rich Farmbrough, 10:56, 19 November 2010 (UTC).

Creation of Special:AllRedirects

Is it possible for the MediaWiki software to have a new special page that lists all the redirects for a particular wiki? The current form of this kind of special page would be Special:ListRedirects, but it is currently inactive/disabled and only works for the past 1000 redirects in the beginnings of Wikipedia. I believe that a new special page would be needed, and that it would be based on the same principles that work for Special:RandomPage and Special:RandomRedirect. It has the capability to help out many different areas of a wiki; for example, it might help better organize redirects on small wikis where users could monitor or repair redirects, in the same way that Special:AllPages was constructed for, that are broken or that need fixing in some other fashion—like seeing and reverting extra content misplaced below the redirect, for example:

#REDIRECT [[Foo]]

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

And for Wiktionary, it could help locate unnecessary redirects leftover from moves from the old system of Wikipedia first-letter auto-capitalization for users to delete those. :| TelCoNaSpVe :| 07:37, 16 November 2010 (UTC)

I feel like this would probably be better served as a discussion on MediaWiki. ¿SFGiДnts! ¿Complain! ¿Analyze! ¿Review! 04:30, 17 November 2010 (UTC)
the Wiktionary job would be better done with a database scan or a SQL query since it is one off. I don't see the utility to en:wikipedia of a list of several million redirects on-wiki - there are categories, there is search and there are data-base dumps (we hope). Rich Farmbrough, 11:00, 19 November 2010 (UTC)
I think building this functionality into Special:Allpages would be a better way to go about this. A simple checkbox for whether or not a page is a redirect would do it from the user standpoint, imo. --Izno (talk) 21:27, 19 November 2010 (UTC)
Now that I think about it, Special:AllPages does include redirects, so something feasible like Special:AllPages/redirect would be a useful title for the function as well. :| TelCoNaSpVe :| 22:46, 19 November 2010 (UTC)

Ad banner

The ad banner is great, but it can get annoying. If you hit the close button, it pops up on the next page if you're not logged in. Can we have a button that permanently closes the banner? WikiCopter (radio • sorties • images • lost • defense • attack) 23:29, 17 November 2010 (UTC)

  • Not likely to happen, because if you are logged out, you are on an IP address, and when the address cycles to the next reader, how will the banner show up to him or her if you, previously the occupant of the IP address, close it permanently? :| TelCoNaSpVe :| 23:34, 17 November 2010 (UTC)
The obvious solution is to stay logged in, and use the suppress fundraiser Gadget in your preferences. Strictly speaking, though, your browser should catch on after you close the fundraiser a few times, or so I have read, regardless of whether you are logged in or not. Intelligentsium 23:41, 17 November 2010 (UTC)
It could be suppressed by a cookie - wikipedia wide, wiktionary wide etc.. It's not a big deal but every time you visit another wiki, use a different browser, or change accounts, there he is... Rich Farmbrough, 09:58, 19 November 2010 (UTC).
Thank you Intelligentsium (and hi haven't typed you in a long while :P) I wasn't aware of the "Gadget". Mlpearc powwow 13:39, 19 November 2010 (UTC)

Appeal Idea for Jimmy Wales

Dear Jimmy Wales, I saw your appeal on Wiki and think it is a great idea. Unfortunately people who use the internet are strong believes that it's use should remain free which is always less the case. My idea is simple: Offer a small gift (meaningful) to people who donate to save Wiki i.e. if someone donates $20 you could send them a pen drive with Wiki's 2011 most interesting facts/ I'm sure you'll get more donations. Just a thought. All the best, Joe

A similar fund-raising system has been used for several years, and as far as I am aware the foundation is satisfied with the results, so there is no shortage of people willing to donate. Sending gifts to everyone would be highly impractical: I don't think the WMF has the logistical infrastructure for distribution of hundreds of thousands of packages, and given that most of the donations are small amounts, many from all over the world, the freight costs would consume a nontrivial part of the income. For those who absolutely need to get something tangible for their money, there is always merchandise.—Emil J. 12:29, 19 November 2010 (UTC)

Appeal to improve appeals: avoiding excessive personalization

Dear Jimmy Wales, I'm not the guy above and yet I too have read your appeals and I noticed that in the last months I have seen more often your face and appeals on wikipedia rather than the contets I was looking for, so frequent and prominently featured they have been. Could you be so kind to remove at least your face from your appeals? Honestly, it gives a kind of visual impact that is not what a wikipedia surfer is looking for. Of course wikipedia may end up closing for lack of funds, or could not. But in both cases, this is not enough reason to administer us your face features with this by now frankly excessive frequency. Sorry if this is not what you wanted to hear, I'm just being honest and I think that your appeals would be better off if you avoid using them as a proxy for personal fame as a candidate actor - you're by now giving this impression, and I am sure such was not your original intention. It is really detrimental for your intention to couple your appeals so often with face shots. — Preceding unsigned comment added by 94.34.246.114 (talk) 18:54, 18 November 2011 (UTC)

Input randomisation

One of the perennial issues with dispute resolution is not getting enough external input - that is, input from people not previously involved yet willing to take the issue seriously. My proposal is to create a list or category system of Editors Willing To Be Asked For Input (subdivided by various topics, probably similar to the current RFC subdivisions), with a bot choosing a number of editors at random to request their input (via a post on their talk page - or even perhaps via email if possible and if desired by the editor). The input of these editors will not carry any more weight than input from any others, nor will they be required to fulfil any input request; but it would help make RFCs more effective by encouraging a greater diversity of input in the many lower-visibility RFCs. And if it succeeds in making content RFCs more effective, they may be used more frequently and help prevent problems escalating into user conduct issues. Rd232 talk 15:44, 18 November 2010 (UTC)

PS to anticipate one likely response: editors are far more likely to respond to specific requests on their talk page or via email than from monitoring the RFC listings (see the box at WP:RFC) via their watchlist, which is the current approach. Rd232 talk 15:47, 18 November 2010 (UTC)
Why randomize? If people have volunteered, why not just ask all of them? Of course, whether you'd get enough volunteers would be interesting to see.
Also, I see no reason to restrict this to the formal RfC approach. Exactly the same problem applies with the noticeboards. Those are alos in effect RfCs though not formally called that. Peter jackson (talk) 18:12, 18 November 2010 (UTC)
Why randomise? Because for it to work you'd need a pretty big list of users volunteering to be asked (100 minimum), and most RFCs won't need 100 people turning up. Also if people know that, say, 4 other people have been asked, they're more likely to respond; if hundreds of people have been asked, it's more like "news you may be interested in" than a personal request. Why RFCs? because they're structurally well-suited to it, and a good way to test the approach. If it works, applying it to noticeboards may be slightly trickier but probably not all that much. Rd232 talk 18:56, 18 November 2010 (UTC)
"if hundreds have been asked..." needs some evidence. I see it differently: the pool of willing volunteers is too small to randomize (it needs evidence too, like all "we don't have enough..." statements). Why not try a simple subscription that will post, say, weekly alerts on user talk pages. The Signpost already reports on ongoing and pending RFARs, RFCs aren't too different. But someone must review these cases and write brief, palatable outlines - something better then the blurbs on WP:RFC. East of Borschov 11:48, 19 November 2010 (UTC)
RFCs tend to need quicker external responses than that. But for larger ones that need more input, yes, by all means let's write them up and mention them in the Signpost. This then links neatly with Peter Jackson's point further down. Rd232 talk 17:08, 19 November 2010 (UTC)
Sort of like a jury list except elective. Sounds like a very good idea to me. Dmcq (talk) 18:48, 18 November 2010 (UTC)
It's a little bit like that - except that in addition, anyone can get on the jury just by turning up at the court house :) Got to be careful not to let metaphors confuse people: the input so requested has no higher status than any other. Rd232 talk 19:00, 18 November 2010 (UTC)
Does indeed sound useful to attract editors more selectively without excessive spam. —  HELLKNOWZ  ▎TALK 19:00, 18 November 2010 (UTC)
Ive actually been pondering this idea for a while, creating the software for creating the pool of "jurors" is relatively easy, we just need to get a large pool of them and create a structure for requesting a "case" to be heard by them. ΔT The only constant 19:02, 18 November 2010 (UTC)
Cool - but one of the reasons I've talked about RFCs is to avoid creating (or appear to be creating) a new process; this is supposed to make existing processes work better. As part of that, let's please back away from the "juror" / "case" metaphor! The existing RFC structure provides clear questions to be asked; the technical aspect of choosing people at random from a list or category and sending them a message asking for input on new RFC X, involving Question Insert Interesting Question Here, ought to be straightforward, and ought not upset anyone with over-complication, WP:CREEP, WP:NOT, etc. Rd232 talk 19:11, 18 November 2010 (UTC)
I think I understand what this is designed to address (getting more outside eyeballs onto RFCs et al) but I don't think this proposal will result in any improvement in the longer term. The problem is not finding Editors Willing To Be Asked For Input, it is finding Editors Willing To Give Input Who Actually Do So. Take a look around at the many project-space lists of "editors willing to..." and "editors participating in...". They are full of names of editors who are no longer willing, or no longer participating or no longer even have a computer. This list too will inevitably grow to a size where getting actual valid hits will become impossible. Sure, a bot could check for recent activity, but then it would also have to measure responsiveness to decide how many notices should go out. And new people coming along will just look at the huge list of names and think "oh well, there's already 300 people signed up for this" and stay out of it. There's no great harm to have an opt-in list for bot messages but I think the end result will be nothing but a bot running for no great purpose. The editors willing to give outside input probably already do. Finding more of them is a problem, but it is a social problem and automated solutions to social problems (unless they are mandatory, like jury duty or military drafts) rarely work. Franamax (talk) 19:57, 18 November 2010 (UTC)
I understand your point, but I think you underestimate the value-added of this approach. Yes, the bot would take into account recency of editing, so it doesn't matter that the list or category would gradually populate with inactive editors. What matters is that for for active editors approached with a specific request, via talk page or email, knowing they're one of say 5 people asked, is very very different than having an RFC pop up on your watchlist, or having put your name on a rarely-edited WikiProject page X years ago. It's a system for generating engagement with under-served subjects, and if it works for RFCs, we can build on that for other things. Rd232 talk 20:50, 18 November 2010 (UTC)
Yeah, I'm sure not going to put asterisk-3quotes-Oppose-3quotes in here anywhere. I wish I had the discipline to do what I've long considered, slice off a piece of my time every so often to do "volunteer" duty with RFCs. I just don't think I would respond well to a bot nagging at me. I kinda see the value in "you asked to serve, here is where you can serve". But my Hilroy spiral-bound already has lots of "notes to self" in it, and there always seems to be some other current issue, so I guess I would just not opt in. It is certainly possible I underestimate the value-added, and I think it would for at least a short time beneficially increase outside input to RFC's. I'll stand by my prediction that it will collapse under its own weight though, and I'm happy to be proved wrong. Franamax (talk) 22:38, 18 November 2010 (UTC)

Also, one of the advantages of this is that whatever signup system is ultimately used can be linked from welcome messages and such, so it becomes another route to help engage new editors with topics beyond their immediate interest. Turning casual editors into Wikipedians is one of the key things we should be trying harder to do, and I think this would help a little. Rd232 talk 20:55, 18 November 2010 (UTC)

Funny you should mention that, because after I'd commented I was thinking about this from the other end, that there was a risk that it would become part of bauble-collecting, as in "I signed up for NoticeBot 2 months ago, I have a mostly-unplagiarised DYK and I haven't abused rollback for all 3 days I've had it, can I be an admin now?" Dispute resolution is probably not the best area for a brand new editor to get their feet wet (though I'll admit it would probably work out better than trying to defend your article on your garage band). I'm probably far too cynical on that topic and I do recognize it's important to let newcomers know of the many areas where they can contribute. But in the welcome template, as in "you can do this right now"? Franamax (talk) 21:58, 18 November 2010 (UTC)
New users have the patience sometimes to actually read diffs and trawl edit history instead of just !voting "per all the above". But sometimes they don't. Rich Farmbrough, 21:16, 19 November 2010 (UTC).
Yes, I think so. Commenting on content RFCs which they don't have an enormous vested interest in is a good way for newcomers to learn the ropes, I think - and due to the randomness, they're unlikely to be asked immediately after signup. Anything can be debased as a bauble so I discount that. And since contributions to RFCs are less simplistically measurable than eg number of DYKs, it's less of an issue. Rd232 talk 22:21, 18 November 2010 (UTC)
Still not likin' it. There would have to be full disclosure. What about when a new and enthusiastic editor signs up for what they want to treat as an obligation to comment and gets the bot message "You are invited to comment at this RFC" and heads over thinking, hmm, what is a climatic research unit and what is the difference between stealing, hacking and leaking, I know I have to say something? And would there be a difficulty rating system for where the dispute is between two long time article writers who even if you agree with them will chew your head off for small inaccuracies? Random assignment here looks like putting new editors randomly into situations they had no idea even existed, and randomly finding whether they sink, swim or quit. If they know that's what they're siging up for, no problem. Franamax (talk) 23:50, 18 November 2010 (UTC)
Well, as a I said, they're unlikely to get a request immediately after signing up. But more importantly, the aim would be to have several new people involved in any given RFC, and some of them will be more experienced than others. The mere fact that they've been selected by the bot, rather than turned up for no apparent reason, will also help AGF in some of these situations where sock/meatpuppeting is an issue. Also, talk pages of these kinds of articles often have a "controversial topic" warning label or a template relating to arbitration enforcement; which the bot could even look out for and bake appropriately into the notification message. Rd232 talk 00:30, 19 November 2010 (UTC)
I already have some crude "Rota" code for doing this type of task, and I think a rota based system is better than randomised. If the list and response is sufficiently large compared with load it becomes possible to prioritise those who haven't been asked for a while, and those who haven't responded, if desired. This means that any who juts "sit" on the list will get more invites, until they either get involved or pull their name, thus helping to clean the list. Rich Farmbrough, 09:56, 19 November 2010 (UTC).
I like the randomisation for its simplicity and for the philosophical approach (somehow a Rota sounds offputting to me), but I see your point about spreading the load. We'd want to make sure though that the system didn't become predictable. Rd232 talk 11:20, 19 November 2010 (UTC)
Back in 2008, I spent some time (a few weeks I think) responding to lots of RfCs. Often I was the only one. Peter jackson (talk) 11:34, 19 November 2010 (UTC)
Now you mention it, I do recall having the same experience. Do you draw any particular conclusions from this? Rd232 talk 12:07, 19 November 2010 (UTC)
  1. Something needs to be done
  2. It's doubtful whether this proposal would work (though it's a good idea in principle)
Peter jackson (talk) 14:44, 19 November 2010 (UTC)
(a) why is it doubtful? (b) what can be done to make it more likely to work? Rd232 talk 15:01, 19 November 2010 (UTC)
Well, it might depend on the sort of case you're talking about. You said above "most RFCs won't need 100 people turning up". That's probably true, but how would your system distinguish? The cases where you would need 100 editors turning up are those where a cabal of editors own an article. How would the system distinguish those cases from the rest? Especially when you're not allowed to say that a cabal of editors own the article (NPA, AGF). For ordinary cases, I simply think it's doubtful whether you'd get the necessary multiplier. Remember, if I was often the only one responding, then a lot of the time nobody at all responds. You've got a very low baseline to try to improve on. Peter jackson (talk) 16:36, 19 November 2010 (UTC)
See my response above to East of Borschov, which I think links to this rather neatly. The proposal takes care of "smaller" RFCs, with less input required. Where more input is required, a participant will recognise that and can write up a blurb or summary (or just repeat the original question) and submit to the Signpost for wider input (and in addition perhaps a mechanism for additional random requests for input as well). So to answer your main question: the cases where more editor input is needed will be identified by participants, and there should be clear routes for asking for more input. Rd232 talk 17:08, 19 November 2010 (UTC)

Trial

OK, does anyone have any concrete objections to trying this out? The main concern I see is potentially dumping editors into battleground territory, but the input request can include a generic warning and a specific one if any relevant templates are detected on the talk page. And perhaps in the trial phase new editors can be excluded (eg < 100 talkspace edits), til we get some sense of how it works. Comments? Rd232 talk 00:55, 22 November 2010 (UTC)

Using [[diff:$1]] and [[oldid:$1]]

Would it be possible to create these two prefixes as interwikis to refer to certain revision numbers within the wiki, e.g. referring to http://wiki.riteme.site/w/index.php?diff=397820813 as [[diff:397820813]]? I think that there is benefit in doing this, since referring them to certain numbers conserves wiki syntax, what with having to repeatedly use &lt;span class=plainlinks&gt; for such instances, and through easier reference to diffs of other wikis as well, e.g. [[:ar:wikt:diff:12345]]. :| TelCoNaSpVe :| 01:45, 21 November 2010 (UTC)

I would greatly appreciate such a system, provided that it supports the secure server correctly (links to whichever server the reader is using, a la {{FULLURL}}). Also, how would one use both diff: and oldid: in the same link? --NYKevin @273, i.e. 05:33, 21 November 2010 (UTC)
Why would they need to use both? IMO, only one or the other is needed to show a particular revision. :| TelCoNaSpVe :| 05:42, 21 November 2010 (UTC)
You don't have use plainlinks when you make a diff link with a URL. Even if this were done, it would probably see little use (like {{diff}} and {{oldid}}) due to the extra work required to make the links. Mr.Z-man 06:00, 21 November 2010 (UTC)

Adding {{Commons cat}}, {{Commons}} or {{Commons and category}}

Hi! There were no replies here and here, so here is the proposal:

  • Proposal: if an article does not contains {{Commons cat}} or {{Commons}} or {{Commons and category}}, but exists a specific category or page on Commons, I suggest to add these templates.
    • If on Commons exist both category and page (gallery), then {{Commons and category}} should always be preferred over {{Commons}} because Gallery pages are usually poor mantained, there are just few images and the gallery itself rarely add any real value. Categories are easier to mantain and to scale up (adding sub-categories). Moreover well written and well mantained gallery pages are usually already linked from en.wiki.
    • The presence of {{Sister project links}} should not affect the insertion of {{Commons cat}} or {{Commons}} because should be noted that {{Sister project links}} simply "provides links to the 'Search' page on the various Wikimedia sister projects". That means that it does not grant that any related content actually exist, it is just a (blind) guess. {{Commons}} and {{Commons cat}} instead state that Wikimedia Commons actually has media related to the subject and provide a link to it. This is a precious information. It is the difference between the search function and a link.
    • There are several cases where this process can be safely performed via bot. I'm going tring to do it, but nobody cares about this issue and BRFA is waiting...

If this proposal sounds reasonable, please write here (or below): "uhm... sounds reasonable" and sign. ;) Thanks. -- Basilicofresco (msg) 08:45, 21 November 2010 (UTC)

New editnotice: Template:Editnotices/Page/Wikipedia talk:User pages

Due to the recently high levels of spam on Wikipedia talk:User pages, I think that a way to alleviate this problem would be to create a new editnotice warning users not to post advert material onto the talkpage. It would be something along the lines of “Attention: This is the talkpage for discussing changes to the Wikipedia:User pages guideline for user pages, not for advertising material or posting stuff on your own userpage." :| TelCoNaSpVe :| 08:48, 21 November 2010 (UTC)

I have no objection, but it probably won't stop them ;) Anomie⚔ 15:10, 21 November 2010 (UTC)
Boldly done. Rd232 talk 16:28, 21 November 2010 (UTC)

New Userrights Proposal

I have noticed that there have been several RFA's recently where the candidate needed a particular area of the Administrator tools, but not all of them. Many users find some of the tools useful, but not all of them. There are three major areas of administrator work. I know there have been several debates surrounding splitting up the administrator rights into sections. I propose that several userrights be added. These rights would be granted to trusted users by administrators and/or bureaucrats at Wikipedia:Requests for permissions and revoked by Bureaucrats These rights would not replace the standard sysops right. They are intended to help editors who do work in one particular area where a certain tool normally reserved for sysops would be useful, but don't want the full sysops right. It would also decrease the "authority gap" between administrators and non-administrators. Here are the rights I propose: Thoughts? --Alpha Quadrant talk 19:04, 27 October 2010 (UTC)

As a general note we'd be fools to think that block, deletion rights, and ability to give user rights to other people would not be the most controversial rights in all of this. If this is the hang up for you, just mention you'd support this assuming right X is excluded from the bunch. "File Uploader" would still be an amazing right to have for file uploaders without deletion rights, and "Patroller" would allow vandal fighters to be all that much more efficient at it, even without the ability to block them. If the rights are modular rather than bundled up, those who want to (for example) do cleanup in files or templates wouldn't have to have to have their enthusiasm crushed because of opposes such as "Well I like your file work, but I don't think you have enough vandal fighting experience to get the tools" or similar and told "come back 6 months" or some other arbitrary delay. Headbomb {talk / contribs / physics / books} 20:06, 27 October 2010 (UTC)

My proposed tools, by no means be given out like rollback. There would be a strict process of evaluating whether or not a user can be trusted with a specific tool. It is not meant to replace RFA and likely never will. Giving out module tools are only meant to make trusted editors who don't have enough work in specific areas. The community normally wouldn't be able to safely agree to giving the editor the whole administrator bundle. This proposal would potentially eliminate the accused "caste system" that many new users assume exists. It could potentially make RFA run smother, by having a admin hopeful apply for a module first, then later applying for adminship it would make it easier for the community to evaluate the editor. Naturally editors will be prohibited from gaining access from all three modules without a proper RFA. There willl still be several tools limited to the administrator group: Editfilters, editing interface, and other's .js and .css will remain restricted to administrators. The tools would be easier to remove than a full administrator because any bureaucrat could remove them if they are ever abused. The standards would be somewhat lower than a RFA because only part of the tools would be given. Hersfold pointed out one issue in the proposal. If the module idea succeeds issues like this would eventually come up: if a editor with the "Purge" module comes across a persistent attack page vandal they would be unable to block them. The editor could file a report to AIV so that a full administrator or a "Patroller" blocks the vandal. This would be no different than what a rollbacker does when they find a page that comes across persistent vandalism on a page, they file a request at RFPP.

Proposed User rights
*The first three proposed rights would be granted by either a Administrator or Bureaucrat and revoked by a Bureaucrat if abused. The "Flooder" and "File Uploader" would be granted and revoked by Administrators at Requests for permissions. See relevant pages and below for details.

Relevant pages:

  1. Wikipedia:Guide to requests for tools
  2. Wikipedia:Requests for tools

Patroller - Antivandalism fighters who patrol recent changes and revert vandalism. Would be assigned to users who are trusted vandal fighters who have a good record of appropriately warning and reporting vandals.

  • Block a user from sending e-mail (blockemail)
  • Block other users from editing (block)
  • Disable global blocks locally (globalblock-whitelist)
  • Have one's own revisions automatically marked as "accepted" (autoreview)
  • Mark revisions as being "accepted" (review)
  • Mark others' edits as patrolled (patrol)
  • Have one's own edits automatically marked as patrolled (autopatrol)
  • Quickly rollback the edits of the last user who edited a particular page (rollback)
  • Revert all changes by a given abuse filter (abusefilter-revert)
  • Not create redirects from source pages when moving pages (suppressredirect)
  • Show the extended software version information (versiondetail)
  • Not be affected by rate limits (noratelimit)
  • Use higher limits in API queries (apihighlimits)
  • Configure how the latest accepted revision is selected and displayed (stablesettings)
  • Bypass automatic blocks of proxies (proxyunbannable)
  • Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
  • View abuse filters marked as private (abusefilter-view-private)
  • View detailed abuse log entries (abusefilter-log-detail)
  • Override the title blacklist (tboverride)
  • Change the user groups of another user (userrights) +/- Edit Filter managers +/-IP block exempt +/-rollback +/- reviewer

Protector - Users who perform various cleanup tasks such as moving pages and improving articles. Would be assigned to editors who do good work maintenance and content improvement areas.

  • Change protection levels and edit protected pages (protect)
  • Move pages (move)
  • Move files (movefile)
  • Move pages under pending changes (movestable)
  • Configure how the latest accepted revision is selected and displayed (stablesettings)
  • Edit other users' CSS files (editusercss)
  • Edit other users' JS files (edituserjs)
  • Edit semi-protected pages (autoconfirmed)
  • Edit the user interface (editinterface)
  • View a list of unwatched pages (unwatchedpages)
  • Move pages with their subpages (move-subpages)
  • Move root user pages (move-rootuserpages)
  • Not create redirects from source pages when moving pages (supress redirect)
  • Show the extended software version information (versiondetail)
  • Not be affected by rate limits (noratelimit)
  • Use higher limits in API queries (apihighlimits)
  • Override the title blacklist (tboverride)
  • Override the spoofing checks (override-antispoof)
  • Have one's own revisions automatically marked as "accepted" (autoreview)
  • Mark revisions as being "accepted" (review)
  • Mark others' edits as patrolled (patrol)
  • Have one's own edits automatically marked as patrolled (autopatrol)
  • Change the user groups of another user (userrights) +/- rollback +/- reviewer +/-confirmed +/- autopatrolled +/-account creator

Purger - Would be assigned to users who are trusted in New Page patrol work as well as good work in AFD and properly using CSD.

  • Delete and undelete specific revisions of pages (deleterevision)
  • Delete pages (delete)
  • Undelete a page (undelete)
  • View deleted history entries, without their associated text (deletedhistory)
  • View deleted text and changes between deleted revisions (deletedtext)
  • Search deleted pages (browsearchive)
  • Mass delete pages (nuke)
  • View abuse filters marked as private (abusefilter-view-private)
  • View detailed abuse log entries (abusefilter-log-detail)
  • Show the extended software version information (versiondetail)
  • Not be affected by rate limits (noratelimit)
  • Use higher limits in API queries (apihighlimits)
  • Override the title blacklist (tboverride)
  • Have one's own revisions automatically marked as "accepted" (autoreview)
  • Mark revisions as being "accepted" (review)
  • Mark others' edits as patrolled (patrol)
  • Have one's own edits automatically marked as patrolled (autopatrol)
  • Quickly rollback the edits of the last user who edited a particular page (rollback)
  • Change the user groups of another user (userrights) +/- Edit Filter managers +/-confirmed +/-rollback +/- reviewer

Flooder - AWB users and users who make extremely high numbers of edits

  • Not be affected by rate limits (noratelimit)
  • Use higher limits in API queries (apihighlimits)
  • Mark rolled-back edits as bot edits (markbotedits)
  • Quickly rollback the edits of the last user who edited a particular page (rollback)

File Uploader - Useful for users who transfer files from Wikipedia to Commons

  • Move files (movefile)
  • Move pages (move)
  • Overwrite existing files (reupload)
  • Upload files (upload)
  • Upload files from a URL (upload_by_url)
  • Override files on the shared media repository locally (reupload-shared)
  • Override the title blacklist (tboverride)
  • Delete pages (delete)
  • Undelete a page (undelete)

Possible Process

  1. To obtain the userright the user will submit a request at Wikipedia:Requests for tools (possible title).
  2. The community will take three (3) seven (7) days and !vote either support of the editor being given the flag or oppose the user being given the flag.
  3. A administrator or Bureaucrat will review the request and grant the flag if there is 70% or higher support

In the event of abuse a Bureaucrat will remove the tools. Example: If Patroller inappropriately block a user it would result in removal of the tools --Alpha Quadrant talk 19:37, 27 October 2010 (UTC)

Discussion

The exact details would need to be worked out in details later, of course, but I'm talking about the general idea. Like "File Uploader" would be pretty useful to have even without the file deletion/undeleting rights. Headbomb {talk / contribs / physics / books} 19:19, 27 October 2010 (UTC)
  • Strong Support per Headbomb and the proposer. The sock that should not be (talk) 19:12, 27 October 2010 (UTC)
  • Support. However, the 'purger' group won't be made, I think. per MGodwin, the WMF will not allow viewdeleted to be given without community input. → ROUX ₪ 19:14, 27 October 2010 (UTC)
  • (edit conflict) I have never been a big fan of splitting the core rights (block, delete, protect). If one is trusted to block, one should be trusted to delete and protect, and so on. Use of these admin tools should be sought at RfA as at present. Viewing deleted material is a definite no per an announcement by Mike Godwin in 2008. There are some less damaging rights that I think could be given to a lower-level group, but this isn't the proposal here. PeterSymonds (talk) 19:16, 27 October 2010 (UTC)
  • I like the idea but have issues with the details. Specificaly the block button of patroler & the delete button of purger. I don't support these being handed out without community input. The key problem with the block button, there's no technical way to separate the ability to use it for simple vandalism blocks and the highly difficult area of blocks of established users for more controversial reasons.--Cube lurker (talk) 19:21, 27 October 2010 (UTC)
    Well it could always be configured so that the "patroller" can only block IP's and non-autoconfirmed users. The controversial blocks, or rather, the full ability of the block button, would be in a normal administrator's jurisdiction. The sock that should not be (talk) 19:23, 27 October 2010 (UTC)
There could also be a special request for permissions where the community decides over the course of, say three days, over whether they think the editor can be trusted with the flag. That would also allow the "purger" right to be permitted. Naturally it would not be as difficult as a RFA. --Alpha Quadrant talk 19:27, 27 October 2010 (UTC)
  • Neutral (having seen more information, this is where I will stay). Abstain for now because I want to see more details. Previous opinion was: Oppose this proposal as currently stated. Not just because of the user-rights, but because of the fact that it's handed out by admins with no community approval. You say that they're not a replacement for admin userrights, but "block" and "delete" are probably the two most controversial tools, and I would say that if you give one person both of those things, they're effectively an admin, and I am uncomfortable with the idea that an admin can just make a bunch of new almost-admins with no community input. At most there should be an RfA-like process for granting these userrights. I may change my opinion if this is rewritten to include an RfA-like process. I should add that it's the groups beginning with "P" that are the most worrisome. "Flooder" may be a good idea, as it exists already on Simple and some other wikis, and though I think we don't have as much need for it here, that doesn't mean it would be bad. —Soap— 19:29, 27 October 2010 (UTC)
  • I at first thought this was a way to help get anti-vandal patrollers with little content creation experience an easier path to adminship, but now I see this is really for specialist admins, since an anti-vandal candidate really needs all of the tools (or at least the three "P" packages) and not just some of them. As such, I don't have a firm enough opinion to be able to comfortably put myself in the "support" or "oppose" column and will remain neutral. —Soap— 12:46, 28 October 2010 (UTC)
And what exactly would make this different from electing an admin, praytell? Choyoołʼįįhí:Seb az86556 > haneʼ 19:39, 27 October 2010 (UTC)
Because it's only certain tools, not the full admin bit. The sock that should not be (talk) 19:42, 27 October 2010 (UTC)
Not all editors want/need all of the tools. However some users would find particular rights useful for their work. Patrollers would find the block tool useful when they are fighting vandalism. Rather than running complicate RFA process for one tool they would find useful and the rest of them not so useful, they could just request the tool they needed. If they required all of the tools they could run a RFA. --Alpha Quadrant talk 19:46, 27 October 2010 (UTC)
Look at the list. It's "an admin who can't delete" or the like; anyways, I meant... "socially"... the "dynamic"...? If I hear somebody gets the block-hammer, I don't care what the flag is called. Same scrutiny, same discussions, same reasons. Choyoołʼįįhí:Seb az86556 > haneʼ 19:45, 27 October 2010 (UTC)
  • Why not seven days? Or fourteen? If anything, I'd expect these RfT's to be less attractive to potential voters than full RfA's, and the votes would come in more slowly. Not trying to harass, but just to get at the ideas behind this proposal. —Soap— 19:40, 27 October 2010 (UTC)
Good point Soap, I'll increase the suggested number of days. The number was just a suggestion. --Alpha Quadrant talk 19:47, 27 October 2010 (UTC)
  • Oppose. I agree with PeterSymonds. Someone who can be trusted with one administrative tool can be trusted with all of them (including those that he/she doesn't intend to use). If adminship requests are being rejected on the basis that candidates will make frequent use of only some administrative tools, we should address this flaw in the RfA process. —David Levy 21:49, 27 October 2010 (UTC)
That's just not true. If that were the case, people would not be rejected for RfA when they want vandal fighting tools, but are opposed for not having experienced in deletion, or content work, or whatever. Modular rights is the only way to fix RfA, because as it stands, people are denying RfA candidates the tools they request, because they wouldn't trust them with tools they wouldn't use anyway . Headbomb {talk / contribs / physics / books} 22:05, 27 October 2010 (UTC)
I referred to a hypothetical scenario in which an adminship request is rejected because the candidate intends to use only some of the administrative tools. Actually distrusting someone with certain tools (irrespective of whether he/she intends to use them) is an entirely different matter.
The various aspects of adminship are heavily intertwined and difficult to isolate, so I believe that a reasonable understanding of Wikipedia as a whole is essential for someone possessing most of the individual tools in question. If a prospective administrator wishes to concentrate primarily or solely on one area, that's fine, and I don't regard that as a valid reason to oppose his/her adminship request. But if someone knows so little about a key process that the community actually distrusts him/her with relevant tools, that's an indication that he/she should gain a better understanding of the site as a whole. —David Levy 22:47, 27 October 2010 (UTC)
And I'm talking about actual cases. The problem isn't the candidates are grossly unfamiliar with Wikipedia, the problem is that the candidates have preferences, and just don't care about some of these tools. Vandal fighters are denied tools because they aren't experienced in deletion debates. Template editors are denied them because they don't have content work. AfD/MfD/etc...-types of admins are opposed because of lack of vandal fighting. Were RfA sane, or the tools unbundled, this would not be a problem. If Jimmy Longpants is an expert template-writer, with no history of edit wars, etc... what does it matter if doesn't have lots of experience with CSD criteria or vandal fighting? Maybe you wouldn't oppose him for that, but tons of people would, and that makes the difference between Wikipedia seeing it's more clueful editors being empowered, rather than disfranchised. Headbomb {talk / contribs / physics / books} 23:23, 27 October 2010 (UTC)
Then the solution is to make RfA "sane," not to overcomplicate something intended to be "no big deal."
Below, Mr.Z-man points out some significant flaws in the proposed setup. —David Levy 01:55, 28 October 2010 (UTC)
I have revised and crossed off the rights that caused concern. The undelete would require WMF approval before being set up. This proposal is about whether or not creating such a right is supported. None of the rights would be given out lightly. The reason Bureaucrats should only be able to take away one of the userights is so that administrators would not be able abuse their position in a dispute. If the tools were given out by community consensus they shouldn't be revoked without community consensus, except in emergency cases. "Removal Administrator discretion" would not work. Instead of having to wheel war all the admin would have to do would be to remove the editor's rights because they were a full administrator and the other editor wasn't, therefore the opinion of the full administrator is correct. This would more than likely occur eventually, hence the issue. Bureaucrats are trusted to remain civil and do a pretty good job gauging abuse and violations of policy, whereas administrators are more likely to lose their cool and make those kind of threats. For example, there are quite a few reports of block treats at AN/I. --Alpha Quadrant talk 03:04, 28 October 2010 (UTC)
Please see Mr.Z-man's message from 28 October at 01:23 (UTC) for some concerns that haven't been addressed. —David Levy 03:49, 28 October 2010 (UTC)
A poll on the village pump isn't really the best format for a complex proposal like this (and it will almost certainly need a larger discussion before any implementation, but my opinions:
  • Weak support patroller - There are some unnecessary rights here - ipblockexempt, proxyunbannable (which does nothing on Wikimedia sites, since we don't use MediaWiki's proxy blocker), stablesettings (this is closer to protecting than blocking), versiondetail (what?), +/-rollback and +/-IP block exempt (this is an administrative task, not a antivandal one).
  • Oppose protector - There's not a high enough volume of admin work regarding protection to justify this. editinterface, edituserjs, and editusercss should be restricted as much as possible due to the potential damage if abused. Ideally, not even all admins should have it.
  • Oppose Purger - Won't happen unless undelete/deletedtext are removed, which would then lead to a situation where users couldn't undo their own actions
  • Oppose Flooder - This is essentially bot, without a few rights that don't really matter because most users already have them or won't need them. This basically creates a way to bypass the bot approval process.
  • I re-read the list and saw the proposal was to give markbotedits and not bot. In this case, its just pointless. The only rate limits that affect established users are 8 pagemoves per minute, 200 emails per day, the account creation throttle, and 100 rollbacks per minute (for rollbackers); normal edits aren't limited at all. These aren't something that people are going to run into with AWB.
  • Weak support file uploader - I would support this as "file mover" if delete/undelete are removed. upload_by_url is disabled here.
Also, if admins can add the rights, they should be able to remove them. This will help to make these less of a big deal à la rollback. Mr.Z-man 22:30, 27 October 2010 (UTC)
Something needs to be done about this according to this and this it has been going on since at least 2005. Something needs to happen. Splitting the core administrator components would be extremely useful. There are four components to the Sysops group, Deletion/Undeletion, Protection/Page Moves, Block/Unblock, and reverting aka Rollback (which, after a long debate was finally given out to non-admins). Not all users want to do all admin tasks. The modules would not be given to users without support from the community. It would actually make it easier for editors to do tasks. There are basically three aspects of the administrator's job. All editors fall into one of the categories. They either primarily fight vandalism (patroller would particularly help them), spend much of their time improving article content (protector would help them with their article work), and new page patrollers/article taggers, users who CSD articles and nominate articles for deletion as well as tag article problems (Purger would help them delete attack pages as well as other inappropriate content. Undelete would be useful in allowing them to undo their action when they make mistakes). This is why I think addingg userights would help. --Alpha Quadrant talk 23:55, 27 October 2010 (UTC)
The simpler solution is to make it easier to lose adminship. One potential risk with splitting it up is that it might make it harder to get full admin rights. I can imaging RFA votes like "Oppose - candidate hasn't demonstrated need for blocking, should only get protector and purger." And of course, there's the golden hammer issue; in many cases there are multiple ways to deal with an administrative issue. Someone without full admin rights may use a suboptimal solution because that's all they can do. Mr.Z-man 01:23, 28 October 2010 (UTC)
I don't think making it easier to lose adminship would make it easier to pass, but that's a debate for another page, such as the WP:CDA proposal. (Indeed, my thoughts have been expressed there already by me and by others.) —Soap— 13:20, 28 October 2010 (UTC)
  • Support patroller - I can see a definite use for that, but quite frankly, I'm not sure about the other stuff. I'm also not sure; do these people really need to be able to assign userrights? There are 1,700 admins; surely they can be responsible for that. Ajraddatz (Talk) 22:51, 27 October 2010 (UTC)
  • Strong support: My main areas of work (when it comes to maintenance) is CSDs, particularly F8's. I have "tagged" hundreds of files and pages for CSD, only to wait for another admin to click the delete button hundreds of times again. I failed the RFA twice as simply being "not ready" in all admin areas; pretty much lost my interest in going for the third. I find special deletion rights very useful to editors who offer to perform specific admin tasks. Rehman(+) 00:20, 28 October 2010 (UTC)
  • Very strong support for the modular rights; the modules and process will need to have the bumps and whatnot ironed out by the community though. Is is just me, or are the admins opposing, while non admins are supporting? 930913 (Congratulate/Complaints) 01:23, 28 October 2010 (UTC)
There is a difference between content creators and new page patrollers/issue taggers. Content creators are more likely to need the protection tool than a new page patroller. Content creator often work on templates (which are often full protected). It is logical for Protection to be in the same module as page moving. In order to move protected pages properly you need also to move the page protection. New page patrollers are less likely going to need to protect a page. In the event they do they can make a request at Requests for Protection. There may be issues where the fields occasionally cross and they need to request help from someone with the right. If it happens often enough they could apply for adminship, or for that particular module. --Alpha Quadrant talk 02:16, 28 October 2010 (UTC)
As discussed above, there also is a difference between needing a tool and being trusted with a tool. Anyone who can be trusted to not abuse the deletion tool can be trusted to not abuse the protection tool (irrespective of whether he/she intends to use it). —David Levy 02:26, 28 October 2010 (UTC)
Yes, there is a difference. However, some users would be trusted with one module, but not the others because of lack of contributions in that particular area. They would get opposes in a RFA due to lack of contributions in a particular area.As I have said before above, if some editors don't need the entire sysops right why should they be discouraged because lack of contribs in a area. It would make it easier for editors to get the tools that they would be trusted with, rather than fighting through a RFA to get a few tools they will use as well as some that they won't. Nothing will happen to the sysops group. What would be wrong with making administrator modules? --Alpha Quadrant talk 02:49, 28 October 2010 (UTC)
As I've stated above, the various aspects of adminship are heavily intertwined and difficult to isolate, so I believe that a reasonable understanding of Wikipedia as a whole is essential for someone possessing most of the individual tools in question. If someone cannot be trusted with one of these tools, I don't believe that he/she should be trusted with any. (It's fine if someone doesn't wish to use some of the tools, but we should be able to trust him/her with the capability.) —David Levy 03:49, 28 October 2010 (UTC)
  • (edit conflict) Support for patroller, but given out by the community rather than a single user. Let's not give userrights to this group, cos that would allow them to grant and revoke every group in existence. The add/remove groups thing is separate, but I know what you mean Support for flooder - concerns of bot editing etc are meaningless, because it's only stuff like rollback that can be marked as a bot edit anyway (IIRC). Should be OK for a single admin to determine this one. Support for protector too, again with community agreement, but I don't like that unwatchedpages is included in that tbh - the info in that is quite dangerous if someone malicious gets hold of it. Weak Oppose for purger, IMHO you can't include deletedtext in that one, which basically knocks the usefulness of this group quite a long way. For the use it'll have, you might as well knock undelete, deleterevision, browsearchive, nuke and deletedhistory too. Which leaves delete as the main function of this group, and will prevent a user from undoing a mistake. So knock delete out too. What does that leave? Weak Support for file uploader, but delete is in there (see above). Yes, a file can be uploaded again, etc, but I see little point in this too, as most of what is in there is probably (IIRC) mainly in the autoconfirmed group (feel free to correct me, as always). I do like the idea of unbundling the rights, but not to a huge extent - this is getting to the far end of unbundling in my opinion. and whoever commented that admins didn't like this, here's an admin who likes the idea in principle [stwalkerster|talk] 02:17, 28 October 2010 (UTC)
    And a cookie to anyone who manages to fix the bold/italics at the beginning of my above comment - I can't see what's gone wrong. :( [stwalkerster|talk] 02:17, 28 October 2010 (UTC) Fixed it :) [stwalkerster|talk] 02:19, 28 October 2010 (UTC)
  • Lemmings! –MuZemike 02:44, 28 October 2010 (UTC)
  • Oppose all These rights do not need to be split. A user gets the package deal by becoming a sysop. Acps110 (talk • contribs) 03:55, 28 October 2010 (UTC)
  • Strongly oppose - and I apologize for TL;DR-ness - for a number of reasons. Firstly, this will not solve the problem it is meant to resolve, that being that non-admins will more easily be able to complete tasks in admin-related areas they are involved in. Yes, someone who does a lot of work in new page/CSD patrolling could benefit from this "Purger" right. Yes, someone who does vandal patrol could benefit from the Patroller right so they could block users. And so on. But in my experience, even if what you're doing falls squarely in one of those areas, you'll often need the other admin tools as well. For example, this: I'm doing new page patrol and notice a user making attack pages. I have Purger, so no problem, page deleted. Five minutes later it's back, so I delete it again. And so on. I don't have Patroller, so I can't block the vandal, and I don't have Protector, so I can't salt the title. What do I do? I go post on AIV and RFPP, and find myself back in the situation I was in before I asked for Purger in the first place. Or, scenario two: I notice this page but don't have any rights. I tag the page for CSD, and the admin who handles the tag not only deletes the page but also blocks the user and adds the page to his/her watchlist in case it needs salting in the future. Much more efficient, no? Very frequently I will start doing one task and find myself doing something that you'd think would be entirely unrelated at first glance. It would be much better for someone to go through RFA, so that they have access to all of these tools, so that they may use them should the need arise.
    Reason the second: let's take that first scenario and say that our hypothetical Purger decides that this is a good reason for them to ask for the Patroller right. They do so, and after a review by the community, they see no reason not to give him the right. Life continues. Our Purger/Patroller finds that they're coming on that scenario multiple times, and would really like Protector as well. So they ask for it, and get it. Now, with access to the block, delete, and protect buttons, they are an admin in everything but name. Are they still held to the same standards as administrators (as established by numerous ArbCom cases)? Likely not, as they don't wield a mop, but rather a large number of Swiffers feather dusters. Are they held to the same level of scrutiny in gaining these tools? Likely not, as they pick them up one at a time. This seems like an excellent way for someone to clear RFA without actually clearing RFA; it'll take a lot longer, but someone that may not be able to pass RFA may be able to jump all the hurdles needed to make themselves an admin with this process.
    Finally, as pointed out before, there are a number of other minor issues with this. Legal issues associated with deleted revisions. Security issues associated with access to Unwatched Pages, private abuse filters, and so forth. Consistency issues that we trust a user with one button that can cause major disruption and drama but not THAT button. And so forth. As most of those points have been made already and I've already rambled on for far too long, I won't go into detail about them, but I do not see this as a good idea, and in fact see it as something that has great potential to cause serious problems. Hersfold (t/a/c) 04:15, 28 October 2010 (UTC)
    I have been informed that Swiffers are better than mops. Fine. I'll call these extra rights "feather dusters" then. :-P Hersfold (t/a/c) 04:20, 28 October 2010 (UTC)
  • So the logic is that because sometimes you need a hammer, and sometimes you need a screwdriver, you're rather have no tools at all than have some of them. Or put differently, you'd rather have 2 people with hammers and screwdrivers, than 2 people with hammers and screwdrivers, plus 5 with screwdrivers, and another 5 with hammers. We lose nothing by letting clueful people have access to tools that would allow them to be more efficient at what they are good at and want to help with. Headbomb {talk / contribs / physics / books} 06:04, 28 October 2010 (UTC)
  • Unless of course one of those people with a hammer tries to use it to drive in a screw, and ends up breaking things worse than if they'd done nothing. When all have is a hammer, everything looks like a nail. Mr.Z-man 14:25, 28 October 2010 (UTC)
  • Sorry, but the "Well since I can't edit mark your edits as patrolled [not a patroller], I'll move a file instead [since I'm a File Uploader]!" seems both pretty damn far-fetched and terribly useless. Remember the big fuss about how rollbacking would be the end of Wikipedia, which would enabling users to revert war at ungodly rates, etc... and how it turned out that we're still here, and we're now pretty glad rollback was unbundled? Headbomb {talk / contribs / physics / books} 16:51, 28 October 2010 (UTC)
  • Not that (file mover is actually the one that I support the most, since its the least intertwined with other tools), more like "This edit war might be better solved by protecting the page, but I can only block, so I'll just block the users" or "This page is getting a lot of vandalism from one IP range, but I can only protect" – cases where it would be better to report it to someone who can deal with it properly, rather than deal with it yourself in a suboptimal way. Mr.Z-man 20:33, 28 October 2010 (UTC)
  • But only one of those is part of the proposed group that includes blocking. The issue (or one of the issues) is that each of these groups only includes one of the major admin rights (except Flooder, which doesn't include any), when, as myself, David Levy, Hersfold, and Beeblebrox have said (to quote David), "the various aspects of adminship are heavily intertwined and difficult to isolate." If people want something like this to do maintenance work, then these are probably still too bundled; the proposals here are basically just the admin package, chopped into thirds. If none of them included the "big" rights (block/protect/delete) and extraneous things like noratelimit, unwatchedpages, and tboverride, and just included specific rights needed to do specific maintenance tasks there would probably be a lot more support. There's no reason we can't have user groups with only 1 or 2 rights. Admin only has a whole bunch of stuff tacked on because that's how MediaWiki was designed, there's no policy for it. Mr.Z-man 04:47, 29 October 2010 (UTC)
  • Oppose, stop with the attempts to unbundle the tools. All it has done is create a whole new class of prizes to reinforce the Reward Culture, passing out tools to unprepared immature editors. SandyGeorgia (Talk) 04:37, 28 October 2010 (UTC)
On the contrary it would finally defuse that culture. Because right now, since we're giving access to all the tools at once, people are paranoid about letting someone who farted once in 2006 touch them for "fear or abuse". Criteria go up, admins go down. Make the tools comes in smaller bundles, and you'll both encourage more people to step forwards and volunteer their skills to improve Wikipedia in various areas (Vandals, templates, files, page patrol, ...), and remove the "monolithic prestige" of getting access to tools. I've yet to see someone fawn over rollbackers and account creators, and I very much doubt patrollers and uploaders or whatever would gain any amount of worship. Headbomb {talk / contribs / physics / books} 06:14, 28 October 2010 (UTC)
  • Oppose; Sandy pretty much hits it on the head. There's a culture developing here where more and more people play Wikipedia like some kind of great big Game with different Levels and Status Points. This isn't the answer. (Not sure I know what the answer is, mind you; this just isn't it.) Antandrus (talk) 04:47, 28 October 2010 (UTC)
  • Oppose as defective. The Patroller (blockemail) (userrights), Protector (move-rootuserpages), and Purger (nuke) would be given rights that should be reserved for sysops and crats. Otherwise I would approve a 3–6 month trial. – Allen for IPv6 06:18, 28 October 2010 (UTC)

Without being a total nag, let me repeat my question (^above): Why do the proponents think that this will not turn into the same "hurdle-drama" as the current process? ("In other words"? sure:) Why would people suddenly quit being suspicious, skeptical, over-critical, have the candidate do the pole-run? What exactly will change? If you could convince me that this will indeed make the process of giving people these tools easier, I could be warmed up to the whole idea. thanks. Choyoołʼįįhí:Seb az86556 > haneʼ 06:30, 28 October 2010 (UTC)

I assume they think people would set the hurdles lower, presumably on the basis of fewer rights = less potential harm. Not that I am a proponent personally. --Cybercobra (talk) 08:56, 28 October 2010 (UTC)
  • Support viewing deleted content, but oppose other I agree some of these tools are too powerful for non admins but why for all sanity can't normal users view deleted content, there is no harm right? why are we censoring people from deleted stuff (this is wikipedia saying no you can't look at that because its offensive/disruptive) this is a nanny culture, if I want to have a laugh reading over deleted content where some user is insulting another user I should be able too, we are all adults here we shouldn't be censored--Lerdthenerd (talk) 13:13, 28 October 2010 (UTC)
    I think it's mainly for the sake of security. Note that there is a type of deletion called suppression (or "oversight") that even administrators can't see. —Soap— 13:17, 28 October 2010 (UTC)
    what about on just articles, I've had users ask me to give them the content on their articles that have been deleted, and I've had to turn them down because I don't have access, confirmed users should have this right so they can have a copy of their deleted work, to work on--Lerdthenerd (talk) 13:23, 28 October 2010 (UTC)
    In an ideal world, there would be enough administrators to handle those requests promptly. We don't have that, but I don't think turning viewdeleted into an automatically assigned userright in the manner of autoconfirmed is a good solution. On some wikis, such as Simple English, the RfA process is much more lenient than ours is, and they manage to survive without the constant disasters predicted by those who oppose loosening RfA standards over here. I think what we should work towards is finding out what they're doing right that we're doing wrong. —Soap— 13:41, 28 October 2010 (UTC)
    Actually, I think viewdeleted is one of the most dangerous admin rights to give someone. With, say, the ability to block or delete, at least it's obvious that someone's abusing it, and you can quickly revert and block/remove usergroups. With viewdeleted, there's neither a log of what was viewed, nor any way to undo its effects. (Being able to view deleted articles you edited/created is a different issue. And is WP:REFUND really that backlogged?) --ais523 15:55, 28 October 2010 (UTC)
    I seem to recall that for legal reasons the Foundation won't give viewdeleted rights to people through processes much less stringent than RFA. Deleted content is supposed to be deleted, not widely viewable. Rd232 talk 15:57, 28 October 2010 (UTC)
whats dangerous about viewdelete? with the other rights you could seriuosly mess up wikipedia if they fell into the wrong hands, with view delete all you're doing is reading, not changing anything.--Lerdthenerd (talk) 11:01, 29 October 2010 (UTC)

Strong support for trial How is not different than when Rollback and autopatroled were unbundled from the admin package. Feinoha Talk, My master 15:36, 28 October 2010 (UTC)

I can tell you how it's different: rollback and autopatrol do not affect other users and you cannot wield power with them; if I don't have rollback, I can use undo which is slower, but w/ the same effect. The crux here are block and delete, at least for me. These can really piss people off if misused. Choyoołʼįįhí:Seb az86556 > haneʼ 16:59, 28 October 2010 (UTC)
We're not going to be handing these rights out to people like candy on Halloween... There's probably going to be strict standards for these tools. What exactly those standards are yet, I don't know. The Thing // Talk // Contribs 17:37, 28 October 2010 (UTC)
Wikipedia:Requests for tools and Wikipedia:Guide to requests for tools is the first draft. The fine details would need to be worked out. --Alpha Quadrant talk 18:00, 28 October 2010 (UTC)
The requirements for the patroller right should be raised significantly, to a few thousand at least. I could get 500 reverts and 500 warnings in a single day if I put my mind to it. I believe one should have vandal-fighting experience spanning about 8 or 9 months at the very least, with few mistakes, particularly 1 or 2 months before requesting the right.The Thing // Talk // Contribs 18:07, 28 October 2010 (UTC)
 Done changed to a minimum of 5000 anti-vandalism edits and 8 month experience. --Alpha Quadrant talk 18:22, 28 October 2010 (UTC)

File Uploader I could see a use for in terms of Commons people, especially Commons admins, getting rights that will make migration easier; though I'd want the rights limited to the File namespace. The others... probably more trouble than they're worth, in terms of complexifying things overall. The vast majority of WP backlogs don't require these rights to handle. Rd232 talk 15:57, 28 October 2010 (UTC)

  • Oppose. This proposal, if implemented, will create more problems that it can solve. I would only support splitting 'movefile' userright into a separate usergroup—it has never been intended as admin only right. Ruslik_Zero 18:59, 28 October 2010 (UTC)
  • No no no even though I wish I have at least one of the buttons again, it has the potencial of being grosly abused. If a user can't pass RFA, is their own fault. I agree with Sandy. Secret account 20:38, 28 October 2010 (UTC)
  • Oppose This type of thing has come up again and again, and has been shot down again and again for the same reasons. Adminship is for trusted users. If a user isn't trusted enough to be full admin there should not be a back door they can sneak through, and they definitely should not be blocking other users. Also, as been stated, admins often use mre than one tool to deal with a situation, such as blocking a spammer and deleting all the spam they have added. Situations that one admin can handle would be require several of these partial admins, or they would have to go find a real admin to finish the job, actually reducing efficiency. Beeblebrox (talk) 20:46, 28 October 2010 (UTC)
  • No means no. Killiondude (talk) 20:57, 28 October 2010 (UTC)
  • Support abandoning the idea of "adminship" Opposers keep saying things like "this is a back door to adminship". That completely misses the point. We shouldn't have anything called "adminship". It's been a major cause of misunderstanding that we've taken this bundle of technical permissions and called them something that is traditionally associated with additional authority. The only way we can fix this is to make it clear that it is indeed just technical permissions. I think it will actually eliminate "level upping" if we remove the heirarchy aspect of it by unbundling the significant functions. Of course the more sensitive functions like blocking and deletion will have higher bars, just as checkuser is harder to get than rollbacker. Gigs (talk) 21:20, 28 October 2010 (UTC)
  • Support some bits of this RFA is broken, our number of active admins is dwindling and has dropped from 1,021 to less than 800 in the last two and a half years. At some point things will have to change, however unpalatable the idea of change is to some. I would prefer that we as a community reform ourselves before things reach crisis point, not least because a gentle change of direction in good time is usually smoother than a last minute panic. I think these particular solutions are over complex, involve too many rights in each package and have odd mixes of content creator and vandal fighter. My suggestion for the next unbundled right would be the block button, it is the second most heavily used admin tool, but the one where we need to always have people available who can block vandals. If we create a block button that can only be used against IPs and autoconfirmed editors then I believe we have created a useful group of users, and I would hope that the "must have a GA or FA" brigade could tolerate the appointment of trusted vandalfighters to this role. Most AIV reports could be resolved by such users, and it wouldn't matter if occasionally they left a few speedies for an admin to delete - the urgent thing is to stop the vandal in mid spree. ϢereSpielChequers 21:45, 28 October 2010 (UTC)
      • Limiting rights by domain is more likely to get community approval. I suggested File Uploader with rights limited in software to File namespace; block tools limited in software to use against IPs and non-auto-confirmed might get my vote too, though there would be concerns about encouraging WP:BITEyness. Rd232 talk 11:57, 29 October 2010 (UTC)
    • I noticed your the only adminstrator supporting this proposal so far, all the other people supporting are non-adminstrators, that tells us that people are interested in the tools, but won't be willing to go though RFA. We need to fix RFA back to the standards of a few years ago, where it was more forgiving for an editor who make mistakes, not give out admin tools. Right now it's impossible to forgive any editor who does one messup in a question, or made poor decisions that led to desysopping (like myself). Secret account 22:22, 28 October 2010 (UTC)
Secret, User:stwalkerster is also a administrator as well. Also, being a administrator is not a supervote. --Alpha Quadrant talk 00:00, 29 October 2010 (UTC)
      • To me that's exactly the problem. "Becoming an administrator", "being an administrator". It's just a bit in a database. It doesn't define you as a person or as an editor. We used to call it "the bit" more often to remind everyone what it really means. The normal non-wiki connotation of the word "administrator" has tainted things, I think. They should have given it a silly name like they did to the bureaucrat bit. Gigs (talk) 01:52, 29 October 2010 (UTC)
        • Err, being male/female or dead/alive are just "bits in a database" too, but that doesn't mean they're unimportant. It's time to retire the "just a bit"/"only a mop" analogies. They're misleading, like pretending an injection was "only a little prick" in the days before disposable needles. - Pointillist (talk) 11:37, 29 October 2010 (UTC)
  • Very much oppose because this is now the fourth time I've seen a discussion over this within the past few months. The consensus is and has always been a resounding "no". Someone address all my concerns at Wikipedia talk:Vandal fighters#My opinion (which apply not only to vandal fighter semi-admin rights, but to all such proposals) and I'll support. But this is becoming forum shopping by many users (intentional or not), and there are still two threads on WT:RFA related to separating rights, too, neither of which has any consensus at all. Someone tell me, also: why should we be making more convoluted RfA-type processes without first fixing RfA? and to take TTTSNB as an example, why should I trust him with extra rights when he has not listened to users who ask him to work with content more? If I cannot trust him with delete, I see no reason to trust him with block, because they are based on similar principles. If a user only CSDs articles as his or her onwiki-work, why should they get the delete ability if we cannot trust them with blocking or protecting? Everything crosses over; you either know all the major policy or you don't, and you either get all the rights or you don't, because something could seriously go wrong, especially without any standard desysop or de-right process. /ƒETCHCOMMS/ 01:28, 29 October 2010 (UTC)
  • Support the idea if not so much the implementation. The idea of giving out admin abilities separately is one that's been around for a while. I've broadly supported it, but the general consensus has been to keep the status quo, which hasn't been particularly bad. I think that though it may be decried as "game-like" in some ways, having a clear path from low trust and responsibility to the broad rights and trust of an admin seems like a good idea that would help cut the stress of going for the full spectrum of admin rights. I particularly like the idea of task-oriented packages, which is something that genuinely adds to the proposal. I don't think, however, that we ought to jump straight to accepting some particular set of packages: we need to settle upon some principles first for what rights these packages ought to include. For example, I think that the ability to undo one's own actions is important, and I would not support the "delete" right being given out without "undelete". However, "undelete" has implications in that it is important on a higher level that we carefully vet who gets it because of the nature of deleted content. I think that this is a good idea, but let's, well, edit this proposal. :) {{Nihiltres|talk|edits|⚡}} 01:45, 29 October 2010 (UTC)
    • You'll have to forgive me, but I find the idea of admins being trusted to be a little bizarre. Trust might come with accountability, but that's lacking at the moment. Malleus Fatuorum 01:53, 29 October 2010 (UTC)
      • You'll have to forgive me, but I find the idea of admins not being trusted to be a little bizarre. There are endless ways that an admin could cause major damage to the encyclopedia if they used their administrative privileges inappropriately. Leave the "accountability" drama for another day: it has very little to do with this discussion. {{Nihiltres|talk|edits|⚡}} 04:00, 29 October 2010 (UTC)
        • You've just demonstrated very nicely how out of touch with reality you are. The fundamental problem that needs to be addressed isn't whether or not vandal fighters should be given right X or Y, it's that admin is effectively a job for life. If it wasn't, then all of the rights could be handed out (and of course taken away) without all of this recurring babbling nonsense. Malleus Fatuorum 13:41, 29 October 2010 (UTC)
          • Concur. All this would be unnecessary if there was a way to easily desysop in case of abuse; as it stands, people given the bomb (it really is called NUKE) and there is no way to take that away from them again (yeah, yeah, in theory, there is, but it doesn't happen in practice). Instead of arguing over splitting this, just make desysopping easier. Choyoołʼįįhí:Seb az86556 > haneʼ 15:17, 29 October 2010 (UTC)
          • Malleus, the "out of touch with reality" bit was rather unnecessary. I think that the "job for life" issue of adminship is tangential to this discussion, but if you really want to bring it in, I think it rather supports the idea of role-oriented rights packages. The reason that English Wikipedia doesn't have a good policy for desysopping is that it's very dramatic. It's a Big Deal, or at least a great deal is made of it. By allowing the rights to be assigned with greater granularity, at least some of the drama can be removed. For example, suppose we have an admin who has abused the block button a couple of times: we might remove adminship but grant one or more of the other packages, meaning that the user would be free to continue productive admin-type work in other areas. The social damage inherent in the removal measure can be minimized. Lowering the barriers to gaining admin privileges (which this initiative would arguably support) will also help lower the barriers towards removing them (which you seem to argue is highly desirable). {{Nihiltres|talk|edits|⚡}} 16:25, 29 October 2010 (UTC)
  • Support the idea of Patroller I support the idea of Patroller as it can help with many antivandalism fighters, however, the practice can be debated quite heavily. The others I feel neutral at the moment.--iGeMiNix 02:22, 29 October 2010 (UTC)
  • Support In principle. I'm not particularly interested in adminship, but would like to have some of the "Protector" tools, especially the ability to move pages over redirects. This would allow me to do more maintenance work myself rather than having to hassle an admin every time I need it done. Sasata (talk) 03:05, 29 October 2010 (UTC)
  • Support Protection Rights but not the others. Deleting and blocking are harsher than protection. But in my point of view, I think it is safe to only semi-protect pages, and unprotect those with the grey padlock, as autoconfirmed non-admins can still edit a protected page. However, I wouldn't give protection rights to users who have an intention to protect the sandbox, unprotect the Main Page or any licensed text like this for example. To sum it up, I would think protectors would only be allowed to put or drop the grey padlock. Minimac (talk) 14:36, 29 October 2010 (UTC)
What about adding and removing Pending changes protection? Assuming that it remains implemented. --Alpha Quadrant talk 15:20, 29 October 2010 (UTC)
Oh yes, I forgot about that because I'm not a reviewer. I think pending changes protection should be allowed for protectors too, whether or not the reviewer right is granted. Minimac (talk) 12:19, 2 November 2010 (UTC)
  • Support File Uploader, Patroller, Protector and Flooder per WereSpielChequers and Stwalkerster. —Ғяіᴆaз'§Đøøм • Champagne? • 12:27pm • 01:27, 30 October 2010 (UTC)
  • Extreme support! It could help in the clearing of administrative backlogs. Also, it may improve the response time for some incidents. I believe that this is an excellent proposal, and, as said before, not all admins use all admin rights, and so, a RFA would also make it more difficult for them to help. As for Patroller, if you notice, many rollbackers are reviewers, and this right gives them both, as well as a few other anti-vandalism tools. Hazard-SJ Talk 16:37, 30 October 2010 (UTC)
  • Strong support; I feel that these would be valuable tools to put in a few more hands, and avoiding the problem of concentrating all rights in one user role (administrator) which have been discussed over and over again... : Not handed out to the masses, but at least with community scrutiny slightly less painful than the hell-week of an RfA, we can get more good people to do these valuable jobs. My personal preference would be to tweak some of the details by removing a small number of rights from these proposed roles (for instance, if "Patroller" is a vandal-fighter, do they need to subsume autopatrol which is for content creation, and already an established user role?). I'd rather move away from bundling rights. Crossing a small number off the list might help assuage some other people's concerns too. bobrayner (talk) 17:01, 30 October 2010 (UTC)
  • Support in principle, with the details to be discussed by the community later. shoy (reactions) 13:45, 1 November 2010 (UTC)
  • Oppose all—perhaps a trial, but this seems like something for the trophy collectors. Also, it would cripple our abilities to deal with multiple problems (from the same user) at once. ǝɥʇM0N0 04:43, 12 November 2010 (UTC)
  • Question I've just wondered. Has the rollback button been unbundled in the administrative package a few years ago? If so, then that could be the reason why some people may be opposing this proposal. Minimac (talk) 13:24, 12 November 2010 (UTC)
  • Support. I initially proposed the "Patroller" and "Flooder" rights as well. Frozen Windwant to be chilly? 00:54, 16 November 2010 (UTC)
  • Support - I mostly support this however I also think that most of the items could/should individually granted. With over 150, 000 edits I should have proven myself worthy of doing things like editing protected pages, Not be affected by rate limits (noratelimit), Use higher limits in API queries (apihighlimits) and various others eventhough I long ago lost interest in becoming an administrator. --Kumioko (talk) 05:42, 26 November 2010 (UTC)

Trial Proposal

Ok, I now put forward this question, should we create these rights to enable them for a trial as was done with Pending Changes? —Ғяіᴆaз'§Đøøм • Champagne? • 7:49pm • 08:49, 3 November 2010 (UTC)

We would need Wikimedia Foundation Permission in order to create the Purger userright. --Alpha Quadrant talk 13:29, 3 November 2010 (UTC)
Why? --Yair rand (talk) 00:57, 4 November 2010 (UTC)
It is against Wikimedia foundation policy to give users non-administrator users the ability to view deleted content. In order implement the purger right it would be required for the Wikimedia Foundation to give their approval. So it would need the Wikimedia Foundation board approval. I sent a email to Jimmy Wales last week asking for WMF contact information, but I haven't gotten a reply yet. --Alpha Quadrant talk 01:29, 4 November 2010 (UTC)
I propose three options for the vote. Oppose (self explanatory), Support principle oppose bundles (SPOB) (Support the principle of bundling rights, while disagreeing to the proposed bundles) or Support (Support principle and agree with above bundles)

{| class="wikitable" |- ! Oppose !! Support principle oppose bundles !! Support |- | 0 || 2 || 0 |}

SPOB and suggest a page where users can propose new bundles, explain them, and then have bundles with community consensus passed. 930913 (Congratulate/Complaints) 00:46, 4 November 2010 (UTC)
SPOB This "vote" or whatever this is is doomed to fail because what we're voting on is ill-defined. The best thing to do would be to work on a draft for a "Request for tools" or similar, and when the draft is finalized, submit each individual bundles to community approval, otherwise some will oppose them all because they oppose one. And because blocking and deletion will monopolize the opposes, let's just remove them from the proposed bundles immediately. Headbomb {talk / contribs / physics / books} 01:07, 4 November 2010 (UTC)
Rushing to get this implemented will likely result in it failing. This vote is probably not the best way to get consensus. I will start working on a proposed process. Would anyone like to help me write a second draft? I will set up a issues section on the wikipedia talk page for any issues or concerns editors might have about the draft so they can be addressed. If you would like to assist in the drafting before we submit this for broader consensus, please list your name below: Alpha Quadrant talk
May I suggest making bundles by a similar means to the fundraising banners? 930913 (Congratulate/Complaints) 01:56, 4 November 2010 (UTC)
Creating dozens of userrights would make it more difficult for editors to understand. By creating these userrights it would make it easier for editors to do their jobs, not make it more confusing. Making custom userrights for each user would just create confusion. --Alpha Quadrant talk 13:38, 4 November 2010 (UTC)
Dozens may be proposed, I would imagine no more than a few gain community consensus though. I fail to see how getting consensus on each proposed bundle before use will make it confusing. Where did custom userrights come from? 930913 (Congratulate/Complaints) 21:53, 4 November 2010 (UTC)
Writing a Request Process 2nd Draft
  1. Alpha Quadrant talk
  2. I'd be happy to help. Mr. R00t Talk 02:01, 9 November 2010 (UTC)
Oppose as per my comments above and isn't voting evil? -- d'oh! [talk] 01:52, 4 November 2010 (UTC)
Oppose - I think there may be some potential user groups that might make things easier for some non-admins to do work, but this isn't the way to go about doing it. It doesn't really seem like a lot of thought was put into these groups. "Protector - Users who perform various cleanup tasks such as ... improving articles" - That's like 95% of users. Before creating a new user group, there needs to be some sort of specific problem that its solving and a justification for each right in the group. It doesn't have to be a "bundle" - if just having one right would be useful, we can create a one-right group; it doesn't need to be filled with useless junk just to make it seem better. Mr.Z-man 19:50, 4 November 2010 (UTC)
So rather than oppose, you want SPOB. If we choose bundles by similar means to the fundraising (see above), the proposers would have to justify the need for any bundle and the need for each right, otherwise the community would oppose it. 930913 (Congratulate/Complaints) 21:53, 4 November 2010 (UTC)
Not really, I disagree with more than the specific bundles. I think the entire process here is completely flawed. Its starting from the wrong point. The question here seems to be "Should we have bundles? If so, what should they be?" The first question is pointless. We already have rollback, accountcreator, edit filter manager, and autopatrolled. We don't need to go out of our way to come up with new user groups. If there's going to be any sort of process about this, it should just be asking users what they personally would find useful, then determining what groups might be possible to help those users. If the idea is to simply split up the admin tools based on some hypothetical situations, then no, I would just oppose it completely. Mr.Z-man 22:52, 4 November 2010 (UTC)
There is only one usergroup that can be created—'filemover'. It already exists on Commons and would be useful here. Ruslik_Zero 19:53, 5 November 2010 (UTC)
  • Oppose I just know that some drunken editors will be thinking "OK, my objective is to block as many users as I can within one week". This idea of a timed trial can still cause as many problems as say when you do get the admin privilege; you can still cause a lot of harm to the encyclopaedia. Minimac (talk) 14:58, 19 November 2010 (UTC)
  • Oppose Was some thought actually put into this proposal, or was it made up in 30 seconds of giddy excitement? This whole thing is flawed and unnecessary. ----Divebomb is not British 18:33, 23 November 2010 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_66&oldid=1147947191"