Wikipedia:Village pump (proposals)/Archive 57

Let's use these holidays to make a difference, and try to clean out the Category:Pages with broken reference names.

It was almost empty a month ago, thanks to two dedicated editors and a bot, but there are always new articles the bot can't fix. If we make an effort, each of us taking 1-2 articles (more is fine, of course), it will take us no time to fix them. Debresser (talk) 11:54, 24 December 2009 (UTC)

I just fixed approximately 20 of them. I'll come back to it later today. TheWeakWilled (T * G) 16:51, 24 December 2009 (UTC)

I replied to tedder on my talk page about this (there was also a discussion on Wikipedia:Administrators'_noticeboard#the_curse_of_AFD_relisting about relisting, not doing away with relisting):

[I]f a PROD is challenged (turns into an AFD), and the challenger hasn't proved notability in a week, it should just be treated like the PROD wasn't even challenged. If there was no PROD, AFD is just like a PROD, but lasts up to 3 weeks, which is 2 weeks longer than just PRODding!

TheWeakWilled (T * G) 15:52, 24 December 2009 (UTC)

This issue has also recently been discussed (somewhat extensively) at Wikipedia talk:Articles for deletion and Wikipedia talk:Deletion review.
— V = I * R (talk to Ω) 02:24, 26 December 2009 (UTC)

There is a proposal at Wikipedia talk:Articles for deletion#Consolidation which appears to be gaining consensus to move forward. Further participation in the discussion would be appreciated.
— V = I * R (talk to Ω) 02:23, 26 December 2009 (UTC)

I propose to improve Wikipedia to support also XMPP URIs.

XMPP URI (xmpp:) is similar to mailto: and irc: (more information on

So, today, for contact a person/join a chan on Wikipedia:

• It is possible to put a link to a user address with this format: <user>@<host >

[mailto:<user>@<host>]

• It is possible to put a link to join a chan: [1]

[irc://irc.freenode.net/wikipedia]

With XMPP URIs :

• It is possible to put a link to a user address with this format:

[xmpp:<user>@<host>]

• It is possible to put a link to join a room (XMPP chan):

[xmpp:[email protected]?join]

There are three requests: URI Scheme for contact link/join room and Wikipedia Notifications.

For more informations:

• RFC 5122
  • http://tools.ietf.org/html/rfc5122

• XEP-0045 on XMPP Standards Foundation, XSF (formely Jabber Software Foundation, JSF)
  • http://xmpp.org/extensions/xep-0045.html#registrar-querytypes-join

• XMPP URIs on official XMPP wiki
  • http://209.85.135.132/search?q=cache:9k49nKoctAgJ:wiki.xmpp.org/web/XMPP_URIs+xmpp+mediawiki&cd=37&hl=fr&ct=clnk&gl=fr

• Etension:ExtendAnchorTags on MediaWiki.org
  • http://www.mediawiki.org/wiki/Extension:ExtendAnchorTags

• Extension:Multi-protocol notification on MediaWiki.org
  • http://www.mediawiki.org/wiki/Extension:Multi-protocol_notification

• Intégrer Jabber dans Wordpress et mediawiki
  • http://gregoire.menuel.free.fr/blog/?p=3

— Neustradamus (✉) 14:52, 21 December 2009 (UTC)

This seems to be a proposal to allow a user to receive notifications when specific wikipedia article have been updated through XMPP. It seems like a good idea. Millueradfa (talk) 23:30, 19 December 2009 (UTC)

It's already possible to subscribe to an RSS feed of a page's changes. There's no need to go for another protocol; and it would involve a change to the back-end anyway, so this would have to be submitted through the bug system. — The Hand That Feeds You:^Bite 17:31, 21 December 2009 (UTC)

Notifications is in second point, but about XMPP URIs ? — Neustradamus (✉) 21:44, 21 December 2009 (UTC)

People can you speak about my proposal ? Thanks in advance, regards — Neustradamus (✉) 20:35, 27 December 2009 (UTC)

I'd say the silence speaks volumes. It's not a very useful addition for most people, and it would require the programmers to do a lot of work behind the scenes. — The Hand That Feeds You:^Bite 17:35, 28 December 2009 (UTC)

What work are you talking about? All modern OS and DE like MacOSX, KDE, Gnome have internal support for uri types. If you are talking about wikipedia developers, so it's their work to make modern hi-tech encyclopedia. By the way, Jabber nowaday is the most popular open im protocol, even more popular than IRC, it should be noticed. Nigmatullin Ruslan (talk) 22:38, 28 December 2009 (UTC)

We are currently discussing some tweaks to the section "Wikipedia languages" on the Wikipedia Main Page. We could have good use of some more opinions. See the discussion at

And please don't start a discussion about it here, instead go to that page.

--David Göthberg (talk) 15:12, 26 December 2009 (UTC)

Here's an idea. Various projects like Wikinews and Commons have user-specific categories to allow contributors to organize their contributed content. (See commons:Category:Images by Juliancolton, for example.) Such categories are generally hidden and only visible via a direct search. I was wondering if we could do something similar here. There are really no downsides, AFAICT. –Juliancolton | ^Talk 19:50, 26 December 2009 (UTC)

The thing with the images on Commons though is that there is only ever 1 creator (perhaps 2 or 3 if a derived work is created), but on a Wikipedia article you can have hundreds or thousands of contributors. Lets say on a typical article we have 100 contributors, we add 1 user category for each contributor and an average contributor's user name is made up of 5 characters (arbitrary figures purely for the sake of the example).

Adding a category like [[Category:articles by UserX]] would add 30 bytes of data for each contributor; 100 contributors for the example article makes that 3kb of data. Replicate that across 3 million articles and we have perhaps 9 billion bytes (9 gigabytes) of data added for a non-vital function. Personally I think it is a waste of resources. Road Wizard (talk) 20:26, 26 December 2009 (UTC)

True, I never considered those issues. I suppose we could try to determine who was a primary contributor to the article, but that does seem more trouble than it's worth. Thanks for the reality check... :-) –Juliancolton | ^Talk 20:50, 26 December 2009 (UTC)

Being able to categorize items in your user space is handy, but special:prefixindex can serve that function adequately enough. Otherwise, I agree with Road Wizard. --Izno (talk) 23:32, 26 December 2009 (UTC)

I agree with Road Wizard, unlike files (which rarely have more than 1 major contributor) or news articles (which are only edited for a short time), encyclopedia articles might have dozens of major contributors. You also run into issues about when people can put the category in. Adding a paragraph to a 3-sentence stub would probably qualify, but what about adding a paragraph to an article that's already 5000 words long? What if someone guts an article and rewrites almost the entire thing, are the categories from old contributors removed, as they no longer have any direct contributions to the current version? Mr.Z-man 23:56, 26 December 2009 (UTC)

I made a related proposal a while back that avoids the problem of arbitrary categorisation by basing it on the {{maintained}} template. Basically, article talkpages would be hidden categorised according to the username parameters of the template, so that placing {{maintained}} on a page would categorise it in Category:Articles maintained by Juliancolton and Category:Articles maintained by Mr.Z-man. I did not implement it because I don't have the necessary bot/coding knowledge, but it might be of interest here.  Skomorokh  13:40, 28 December 2009 (UTC)

Is there a reason that the various interlanguage links, on the side bar, on the main page, and in a couple other places, are presented using their native (read: Non-English) format? Am I seriously the only person to find that practice to be confusing? I propose that we change it so that the language shown is in English, although it might be nice to present the native presentation in the tooltip.
— V = I * R (talk to Ω) 21:50, 27 December 2009 (UTC)

It depends on what you consider the main purpose of those links to be. If it is to help non-English readers to find their native Wiki then they should be in the native language. If it is to help English readers to find a Wiki written in a different language then it should be written in English. However, if someone is unable to read a language name in its native script, what use do you think they will find in going to a Wiki written entirely in that script? Road Wizard (talk) 21:56, 27 December 2009 (UTC)

That's a good point, although I don't know how much value there is in catering to non-English speakers here. I think that the value of interwiki links here lies in part in the simple fact that they exist. I mean, to me I find their existence useful even though I never (or rather, very rarely) click on them. Their presence, which simply states "Here's a similar article in language X", has it's own value. That value is lessened by the presentation of the link in it's native format however, since most readers (such as myself) only speak English (or possible one or two others). Links in Arabic and Far Eastern scripts might as well use wingdings, for all the good they do to most people who speak Western languages.
— V = I * R (talk to Ω) 22:16, 27 December 2009 (UTC)

I kinda see both points of view -- for me, the main issue is trying to figure just what some of them are, as the two digit letters are often unrelated to the English one as well (zh for Chinese?). The tool tip idea is a good one, though perhaps the OTHER way would be better -- show the native language, with the translation as a tooltip (which seems to me to be the standard way of doing things for tooltips -- using them as as a guide to what they are referring). ♫ Melodia Chaconne ♫ (talk) 23:13, 27 December 2009 (UTC)

for the sidebar, the use of tooltips to present the text in English would definitely be an improvement. I'm not sure how technically feasable that would be, though.
— V = I * R (talk to Ω) 23:25, 27 December 2009 (UTC)

It seems fairly self-evident to me that these links are targeted at people expecting to be able to read the language; if you can't speak it, or even parse the characters, what possible benefit is there in transliterating it so you can... know you can't make any use of it? We may not have many Thai speakers stumble accidentally across an en.wp article, but when they do it's nice that we can direct them quickly and cleanly to th.wp. Removing that option seems a bit of a waste.

Look at it another way - you have stumbled, by following the wrong link, into an article in Russian. Would you like to see the page contain a link labelled [English], or one labelled [Английский]? There's a reason most websites mark their "other language options" button with a small flag - it's to make it visually obvious to someone who doesn't speak the language what they're looking for.

talk

| 23:10, 27 December 2009 (UTC)

To add to this - if you install

talk

| 23:13, 27 December 2009 (UTC)

Thanks for pointing out the script. I'll probably use that.

I think that the "issue" that I'm bringing up is probably more relevant to the section at the bottom of the main page then it is to the sidebar. I still stand by my points above about the value inherent in the links appearing in the sidebar and a preference for the use of English there, but I definitely can understand the point that both of you are bringing up (although, the point seems very subjective, which is an issue that Road Wizard mentioned above).

It seems fairly obvious to me that the links in the Wikipedia languages section on the main page are primarily targeted at English speakers though. Maybe I should take this discussion to that template's talk page... I thought about that earlier, but then thought that a more general conversation would be appropriate.
— V = I * R (talk to Ω) 23:22, 27 December 2009 (UTC)

Shimgray explained it well. I often go to other language editions to add interwiki links to the article here on the English Wikipedia. Then I use the interwiki links to go back to the English article or to go on to other languages that I speak. If those interwiki links were shown only in Japanese when I visited a Japanese page then it would be tricky to see which link is which. We should supply the same service to the non-English speakers that happen to land on one of our articles here.

Also, as I just explained, it would be harder for us to maintain the interwiki links. I know plenty of users who come here and add interwiki links to other languages, in spite them not speaking any English at all. So change the naming of those links, and less interwiki links will be added and maintained.

V = I * R: You want the links in English since you are curious on where they link, but you don't have to have that, it's not essential for you, right? While the non-English speakers need them, they depend on it.

But I think there should be a tooltip with the English name for the language.

And for full disclosure: I am not a native speaker of English, I live in Sweden.

--David Göthberg (talk) 21:06, 28 December 2009 (UTC)

Hmm, making the tooltip display in the user's selected language (or the project's language if they're anon) sounds like a good idea. EVula // talk // ☯ // 22:20, 28 December 2009 (UTC)

• It would be useful sometimes to be able to find what edit comments contain links to a page. Anthony Appleyard (talk) 22:34, 15 December 2009 (UTC)
• Special:WhatLinksHere. Happy‑melon 15:17, 18 December 2009 (UTC)
• I know about Special:WhatLinksHere. But how do I make it list links from edit comments? Anthony Appleyard (talk) 15:45, 19 December 2009 (UTC)

If you mean Talk pages, you can limit the Namespace of the pages that WhatLinksHere lists.

However, I'd find it useful if there was a way to separate links from References to others, as it is hard to determine where pages like

News Limited are used that is not a reference. Mark Hurd (talk

) 07:02, 20 December 2009 (UTC)

• Sometimes when someone edits a page (article or other), he puts a link in [[ ]] in the edit comment. It would be useful to find such links. Anthony Appleyard (talk) 07:14, 21 December 2009 (UTC)
  • Are you referring to
    edit summaries?  Skomorokh 
    13:33, 28 December 2009 (UTC)
    • Yes, that's how I understood the OP meant by "edit comment". And I agree, it would be useful to find edit summaries that contain wikilinks to main-space pages only because such a list might be useless otherwise -- just clicking "undo" generates an edit summary containing two wikilinks but one is to Wiki space and one is to user space. ~
      talk
      ) 00:36, 30 December 2009 (UTC)

anyone else have ideas? ways to tweak it etc? again i know it sounds stupid, but some form of it could be adapted, i think it could work. i know its just my opinion, but you all know the saying, opinions are like.... everyones got one. MACKDIESEL5 (talk) 06:41, 21 December 2009 (UTC)

It would be easy enough for a bot to do the actual tossing of the coin, and could easily enough be generalized to "3-sided coins" and such if necessary. And having it on-wiki would effectively force everything to be community-visible. As for #8 in your list, it's not the purpose of Wikipedia to be providing "coin tosses" for people playing xbox and crap like that. I have no opinion on the rest, besides wondering whether

WP:3O wouldn't work better for most cases. Anomie⚔

12:59, 21 December 2009 (UTC)

"sometimes both parties may be correct": can you give an example of such a case? I can't imagine people would go for a literal

talk

) 13:12, 21 December 2009 (UTC)

Remote coin flips are actually a very hard problem, not an easy one, if you want them to be fair, trustworthy, verifiable, and cheat-proof. Moreover, you do want them to be all of these things, because if they aren't they're worse than useless - they will cause problems that wouldn't exist otherwise.

From a social-interaction perspective, you can use even a perfect coin-flipping mechanism to cause all sorts of problems and disruption. Most importantly, if something has already been settled in an arbitrary fashion, anyone who disagrees with the arbitrary resolution can try to disrupt the settled issue with an insistence on using a "fair" coin flip - if the issue has already gone against them they have nothing to lose. This would actually prevent issues from being settled. — Gavia immer (talk) 13:41, 21 December 2009 (UTC)

Even if there is consensus on a topic (or lack of it), it can change if a given user provides new and convincing arguments on why should something be done differently. But a flip of a coin isn't ar argument and can't be "refuted". We don't have things decided by "ultimate truths", much less we should have "ultimate random chance results"

talk

) 13:55, 21 December 2009 (UTC)

Very few things are truly arbitrary. Wikipedia is not on a deadline, we should actually take the time to figure out which option is best. If it is really some stupid edit war like over the color of a template and there aren't any issues with accessibility or relevance, the easiest solution is to just go back to whatever it was before the argument started, like we do with units on measurements. Alternately, we could could block the edit warriors for edit warring over something so stupid, then let someone else decide. Mr.Z-man 16:44, 21 December 2009 (UTC)

What you would do with {{Coin toss}} I dunno, but have fun with it. Rich Farmbrough, 03:29, 22 December 2009 (UTC).

Might be easier (and more fun) to set up a Wikipedia Arbitrary Committee: users who will visit a page on request and make indiscriminate binding decisions on the spur of the moment, with absolutely no thought or effort. kind of like an RfC, except intentionally that way. --Ludwigs2 06:50, 24 December 2009 (UTC)

Oppose. We already have

Moved from

WP:AN. ╟─TreasuryTag►UK EYES ONLY

─╢ 16:26, 23 December 2009 (UTC)

There would be no sanctions for not achieving the 33% guideline but meeting it would mean that the user has passed one of the criteria to be a good editor. Editors could manipulate the statistics by using automated minor edits but I'm not concerned about that at the moment. Suomi Finland 2009 (talk) 16:24, 23 December 2009 (UTC)

Completely unviable, and the fact that you mentioned another editor by name is going to cause this proposal to collapse amongst collective bickering. ╟─TreasuryTag►assemblyman─╢ 16:25, 23 December 2009 (UTC)

name removed as not important to the discussion and was only initially provided to explain how the suggestion originated. Suomi Finland 2009 (talk) 16:28, 23 December 2009 (UTC)

Fair enough – but it's still not a remotely viable proposal. ╟─TreasuryTag►Speaker─╢ 16:34, 23 December 2009 (UTC)

What is a "good editor" and why should we be labeling people as such? If you have a set of criteria upon which you base your opinion of who is and who is not a good editor, that is fine. We ought not be in the habit of declaring, as a community, that such-and-such is a "Good editor". Shereth 16:38, 23 December 2009 (UTC)

See my comments below. I've been misunderstood because I did not mean a separate category of "good editor" like we have "good article". I was using "good" in the English language sense, not the Wikipedia lingo. Suomi Finland 2009 (talk) 01:39, 24 December 2009 (UTC)

All editors that contribute in a positive manner to the project are "good editors". We can't go around naming people "good editors" and "bad editors" on the -amount- of contribution. Good editors are those that help improve the encyclopedia, while bad editors are those that vandalize. warrior4321 16:56, 23 December 2009 (UTC)

How are you even defining this? Is reverting vandalism counted (which a large amount of my edits is toward)? I mean, this IS, after all, a completely voluntary project and to suggest that people can't participate in one thing without doing the other is completely against the WP spirit. ♫ Melodia Chaconne ♫ (talk) 17:18, 23 December 2009 (UTC)

What about things that don't fit into either category? Things like templates and user scripts don't always improve articles directly, but they certainly shouldn't be lumped in with RFA and ANI. You also say "one of the criteria" - what are the others? Mr.Z-man 19:37, 23 December 2009 (UTC)

Sorry, I've been misunderstood. I did not mean a new class of user, like administrator, nor a gold seal, like "featured article". Wikipedia has its own lingo so "good article" means something specific, not just good as in nice. My idea was just to encourage people to write articles and, if they are spending 85% on ANI and Wikispace, then they should occasionally think about articles. That's all. No "good editor seal of approval" was I suggesting!

Perhaps a tweak to an optional welcome template where it encourages people to write articles. That's just a thought. Merry Christmas and Happy New Year! Suomi Finland 2009 (talk) 01:37, 24 December 2009 (UTC)

Ok, perhaps the way in which this proposal was put forth made it doomed from the beginning. How about I refocus the discussion to- How can we encourage more editors to contribute actual improvements to articles instead of just trolling around looking for discussions to enter for the purpose of bickering, excessive caring about policies, and over-enforcing to the letter policies for simple purpose of "its a policy, it must be enforced!"? We have all met those editors who when you check their user-contributions they dont "contribute" anything to articles, but yet you see them needlessly go to random articles to "enforce" policy-by-the-letter without knowing the article subject or any consensus' reached on the talk page or in related noticeboard discussions where exceptions for that instance may have been decided upon (IAR allows exceptions!). I for one am sick and tired of arguing about policy with editors (and janitors) who arent on the "front line" of article creation/improvement about whats best, one example is the "Arm-chair editor", who seems to know what should be the "right way" but yet doesnt seem to have ever edited any relevant type of article...Camelbinky (talk) 02:27, 24 December 2009 (UTC)

Some excellent points Camel. It is certainly in Wikipedia's best interest to promote more content contribution but as Melodia pointed out, you really can't tell people what to do with their volunteer time. To encourage more interest in content contribution it needs to be desirable. This is a cultural issue pertaining to how valuable the Wikipedia community views content contributors. How often are content edits (versus "Wiki-politics") evaluated in RFA? How often it is evaluated in ARBCOM elections? How often are content editors praised in the Signpost? It is hardly ever talked about because as a community we simply do not value content contributors as much as we value vandal fighters, AN/I regulars and "wiki-politicians". Barnstars are nice and there is always the altruistic expectation of contributing just for the sake of the greater good but human nature proves that people respond best when they get a "cookie" at the end. There are far too few"cookies" for content contributors but a lot of crumbs and hassles when it come to dealing with the drama and "arm-chair editors" as Camel mentions. It is a culture thing that the entire community needs to address if we expect to see any progress. Agne^Cheese/^Wine 02:41, 24 December 2009 (UTC)

I'm mostly active at FPC and in providing images, but I'd probably be close meeting the 33% including wikiproject edits and article talk edits anyway. I don't think that it is hard to achieve. I'd like to see it as a guideline for RFAs - labelling "good editors" doesn't achieve anything.

talk

) 03:24, 24 December 2009 (UTC)

How about immediate loss of admin status if you dont keep the monthly 33% article editing quota for three months in a row? Why should you have extra tools in an encyclopedia if you arent actually spending at least 1/3 of your time working on the encyclopedia?Camelbinky (talk) 20:55, 24 December 2009 (UTC)

I'm real nervous about mandating a quota. While I would LOVE for every admin to be more involved in content creation, sometimes it is not feasible. Would we want

WP:AFD to become seriously backlog because an admin needs to radically change gears and write some content before they lose their tools? Would we want Arbcom cases to languish longer because the Arbs need to switch gears and work on some content? I firmly believe that we need make content creation desirable rather than a chore that someone needs to do in order to meet a quota. If we want to change the culture of wikipedia, we have to start with the importance and value that the community places in content creation. In all honesty, Admins and Arbs who are not content driven (or at least were once actively in the "trenches") shouldn't have been so gladly given the tools and authority in the first place. The community should hold content creation to a higher esteem and view RfA, RfB and Arb candidates who don't contribute content as sub-standard candidates for the position they are seeking. . Agne^Cheese/^Wine

21:05, 24 December 2009 (UTC)

How do we do that then? The culture of established Admins is already geared towards asking questions to prospective candidates "have you done x, have you been active at y, do you comment at AN/I", with very few comments on "have you ever gotten an article to FA status? What article are you most proud of?" Barnstars are cute, and I do get all warm and fuzzy when I get one, but really... isnt there more that can be done for those who do the hard work of looking at (in my case just today) literally hundreds of online sources just in order to add a paragraph or two to an article. We seem to be slipping away from the encyclopedia part of our mission and caring too much in the "how to function as a community" aspect. What can be done to refocuse the entire Wikipedia culture back to its ONLY TRUE reason for existing- adding content to an encyclopedia with the ultimate goal of one day being complete (though realistically that will never happen, and we have no deadline, though if we do it my lifetime I'll be forever grateful to everyone!).Camelbinky (talk) 21:27, 24 December 2009 (UTC)

About creating a barnstar for those who edit more than ___ % (50%???) of edits to article and article talk pages (or whatever our criteria) in a period (6 months???) ? Do we want a warning template for those who contribute 85% or more to ANI, AN, RFA? The warning template may meet hostility, which is what we don't want. What we might want is a template encouragement to edit articles, which would have to be worded in a very tactful way. These are all barnstorming ideas, that is, ideas which haven't been thought through carefully but presented to avoid missing good suggestions. Suomi Finland 2009 (talk) 17:50, 27 December 2009 (UTC)

I don't think there is an easy answer to this but I'm sure that anything that will come across as a "threat" (like quotas or templates) will meet fierce resistance and potentially backfire. We simply can't force people to become content contributors. We have to uses more honey than vinegar. If someone really wants to take this bull by the horns, my suggestion would be to start an essay on the importance of encourage more content contributors (maybe tie it into the news articles about the general decline of the encyclopedia?). The essay should also touch on the importance of making content evaluation critical to RfA, RfB and ARBCOM elections. I would suggest presenting the essay to Jimbo and also starting an RfC for "brainstorming" ways to promote content contribution. To accomplish anything we will need widespread community involvement and input. Set a fixed date for the RfC to run thru, say the end of March, and then spend the rest of 2010 implementing some of the most popular and plausible ideas (contest,

WP:WIKICUP, coordinated wiki-project events, coordinated Mainpage ITN, DYK, OTD, FA events, barnstars, etc) submitted at the RfC. Recruit the Signpost for support and to regularly update the rest of the community on the progress. Get this initiative in front of people and frequently remind this is going on. At the end of the year, we should evaluate the results with what worked and didn't work. Agne^Cheese/^Wine

19:32, 27 December 2009 (UTC)

Shifting the indent: Very good brainstorming (not barnstorming! Barnstorming is when you blow up a barn! English is not my forte.) Other possibilities include:
1. asking administrator candidates (RFA) if they plan to continue editing articles primarily and if they are willing to be reminded of their pledge, if they say they will write. Drawback: Asking the same question can meet hostility, as did User:Kurt Weber (though it was a little different).
2. Revive the Dramaout campaign, which was a one time campaign to article write for a few days (1-2 weeks) and not participate in dramatic noticeboards, like ANI.
3. Do some of the other suggestions mentioned above. Suomi Finland 2009 (talk) 21:59, 27 December 2009 (UTC)

No quotas, but in a one-on-one dispute between a content creator with knowledge about a topic and a drive-by janitor editor there should be a bias in favor of the content creator unless the fixer-upper is willing to claim knowledge about the subject or POV pushing is suspected. Lambanog (talk) 09:50, 29 December 2009 (UTC)

Quotas would be a bad thing and would lock out some of our best specialists. People are good at different things, and that is the strength of a project like this, that each user can do what he/she is doing best or enjoys doing best.

I am such a specialist. I don't edit articles much any more. My hobby, profession and education is as a programmer. I was made admin since I need to handle protected templates, since many of my templates quickly become so popular that they get protected since they become high-risk. So they had to make me admin so I could continue taking care of those templates. Now I program templates, fix bugs in the interface, improve the site wide CSS files, and other such tech-work. But with a quota system you would loose specialists like me.

But yeah, the people who only spend their time extending the policies and then enforcing them (without understanding the needs of our content creators or our readers) are really annoying. I wish there were some mechanism to get rid of those users, since they are detrimental to the project.

--David Göthberg (talk) 17:57, 29 December 2009 (UTC)

"Um, I'm volunteering my time to edit Wikipedia. As such, I'll edit anywhere I damn well please, thankyouverymuch." That would be my initial reaction to reading a suggested focus for editors, and I'd be surprised if that thought wasn't repeated by others. EVula // talk // ☯ // 18:24, 29 December 2009 (UTC)

Proposal

It got done!! Wooo!! We now have a "Book:" namespace. Happy‑melon 13:24, 28 December 2009 (UTC)

Wow, something was actually accomplished... I'm stunned! Congratulations guys!
— V = I * R (talk to Ohms law) 20:11, 28 December 2009 (UTC)

Implementation

Will the books need to be moved manually or is there an automated process set up for the transition? I note that some books are still in the Wikipedia namespace.  Skomorokh  13:29, 28 December 2009 (UTC)

The Book namespace is currently empty except for a

XNR to an article with a conflicting title; all books need to be moved there manually, or by a bot. Happy‑melon

13:32, 28 December 2009 (UTC)

Make sure to make the appropriate changes to Wikipedia:Namespace and all that. :) JoeSmack ^Talk 06:37, 29 December 2009 (UTC)

Done. Mindmatrix 18:28, 29 December 2009 (UTC)

Mindmatrix: Thanks for updating the Wikipedia:Namespace page.

Everyone: For reference, the bugzilla bug about the adding of the new namespaces is bugzilla:21958.

I have done some checks and updates:

The magic words such as {{NAMESPACE}} works correctly in the two new namespaces, also when used in unusual ways such as "{{PAGENAME:Book:Example}}".

Both "Book:" and "Book talk:" have the MediaWiki subpage feature enabled, which is good.

I have checked all the namespace-detection templates such as {{talk other}} and {{namespace detect}} and done updates where needed. I also created the {{book other}} template. I have also checked some of the major templates that use those templates.

However, there are lots of templates and system messages out there with hardcoded namespace-detection, and some of them probably will fail when used or shown in the "Book:" and "Book talk:" namespaces, so we need to check and update lots of more places.

--David Göthberg (talk) 04:07, 30 December 2009 (UTC)

I previously had a number of Wikipedia templates tweaked to allow optional links to appropriate current articles on Wikinews. Picking Ted Kennedy and the obituary template met with great resistance, and I — personally — don't have the patience of a saint required to deal with arguments that should not be dragged into daylight where certain material is technically against Wikipedia policy, and such should be redirected to Wikinews.

I have taken some time to put together another attempt at what I see as the appropriate templates to be changed. The examples shown there are with links to Wikinews, click through to the template copies there to see the proposed display where no parameter is given. Note! There is extensive use of tooltips in my changes.

I would like to get this sorted out before Christmas, please suggest how this proposal could be improved. Naturally, I would like to be able to add the Wikinews logo but, there has to be some balance and keeping this relatively unobtrusive.

Thoughts? --Brian McNeil /^talk 14:03, 6 December 2009 (UTC)

And what if there is no accompanying article on Wikinews? Would your change to policy be just not to note that this subject is currently in the news? 99.166.95.142 (talk) 17:17, 10 December 2009 (UTC)

Where, precisely, do I propose change to policy? Had I thought this impacted policy I would have raised it on that section. The policy is

WP:NOTNEWS

. I propose templates regularly applied to articles where this policy is applicable be used as a way to direct contributions unwelcome as a consequence of that policy to another Wikimedia Foundation project where such contributions are welcomed and appropriate.

Have you any further, and preferably constructive, criticisms to add? If there is another policy which you feel the proposed changes would violate, please enlighten me and give a cite as to why there is a problem. --Brian McNeil /^talk 06:58, 13 December 2009 (UTC)

Actually, I think that's a great idea. To address the above concern, if there's not yet an article on Wikinews, we could always have a template saying "This subject is a current event that is

not appropriate for an encyclopedia article at this time. If you would like to write about it, you may wish to consider writing about it on Wikinews." I think that would vastly help compliance, as well as drive a lot of news type stuff where it actually belongs. Seraphimblade ^{Talk to me}

07:18, 13 December 2009 (UTC)

• Thank you for the encouragement! I was just adding an additional piece to my user talk (the initially linked to section above) to try and explain what I was guessing might be the anonymous user's issue if they did not look there, or at the alternate visible
  WP:NOTNEWS
  within my proposed changes because when I last looked at that it is a redirect into a largish policy document.

Would copying the template examples from my user talk page here (adding a little colour) provoke more feedback on this? --Brian McNeil /^talk 07:35, 13 December 2009 (UTC)

This is what I'm proposing. Click on the links to sub-pages of my usespace to see the template without a completed |wikinews parameter

Each of the below attempts to redevelop these templates includes an optional "wikinews=" parameter. The given examples show what is presented when this parameter is filled in; to see the template with no "wikinews=" parameter, click on the link to the sub-page.

• User talk:Brian McNeil/Recent death

  Example:

This article is about a person who has recently died or has recently been reported dead. Some information, such as that pertaining to the circumstances of the person's death and surrounding events, may change as more facts become known. Obituaries are not appropriate for Wikipedia; please consider contributing to the obituary on Wikinews.

• User talk:Brian McNeil/Current

  Example:

This article documents a current event. Information may change rapidly as the event progresses. Wikipedia is not a news site; please consider expanding Wikinews coverage, or writing a follow-up.

• User talk:Brian McNeil/Current related

  Example:

This article is related to a current event. Information may change rapidly as the event progresses. Wikipedia is not a news site; please consider expanding Wikinews coverage, or writing a follow-up.

• User talk:Brian McNeil/Obituary

  Example:

This article reads like an obituary. Wikipedia is not a memorial site and articles should have a neutral point of view. Please help edit it to help achieve a neutral point of view, or discuss changes on the talk page. Wikipedia is not a news site; please consider expanding Wikinews coverage, or writing a follow-up.

• User talk:Brian McNeil/Recentism

  Example:

This article or section may be slanted towards recent events. Please try to keep recent events in historical perspective. Wikipedia is not a news site; please consider expanding Wikinews coverage, or writing a follow-up.

--Brian McNeil /^talk 02:13, 18 December 2009 (UTC)

I don't think the recent death one would be useful. The reason is because editors who tag articles are more often than not experienced editors who know that Wikipedia is not a news source. A IP/New editor would not know to use such templates, and would create the page without the template, and even if it was an obituary. If it was an obituary, the article in question will most likely be tagged with a deletion template, so the chances of a new editor being helped by it is low. I think what would help more is if they included it in the meta when you edit of what wikipedia is not. (not dictionary, not news, etc.) ηoian ‡orever ηew ‡rontiers 04:06, 25 December 2009 (UTC)

edit: I also consider the recent events not relevant enough for the negative effects (discouraging edits), a submessage saying that one shouldn't include opinions would solve a much more pressing issue for usage of that template. ηoian ‡orever ηew ‡rontiers 04:08, 25 December 2009 (UTC)

• I am not proposing these changes for experienced Wikipedians who do know that Wikipedia is not news. My understanding is that many would-be editors are put off as their attempts to add news vanish. The intent is to direct to any existing news story, or to actually create one on Wikinews. I don't think that discourages edits; the two are Wikimedia projects, Wikinews still hasn't disabled anonymous users from creating new pages. --Brian McNeil /^talk 17:37, 27 December 2009 (UTC)

  I (still) think that this (or something very much like it) is an excellent idea.
  — V = I * R (talk to Ω) 19:37, 27 December 2009 (UTC)

I agree with the general idea. How helpful these templates will be in use is hard to say, but having such notices/reminders should have some positive effect. Rd232 ^talk 20:10, 27 December 2009 (UTC)

• I'm trying to persuade a couple of more technical Wikinewsies to help me "steal" the Wikipedia Article Creator and adapt it. Obviously I'd want links in these templates asking people to create an article to direct them to that. --Brian McNeil /^talk 00:59, 30 December 2009 (UTC)

Persons interested,

I noticed that Hudong Encyclopedia, a Chinese Encyclopedia, is much larger than Chinese Wikipedia. I would like to suggest that someone associated with Chinese Wikipedia begin to copy over parts of Hudong Encyclopedia in order to expand the Chinese Wikipedia, as it is way, way smaller in comparison.

I do not speak or read Chinese, and would not be able to work on this project. However, as I said, we could ask someone that's associated with Chinese Wikipedia to help expand our reserves.

We could claim this as a "reference" for the pages that we copy, if need be.

This is merely a suggestion.

Signed,

Sean

Sean 0000001 (talk) 09:28, 21 December 2009 (UTC)

We can't copy Hudong's content, as it is copyrighted. Firsfron of Ronchester 09:32, 21 December 2009 (UTC)

Rather ironic that the encyclopedia from the socialist country doesn't use a free culture license. --Cybercobra (talk) 09:40, 21 December 2009 (UTC)

OK. That's cool. As I said, it's merely a suggestion, and Cyber, that truly is ironic. What has the world come to?

Is there any way we could get them to work with us?

Sean

Sean 0000001 (talk) 21:32, 21 December 2009 (UTC)

That would be something best brought up on the Chinese Wikipedia, as the English Wikipedia has no control over it. --Golbez (talk) 03:59, 22 December 2009 (UTC)

OK. I don't really read/write Chinese, but I'm sure that someone will read this that can speak Chinese, and hopefully they will bring it up over there. Until that happens, though, this idea will be pretty much dead.

Thank you all very much for all of your help.

Sincerely,

Sean

67.83.48.26 (talk) 05:26, 22 December 2009 (UTC)

But how do you know that chinese wikipedia is shorter, if you can't read it?

talk

) 23:55, 22 December 2009 (UTC)

Sean isn't wrong; the fourth Google hit for Hudong is an article with the statistics. Hudong: 3 million articles, Chinese Wikipedia: 280,000 articles. It's not even close. Firsfron of Ronchester 06:58, 23 December 2009 (UTC)

I could bring up the idea of cooperation between Hudong and Wikipedia on the Chinese Wikipedia, but honestly I think that such an idea has very little chance of success. Hudong has no incentive to cooperate with an encyclopedia so much smaller than itself, and the Chinese government doesn't really trust Wikipedia, which would also scare away Hudong. Honestly, Wikipedia's failure in China, in my opinion primarily due to the Chinese government's blocking it for years, is really unfair and unfortunate.--Danaman5 (talk) 07:24, 23 December 2009 (UTC)

The Chinese internet is almost entirely self-sufficient. They hardly use Google, or Wikipedia- they prefer their own version. Could be a government-pressure thing, but they have no incentive to plug in to the west. --King Öomie 20:47, 23 December 2009 (UTC)

Danaman: I figured as much. It is really a shame that the Chinese edition failed, since Wikipedia bills itself as a center of world knowledge, and yet we're getting blocked from compiling part of that world knowledge.

And if you could bring it up, that would be great! Thanks!

Thanks to all for all of your help.

Sincerely,

Sean

Sean 0000001 (talk) 07:32, 29 December 2009 (UTC)

There are systemic biases inherent in Wikipedia that make it Western oriented. That is both what makes it good in many cases and less than ideal in others. Lambanog (talk) 09:57, 29 December 2009 (UTC)

Systemic biases, like our blatant defiance in having an article on the

Tiananmen Square protests of 1989? --King Öomie

14:30, 30 December 2009 (UTC)

Chinese Wikipedia has not "failed" - it is simply going to be slower to succeed. bd2412 T 14:02, 30 December 2009 (UTC)

Has Wikipedia considered using Volunteer computing or Grid computing?Lemmiwinks2 (talk) 23:45, 27 December 2009 (UTC)

For what?
— V = I * R (talk to Ω) 23:24, 27 December 2009 (UTC)

For re-creating articles after an edit. Lemmiwinks2 (talk) 23:26, 27 December 2009 (UTC)

It was this discussion that got me to thinking about this. Lemmiwinks2 (talk) 23:32, 27 December 2009 (UTC)

The discussion you linked to seems to be talking about the delays in downloading pages as they become longer and include more complex templates. Grid computing wouldn't affect that problem as it is the readers' computers and the server's bandwidth capacity that are the most likely bottleneck, not the server's processing capacity.

Grid computing works best on tasks that require a high degree of processing power and where tasks can be bundled into chunks that optimise the benefit of faster processing over the increased cost of bandwidth passing tasks between server and remote processor. There may be tasks in Wikipedia that fall into that category, but I can't think of any offhand. Road Wizard (talk) 23:51, 27 December 2009 (UTC)

No, I dont think so. That discussion says that the bottleneck occurs when the page has been changed and the server has to recompute it. if it is large, has many templates, and is editted often then it can slow things down. It seems to me that that would be perfect for distributed computing. Lemmiwinks2 (talk) 00:00, 28 December 2009 (UTC)

You might remember that when Michael Jackson died, the servers almost went down. The page was very large and very intensive to calculate (over 10 seconds i believe). It was however edited so often that the parsercache and the squids had to update several times a minute. That was putting an enormous strain on the core of the services, that they couldn't handle it anymore. We had never before had so much traffic on a single page before

Lemmiwinks2 (talk) 00:03, 28 December 2009 (UTC)

Actually, it would make it worse. After its edited, the page would have to go into a queue until a client computer requests a new task, then it would be sent to the client, processed on a computer that might be much slower than any server we have now, then sent back. To prevent against intentional tampering or data corruption in transit, the task would likely be sent to multiple clients and the results compared. Distributed computing can't really be used well for anything that's time-sensitive, which, for a website, almost everything is. For a case like Michael Jackson (which comes along about once every several years, and lasts only a few hours), it would just mean that the queue gets flooded. It would prevent the site from slowing down, but overall it would mean that after saving a page, instead of having to wait a few seconds to see your changes, you might have to wait several minutes or even hours. Mr.Z-man 00:24, 28 December 2009 (UTC)

Thats a worst case scenario if i ever heard one. I am sure thousands of people all over the world would be willing to use their computers for such a thing and many of them would be perfectly fine high speed computers. i simply cant imagine that people would have to wait hours and if it really did come down to that then you could always fall back to doing it yourself. Lemmiwinks2 (talk) 01:01, 28 December 2009 (UTC)

And editors themselves could volunteer to use their computers for this whenever they edit an article. Lemmiwinks2 (talk) 01:04, 28 December 2009 (UTC)

The problem is that Distributed/Volunteer/Grid computing is used to optimize the performance of discreet operations. The way that web servers function just doesn't fit with that sort of operating model. The way that Wikipedia, or more accurately the MediaWiki software itself, it's the backend of an already distributed computing environment. All of our millions of browsers are the distributed front-end to Wikipedia, but all of our work is compiled and redistributed via the MediaWiki backend.
— V = I * R (talk to Ohms law) 01:09, 28 December 2009 (UTC)

Hours might be a worst case scenario, but 1 minute would be unacceptably slow when the vast majority of pages can be parsed on the server in ~1 second. Mr.Z-man 01:23, 28 December 2009 (UTC)

← This isn't something grid computing can fix. Grid computing is for calculations being done on the end-user's computer, and is not a time-sensitive job. Serving web pages has to be done from the server itself. — The Hand That Feeds You:^Bite 19:02, 28 December 2009 (UTC)

Of course. Once the webpage is calculated (after an edit) then it would be served from the server. small simple articles probably wouldnt be worth farming out but larger more complex articles might be. Lemmiwinks2 (talk) 20:25, 28 December 2009 (UTC)

How in the world would a "distributed webserver" deal with edit conflicts? Our pages are not static, so they must come together somewhere central and be served from there...
— V = I * R (talk to Ohms law) 21:10, 28 December 2009 (UTC)

My day job since ten years back is researching distributed and serverless computing, and I am an active Wikipedia editor and have some insigths in how Wikipedia works, so I feel obliged to comment on this. :))

Wikipedia pages consist of several parts: The things outside the page area, which are rendered differently for different users. The page content itself. And usually a bunch of templates which often in turn call a bunch of other templates. All these things are stored in different places in the database and has to be fetched before a page can be rendered. Also, for each link on the page a database call is needed to check if it should be a red or blue link. Also after the page has been rendered, the categories it has needs to be reported back to the jobqueue (if they have changed) so the category pages get updated.

So rendering a page involves a lot of database accesses, so it is probably the database work that is the heavy part, not the actual rendering to XHTML. Doing database calls over the Internet from home computers to the Wikimedia database would cost a lot of bandwidth for Wikimedia, and would be slow, so probably doesn't fit for distributed computing.

What could be distributed fairly easily is the page caching. But as far as I heard we don't have a problem with the page caching, the squid cache servers work just fine.

What could and perhaps should be done is some throttling in the updates done after a page has been rendered, if a page is edited rapidly. That is, not insert the same orders on the jobqueue several times a minute, such as the category changes and the orders to all the cache servers to drop the page. Then of course changes to a page might take say 30 seconds to show, but I think we could live with that. But we should leave that to the devs and sysadmins to handle.

But I should mention that there are a bunch of projects in the world that are researching how to make more distributed, or fully distributed wiki systems. Some years ago I said it seemed to be a not solvable problem, but now we have come to a point where it seems it actually is possible to make a fully distributed wiki system. Although it seems such a system would be slower and it would be way more tricky to add features to it. So I think we are stuck with centralised server-based wikis for the next 10-20 years or so.

--David Göthberg (talk) 21:52, 28 December 2009 (UTC)

Thank you for your answer. I was assuming that the server would do all the needed database calls itself then would 'serve' the data to a volunteers cpu which would then render the page which would then be uploaded to and cached on the server. did you see the quote above about the Michael Jackson page? Lemmiwinks2 (talk) 22:37, 28 December 2009 (UTC)

The problem is that by the time you know what queries to do, and actually do them, you've already done 75% of the work. Mr.Z-man 22:46, 28 December 2009 (UTC)

Lemmiwinks2: Your earlier comment about the Jackson article mentioned that the updating of the cache servers several times a minute costed a lot, which probably is right. But rendering of the pages in a grid would not help that part at all. Instead as I said, the updating of the caches could be throttled to handle that.

--David Göthberg (talk) 00:03, 29 December 2009 (UTC)

The problem with the Michael Jackson incident was that the left hand wasn't talking to the right hand about what was going on in the cluster. Most of our requests are served from the squid caches; when a change is made to the page, the cache is invalidated, and on the next request for the article an Apache is assigned to render a new copy of the page which can be cached and take the load off the web tier again. The problem with Michael Jackson was that we were getting thousands of read requests a second: as soon as the cache was invalidated, the first request to come in was assigned to the first available Apache... and the second to the second Apache, the third to the third, and so on, because by the time the first Apache had done rendering we had had thousands of other requests. The complexity and length of the Michael Jackson article lengthened the time taken to render such that every Apache in the cluster was expending their entire CPU time on trying to render the same copy of the Michael Jackson article. And because the article was being edited so fast, the cluster never had time to unjam itself: by the time the first Apache had finished rendering, the copy it was working with was already out of date, and the next round of read requests would still fall through the squid layer and hammer the Apaches. Essentially, the Michael Jackson incident demonstrated just how totally f***ed we would be without the squid layer.

Now we have parallism coordination in the page rendering phase: we have a pool counter that tracks how many of the cluster's Apaches are currently rendering the same content, and serves the old content if it's clear that a lock is developing. I don't see how distributed computing would have helped in this instance; if anything it's an example of how uncontrolled grid computing can go badly wrong. As Domas wrote, it's more an example of "shit happens". Happy‑melon 10:26, 30 December 2009 (UTC)

Happy-melon: Thanks for the explanation. Ouch! So it was a lack of throttling involving the cache servers, but even worse than we thought. But as you also stated, they seem to have fixed that now by adding throttling in the right place.

--David Göthberg (talk) 20:16, 30 December 2009 (UTC)

All there is a flag related discussion at Wikipedia_talk:WikiProject_Football#Proposed_major_change_to_Football_squad_system which may be of interest to user here Gnevin (talk) 14:52, 29 December 2009 (UTC)

User User:WFCforLife has suggested I may generate some more interest in this if I gave a brief overview of the discussion. So I will attempt to be as neutral as possible. There have been numerous discussions about flags for soccer players over the past while . This has lead to this discussion amongst many.

One of the many concerns with flag usage is that it is currently not meeting

Fs player}} useless a reference is supplied. This of course could lead to wide spread disappearance of flags on literally thousands of articles. Outside views of such a major change would help Gnevin (talk

) 20:33, 30 December 2009 (UTC)

The new proposal: A template for comparing debate points side by side. See {{inbrief}}. Sole Soul (talk) 20:38, 24 December 2009 (UTC)

comments? --Ludwigs2 23:53, 23 December 2009 (UTC)

I tested it here User:Sole_Soul/test, I added texts from 2 random articles. Sole Soul (talk) 23:56, 23 December 2009 (UTC)

whoops - I think something I did messed up the test - hang on... --Ludwigs2 00:11, 24 December 2009 (UTC)

My mistake. I'm bad at tables. Sole Soul (talk) 00:17, 24 December 2009 (UTC)

no, this is a wikitext thing - apparently it doesn't like bullet points inside the conditional table cells (at least not the way I'm currently doing it). I'll need to figure out why that is, but for the meantime, you should keep the text restricted to plain text, without wiki expandable elements. --Ludwigs2 00:18, 24 December 2009 (UTC)fixed... --Ludwigs2 01:23, 24 December 2009 (UTC)

Ok, so lets say this proposal flies... you state its good for "certain circumstances"... who decides what circumstances? I'd only support this idea if and ONLY if it was up to the two people involved, only if both agreed. I am not in favor of this being FORCED upon two editors by a janitor (administrator) who happens to come across it and has a philisophical problem with people being jerks to each other in a discussion. Admins (excuse me- Janitors I mean) are NOT policemen or teachers or authority figures, and I can not endorse anything that is just one more tool they can use to make themselves feel like they are and that they can control us.Camelbinky (talk) 01:41, 24 December 2009 (UTC)

I can't speak for Sole Soul, but I see this just as a tool-of-convenience: personally, I get tired of those long discussions that kind of drift around because everyone has forgotten the original debate (you know, where you have to dig back through the discussion to show someone they said something they don't remember saying...). it would be nice to have a box of main points that could be referred to and updated as the debate progressed. I don't think there's any way (or need) to force people to use it. if people get used to it and like it, they'll start to use it habitually; If they don't (or if they are just spoiling for a fight and don't care about clear points) they won't use it. Maybe the mediation cabal can make some good use out of it in a more authoritative way? --Ludwigs2 04:31, 24 December 2009 (UTC)

I agree. Ludwigs2 saw the half full of the glass and made the proposal much better. Sole Soul (talk) 09:01, 24 December 2009 (UTC)

Nice template. This could be used at AfD for editors to summarise the reasons for keep vs deletion, see

Wikipedia talk:Deletion advocacy#Alternative proposal - collaborative arguments. Fences&Windows

15:09, 24 December 2009 (UTC)

As I mentioned to Sole, if we wanted to get sophisticated with this template I think I could set it up similar to {{

todo}}, where each section actually creates a separate subpage for that position and pertinent sections of the subpage are transcluded back. people could use the subpages to hash out arguments for each PoV, refine summaries, and sign endorsements, while only the last two would appear on the main page. that might be overkill, though... --Ludwigs2

18:28, 24 December 2009 (UTC)

I like the proposal as a tool for those in a discussion to use on their own initiative, but it scares me when talk of using it in an "authoritative way" is mentioned. Can we please put an agreement not to let this be used in a forced upon manner on people who are in a discussion and dont want to use it? I myself see the merits and would use it in a discussion, if all sides agreed to it. However, if I was in a disagreement and nobody wanted to use it, I would be the first to bitch and complain if an admin showed up and said there was "too much bickering" and forced upon us the template (which in that case may just cause one side to leave and the other side win by default). Any ideas on what could be done to make it from ever being a mandated form of "punishment"? Other than that I now support this good idea. I just hope some of my worries are addressed.Camelbinky (talk) 20:53, 24 December 2009 (UTC)

In the new proposal this tool will be used as an addition to the direct discussion. It is something informal just to summarize the main arguments. I don't see the need for a prior agreement before it is used, as nobody will be forced to endorse a summary that they don't agree with and the parties can add their own summaries if they wish or ignore the tool altogether and continue their discussion. Sole Soul (talk) 21:30, 24 December 2009 (UTC)

Well, if I were going to suggest a formal use for this, I'd see it as follows. at the beginning of a formal discussion (such as an AfD, as Fences and Window linked), someone (the creator, or a volunteer, or possibly it becomes part of the page construction) would place this template near the top of the page with sections for Keep, Delete, and Stubify. Then they (or anyone else who chose) would periodically add novel arguments or revise present ones for each position, adding links to sections farther on in the article to keep basic argument threads together. other editors could endorse one position or another by editing the lower box (saving the need for dozens of keep per abcd lines), and the remainder of the article space could be reserved for actual discussion (hopefully structured into appropriate sections, by theme). the final result (ideally) would be a template box near the top with succinct summaries of each position and links to full debates, along with a list of user endorsements, with the rest of the article space a linked list of debates about each main summary point. the template could then be preserved for a quick reference on the historical debate, so that people could see the basic overview or review detailed discussion on various points. not so much a requirement, that way; more a structure that editors are given to make parsing the conversation easier. --Ludwigs2 22:19, 24 December 2009 (UTC)

I like it. There are AfDs that just get out of hand and become incredibly lengthy, and end up with "no consensus". A re-nomination could use this template to summarize past arguments for reference, to avoid even more repetition. If

talk

) 00:45, 30 December 2009 (UTC)

ok. I'll take the time to play a bit with a more sophisticated version that generates argument subpages. I'll post a link to it when I get some meat on it. --Ludwigs2 23:28, 30 December 2009 (UTC)

For users who have been inactive for some period of time (30 days seems like a reasonable time period), the software should ignore the watchlisting of pages by those users. Note that the data would be retained on the server, so if/when the user returns then they would still have their old watchlists.

This would be a good change to make simply for accuracy. Inactive users "watching" pages is actually worse then no one watching pages for the simple fact that it creates a false sense of security, and it's misleading. However, this will be especially important as we move forward with any sort of Flagged Revisions system (such as

Sorry, can you explain why it is harmful for inactive users to have pages on their watchlists? I don't understand. ╟─TreasuryTag►Chancellor of the Duchy of Lancaster─╢ 09:16, 30 December 2009 (UTC)

Right now it's simply misleading. If you use the tool server watchers script to see that there are a hundred and something watchers, for example, that can provide a false sense that the page is being watched, when in reality probably 2/3 (if not all) of them haven't logged in for months.

Going forward is where this is going to be important. If noting were to change then this wouldn't be worth spending time on. Considering the fact that some form of Flagged Revisions is coming to en.Wikipedia, and all of the proposed used are partially based on the number of watchers, this becomes really important.
— V = I * R (talk to Ohms law) 09:22, 30 December 2009 (UTC)

(edit conflict) Understood. However, I think that the bar needs to be set much higher than 30 days (perhaps up to 90 days)... people can easily be away from the site for that long. ╟─TreasuryTag►Africa, Asia and the UN─╢ 09:27, 30 December 2009 (UTC)

That's fine, and this is a discussion we should have at length regardless. I readily admit that I pulled 30 days specifically out of thin air with very little forethought. My only issue with the time period is that, in order for it to be meaningful, it shouldn't be too long. Anything more then ~180 days is fairly pointless. Keep in mind here that there's nothing permanent about this anyway, so as soon as the person logs back in then they "count again" everywhere.
— V = I * R (talk to Ohms law) 09:39, 30 December 2009 (UTC)

It's not harmful for them to retain it on their watchlist, and it would be harmful to remove it from their watchlist. However, it is harmful for us to mark it as being monitored when in fact it isn't, as explained in more detail

here. As I indicated on that page (once I fully understood what was being proposed!) I think this is a great idea. Even if targetted flagging is not adopted, it would be very useful for the project to know the proportion of its content that is actively being monitored, as this could potentially highlight areas of weakness and therefore areas where we can try and improve. WFCforLife (talk

) 09:26, 30 December 2009 (UTC)

(e/c x2) I think the problem is that people are using these numbers for something they weren't originally designed to show. The data is now being looked at in order to see how many people actively review changes to articles, when having something on a watchlist doesn't mean there are people watching. I have several hundred pages on my watchlist; doesn't mean I look at each diff of every page that is changed. Killiondude (talk) 09:28, 30 December 2009 (UTC)

Hmm, that's a fair point, actually (it applies more to the general idea of basing FlaggedRevs on watch-statistics, rather than this proposal specifically). Not sure what the solution is, though... ╟─TreasuryTag►secretariat─╢ 09:31, 30 December 2009 (UTC)

It is a fair point, but it's not something that we should really consider here... I mean, the fact is that people do use the number of watchers counts, even if their meaning is open to interpretation. We ought to make those numbers as accurate as feasible (without requiring people to jump through hoops though). As general advice, it's probably a good idea to recommend that people don't watchlist pages that their not going to really check, but that's a discussion to have on a different day.
— V = I * R (talk to Ohms law) 09:43, 30 December 2009 (UTC)

...how is this not applicable? Working off of a flawed system of using the number of watchers, doesn't mean we should expand that avenue. Killiondude (talk) 09:46, 30 December 2009 (UTC)

It's applicable in general, but I don't see how that totally invalidates the proposal. Considering the fact that watcher counts are already used, and that use is likely going to expand, my should try to make that tool as meaningful as possible. This is one step in that direction.
— V = I * R (talk to Ohms law) 09:50, 30 December 2009 (UTC)

You know, another side-benefit (or even primary benefit) to making the software aware of "inactive" users would be that the software could (semi- or fully-) protect those user pages. I've seen issues where vandalism occurs on inactive user pages at least occasionally. It's not a real big deal, but if we're going to engineer a little activity awareness then we might as well leverage that capability for all that it's worth.
— V = I * R (talk to Ohms law) 09:48, 30 December 2009 (UTC)

I agree there is a problem, but having the toolserver report ignore the watchlists of inactive users is only part of the solution as there are active users who don't use their watchlists..... What we really need is a toolserver script that looks at watchlists that are regularly looked at, and tells us which articles are not on any recently viewed watchlist. As for userpages I'd like to see a list of userpages that are not on any actively viewed watchlist and where the last edit was by an IP.... ϢereSpielChequers 10:23, 30 December 2009 (UTC)

Total disagreement about automatically protecting pages when someone goes inactive; not only am I mildly creeped out by the system "reporting" on users in such a fashion, but there's also the argument that an inactive user hasn't done much to piss people off recently, so their userpages are less likely to be vandalized. The idea of taking them off the internal "this many people are watching a page" list is an interesting one, however. EVula // talk // ☯ // 11:34, 30 December 2009 (UTC)

Something that concerns me here is the definition of "inactive". I've always seen "inactive" used on Wikipedia to mean "hasn't edited for X time". If that's the definition here, then it's beside the point. Who cares whether or not the watchers have been editing, as long as they're watching? Ntsimp (talk) 17:35, 30 December 2009 (UTC)

I specifically stated in the proposal that such a system would track logins. You're correct that tracking edits isn't indicative of actual activity.
— V = I * R (talk to Ohms law) 22:04, 30 December 2009 (UTC)

VIR: As I already wrote below before you left this message: Real watchers do corrective edits every now and then. If a watcher never corrects anything, then his watching is worthless. So "active" should be measured as "has done edits lately", not "has been logged in lately".

There are plenty of situations where a user might stay logged in for months without doing any work: I for instance usually stay logged in and continue to read Wikipedia when I go on wikivacations, since that means I have my own user interface tweaks and see if I get messages on my talk page. But I don't do any active watching of pages while I am on wikivacation. So it would be weird if I was counted as an active watcher of a page during such times just because I am still logged in and happen to have that page on my watchlist. So ideally that means "active" in the watching sense should be "have done edits lately in other than his own user space and loaded his watch list lately".

--David Göthberg (talk) 00:19, 31 December 2009 (UTC)

Also, can the system not just report both numbers? A MUSH I'm on has a status message showing X players logged in, Y of whom have been active recently. Why can't we have both numbers, to see the total people watching and the number of those who are active? —C.Fred (talk) 17:58, 30 December 2009 (UTC)

Ntsimp: Because it is easier for the database to know if a user is active by measuring edits. If they are just watching is harder to know. But sure, it would be nifty if there were some metric that showed how often the diffs and the history of a page were checked, and by how many different users. But if those users are just watching and never do any correcting edits, then their watching isn't worth anything. Real watchers every now and then fix things, so only watchers that are active (edited lately) should count if we count history views etc.

--David Göthberg (talk) 20:08, 30 December 2009 (UTC)

Good idea, my thoughts - There would be no harm in under-reporting the number of watchers, as they would still actually be 'watching' and removing them from the stats won't stop their corrections. I agree it should be based on edits to article in question rather than purely being on a users watchlist. Lee∴V (talk • contribs) 00:32, 31 December 2009 (UTC)

Firstly, the title of this section should be changed, because right now it sounds like you want to disable people's watchlists if they've been inactive for a while. Secondly: This seems like a moot point to me since we can't see how many people are watching a page unless it's at least 30, which to me means once you can see any numerical value, the page is already well past the point that I'd consider it sufficiently "watched". If you're worried that the minimum 30 edits might all be by inactive users, I find that unlikely. I think it's much more likely that we'll have 100 inactive users watching a popular article, like one that shows 3,000 watchers; and in such a case, having that little bit of added accuracy doesn't do much for us. Finally, I also have considerable doubt that this idea would gain much traction because I think it would require a change not only to the external watcher count tool, but also to the MediaWiki software and/or the database. It seems like a lot of cost for little benefit. Equazcion ^(talk) 00:42, 31 Dec 2009 (UTC)

Well, I changed the title from "Deactivate" to "Ignore"... I'm open to other suggestions.

As for the rest, I'm not talking about the toolserver watcher tool at all. That seems to be confusing everyone for some reason, but I'm not sure how to be more clear about it. I'm talking about the MediaWiki software itself, and how that will eventually interact with tools such as Flagged Protection. I'm really pretty flustered at my apparent complete failure to properly communicate the idea here.
— V = I * R (talk to Ohms law) 00:56, 31 December 2009 (UTC)

Ah. Well then I can't really comment as I have no idea how watchlisting is supposed to interact with those future tools etc. The average Wikipedia user is going to assume you mean the toolserver program cause thats all they know about. Maybe this discussion belongs at Meta? Equazcion ^(talk) 01:04, 31 Dec 2009 (UTC)

Yea, good point. I was hopping to show support here, and then try to dragoon one of the current devs into doing something about it, but... well, you know what they say: "If you want something done right, you might as well just do it yourself". I sling code all day every day, so I may as well start doing it for WMF, especially since I've been putting it off for so long (partially because there's absolutely terrible management of the MediaWiki project, mostly because it's non-existent. I've worked with and on several OSS projects, but the MediaWiki project pretty much takes the cake as the least organized mess I've ever seen...) Ah well, time to jump into the rabbit hole I guess.
— V = I * R (talk to Ohms law) 03:59, 31 December 2009 (UTC)

Equazcion: We admins have tools such as Special:UnwatchedPages to see which pages are not watched by enough users. But you can't see those tools since you are not an admin. They are restricted to admins only because otherwise vandals could way to easily find pages to vandalize that no one is watching. The same goes for the tool on the toolserver, users with special authority can see the number of watchers for a page also when there are less than 30 watchers.

What VIR is pointing out is that unfortunately tools like Special:UnwatchedPages currently show bad stats. A page that seems to be watched by 20 users might not be watched by any active users at all, just 20 old users who left Wikipedia long ago.

--David Göthberg (talk) 02:05, 31 December 2009 (UTC)

There is a proposal and discussion regarding the use of AWB's general fixes by bots, at Wikipedia:Village pump (technical)#Perform AWB's general fixes from a dedicated standalone bot. All are welcome to comment. Thanks. Equazcion ^(talk) 17:48, 31 Dec 2009 (UTC)

Hi all,

This is just a notice that I've created a new

--(X! · talk)  · @978  ·  22:28, 1 January 2010 (UTC)

I know there's a big overhaul of the editing interface in the pipeline, but it's been in the pipeline for a year now, with no deadline set. In the meantime, can we implement some quick and simple fixes to make our toolbar more intuitive to newbies? IMO, a lot could be done to redraw the icons, but I'll limit this to the most glaring problems. Those being:

1. The 'link to' (third and fourth) button captions could be phrased better -- instead of stating "internal link" and "external link (remember http:// prefix)", it would be better to have them as "link to another article" and "link to an external website".
2. The 'inserting media' (sixth and seventh) buttons could be vastly improved, both in that:
   • The images are not clear or representative of what they do; better images would be something like and
   • The captions do not properly describe what the buttons do; instead of "embedded file" and "file link", the captions should read "insert a photograph or diagram" and "insert a sound or video clip".
3. The 'small text' button is a truly terrible graphic; something like would make far more sense.

As far as I'm aware, the last one can be easily implemented by altering MediaWiki:Common.js/edit.js, but I don't know about the others. Anxietycello (talk) 22:50, 23 December 2009 (UTC)

Number 3 isn't very legible. Fences&Windows 23:10, 23 December 2009 (UTC)

i agree, it is hard to see and figure out what it does (#3). good job on the other two though, i must agree on what you propose. just my 2 cents MACKDIESEL5 (talk) 23:29, 23 December 2009 (UTC)

How about instead? IMO, practically anything would be better than the current one! Anxietycello (talk) 23:36, 23 December 2009 (UTC)

Although we already got a major overhaul of this coming in the pipeline, I think we should just overhaul the current design of the "old" edit toolbar right now (well as in, completely redo all the icons) ViperSnake151  Talk  17:10, 27 December 2009 (UTC)

Agreed. How about the following redesign?

Current toolbar buttons, for comparison

Proposal (#1) for redesigned toolbar buttons

The buttons are the same size, and in the same order, but have been simplified down to four colours (white, light blue, dark blue and black) for faster loading time and a cleaner appearance. Crucially, they possess a uniform design that I feel is lacking in the current buttons. Some of the designs are similar to the old ones, but some, such as the insert photo, small text and quote buttons have been totally redrawn, and hopefully should be far more intuitive to the uninitiated. Anxietycello (talk) 23:02, 27 December 2009 (UTC)

Actually, I find the "current" toolbar to be easier, overall. I think that one or two specific buttons could certainly benefit from a change, but not all of them.
— V = I * R (talk to Ω) 23:11, 27 December 2009 (UTC)

Is that perhaps because you are already used to them and already know what they all do? Why is it you don't support the redesign? Anxietycello (talk) 23:15, 27 December 2009 (UTC)

No, actually, I use wikEd, and I've had the default toolbars turned off for quite a while. Just looking at them though, I find most of the current buttons to be easier to recognize. The problem with the proposed toolbar probably has to do with the fact that the buttons have all been made to similar. They tend to blur together into an undifferentiated mass, primarily because... well, their undifferentiated. The new Sound and Image buttons are better however (although, a little color couldn't hurt). I also agree with the criticism of the small text button, and I like the proposed new one. The new Gallery button appears to be an improvement as well.
— V = I * R (talk to Ω) 23:31, 27 December 2009 (UTC)

How about the below proposal, one with more colour?

Proposal #2

Maybe it would make sense to reorganise it too, grouping together the formatting button, as well as the insert buttons, and coding buttons, etc.? Anxietycello (talk) 01:07, 28 December 2009 (UTC)

The Bold and Italic icons really need to remain the same. Those especially have been standardized across several apps (not least of which include Microsoft Office and OpenOffice). I think that the current wikilink icon is fine as is as well, especially if the bold and italic icons stay the same. I don't see any benefit to changing the math and nowiki icons, since their essentially the same as the current ones (and the current ones look nicer). The new Title button is a possibility, although I think it could be worked on more. I already talked about several others above as well... I still think that if we're going to make a change that is should occur one button at a time.
— V = I * R (talk to Ohms law) 01:16, 28 December 2009 (UTC)

I was wondering about that. You're right, they are similar across many apps, but in particular, our B and I symbols are exactly the same as the ones in WordPad. Isn't a pixel for pixel reproduction of something like that a copyvio? I'm happy with my original proposal, I think those three icons are by far the worst, an I think they should be replaced ASAP, as well as fixing those captions mentioned. Anxietycello (talk) 01:38, 28 December 2009 (UTC)

I don't really know about the copyvio possibility (actually, I think I do, but my political views on copyright tend to keep me from commenting on such issues). I would guess however that those button designs are heavily influenced by prior art, so a copyright claim would be extremely hard to make.
— V = I * R (talk to Ohms law) 01:54, 28 December 2009 (UTC)

I don't understand why you're proposing to change all of them. Most of them are well drawn and easily recognisable, and many of your changes make them less recognisable and legible. The current icons I think need changing are http link, header, sound, small text, hidden comment, quote, table (slightly). Fences&Windows 23:00, 28 December 2009 (UTC)

Please enter Beta and test the new toolbar, which is being worked at actively. You can provide feedback with the feedback link at the top of each page, when you are in Beta mode. —TheDJ (talk • contribs) 15:24, 30 December 2009 (UTC)

I just made a proposal on Bugzilla to just redo the aesthetics of the classic toolbar. ViperSnake151  Talk  17:23, 30 December 2009 (UTC)

This is a very good idea, some things here in wikipedia are somewhat confusing sometimes (specially for newbs). But I don´t see any problem with the image and table buttons (at least not in the button picture). - Woglinde 02 (talk) 19:20, 30 December 2009 (UTC)

While I'd happily support any of the changes proposed here, I most firmly stand by my initial proposal. That being the three numbered bullets at the beginning of this section – these address the greatest problems with the usability of the toolbar. The rest is more cosmetic. Is there consensus on whether or not the three bullets should be implemented? Anxietycello (talk) 04:53, 31 December 2009 (UTC)

• The revised small text button (the single large "E" with arrow to a small "e") seems to have consensus.
  — V = I * R (talk to Ohms law) 03:51, 3 January 2010 (UTC)

I'm currently requesting approval for a bot that will place a message on the talk page of any new namespace 0, 6, 10 or 14 article with ambiguous links. See Wikipedia:Bots/Requests_for_approval/WildBot. Josh Parris 03:00, 3 January 2010 (UTC)

I propose that the Request Tags be used as follows:

Tag	Wikitext	Used for	Used by
Done	{{done}}	Request is met and completed	Sysop or Bureaucrat only
Not done	{{notdone}}	Request is not able to meet requirements given	Non-admin's (Apply Tag) Sysop's or Bureaucrat's (Apply tag and Verify Non-admin placed tag)
Comment: Error: There was no comment detected! Please follow the instructions at Template:AfC comment.	{{afc comment|}}	Leaving a comment for request submitter	Anyone
(none)

It would make it easier for everyone to manage requests.

I used the Y Done tag several times before I became an admin. We often see requests from new users, requests that can be fulfilled by any user that has the know-how. One common such request is to "add this interwiki link to this template", and then an experienced user responds "Done - But you could have added it yourself to the unprotected /doc sub-page".

The {{subst:done}} tag is a good an clear way to show that a request has been handled, to save other users from reading and pondering the request. I think the done tag can and should be used by anyone that fulfils the request, or sees that the request has been fulfilled, no matter if they are an admin or just an IP-user.

In some cases it is also correct for a non-admin to use the {{subst:not done}} tag, like when a regular user states: "Not done - Sorry, not technically possible to do with template programming". And perhaps this slightly more controversial usage of the not done tag: "Not done - Sorry, that would violate the following policies and guidelines: WP:A, WP:B, WP:C".

--David Göthberg (talk) 19:46, 30 December 2009 (UTC)

To clarify what I put above, the proposal was for rights requests rather than general requests, if it is already in use let me know. Thanks

talk

) 19:52, 30 December 2009 (UTC)

It would be useful if someone explained the current usage of the above tags in a user rights request situation as

talk

) 19:58, 30 December 2009 (UTC)

Ah okay. Right, my description was for general usage on any talk page. But you mean for rights requests specifically. Since you asked me to come here and comment more: I am an admin but I don't work with rights requests, so I don't know anything about that. I mostly work with technical stuff like template programming, site wide CSS, the MediaWiki interface etc., and that's why I was made admin so I can edit those areas.

So are there any users and admins here with experience in user rights requests that can comment here?

--David Göthberg (talk) 23:35, 30 December 2009 (UTC)

I think that the only people to decline rights requests, such as rollback or autoreviewer, should be admins. Anyone may add their own comment on a rights request, though, and the decision of an admin on granting or withholding rights could be appealed at

WP:AN. EdJohnston (talk

) 00:06, 31 December 2009 (UTC)

I'm not sure what's being requested here. Anyone fulfilling a request and mark something as being {{done}} (for example, a edit request posted on the talk page of a semi-protected article). I've also used the {{done}} tag to mark on-wiki that I've received (and acted upon) someone's email to me, which isn't necessarily tied to any of my flags (admin, 'crat, or oversight). I don't see why we'd need a policy on just using a template... EVula // talk // ☯ // 19:05, 3 January 2010 (UTC)

I discovered today that

Fixed. --Kotniski (talk) 18:51, 3 January 2010 (UTC)

It's certain that the same location has the same coordinates even when it's described in different languages. Can we make a bot to copy coordinates info among articles on different wikis describing the same location? Or something more, keep them sync? --Liangent (talk) 10:04, 4 January 2010 (UTC)

If two articles give different coordinates for the "same" location, which one is correct? Jan1naD ^{(talk • contrib)} 11:20, 4 January 2010 (UTC)

That is (obviously) an exception that should be flagged for resolution by a human. But otherwise the idea seems reasonable.

talk

) 16:23, 4 January 2010 (UTC)

It's also very difficult to know 100% if the location in one article is the same in another. The details levels between the different language versions, often mean that an interwiki is up/down merged to another article in another language. Such things happen. You only have to look at the problems Google has in finding good matches between placemarks and Wikipedia articles in their Place Pages. For instance: here the placemark Bowling Green Associates LP is matched against the Wikipedia article Bowling Green Park. Though the company has a windowview at the park, the information is hardly really relevant. The match occurs due to placemarkers that are in close proximity to each other and have partly matching names. A bot might have an amount of "false positive" matches that we might not appreciate. Perhaps an assisted editing tool is more appropriate ? —TheDJ (talk • contribs) 13:51, 5 January 2010 (UTC)

I think we should do this. The bot would use interwiki links rather than Google's fuzzy matching, so Google's problems are a red herring. How do bots already match up articles across languages? If they're accurate, there shouldn't be a problem in doing this. Fences&Windows 03:32, 6 January 2010 (UTC)

It seems Google matches them by coordinates, but we match them by interwiki. --Liangent (talk) 04:37, 6 January 2010 (UTC)

It isn't terribly difficult to figure out what some articles are in most common languages. I do it all the time, it's easy. :) EVula // talk // ☯ // 04:47, 6 January 2010 (UTC)

This has certainly been done before (though perhaps as a one-off, not with a bot that continuously keeps the articles in synch). User:The Anome was certainly doing a lot of such work (this is an example).--Kotniski (talk) 09:06, 6 January 2010 (UTC)

Actually, that particular batch was generated by cross-matching a mixture of GNS data, region maps, and other data sources (a lot of which was generated by User:Kotniski), as opposed to interwiki data: Polish places have far greater levels of name reuse than normal, making this a special case. More recently, User:D6 has been doing a lot of interwiki geocoding work. -- The Anome (talk) 18:58, 6 January 2010 (UTC)

What do people think about adding links to user rights request articles to this page, as it crrently looks like there isn't anyone at the moment and it would it easier to direct people to a central place for request such as:

• RfA and RfB Requests
• Rollbacker Requests
• AWB Approval
• Confirmed Requests

and all other user rights related requests. If anyone thinks this would be a good idea then I'll add a section on

An argument against is that if you're ready to make such requests, you should already know where to look. WP:RQ is more of a help page for relative newbies, isn't it? Rd232 ^talk 11:52, 6 January 2010 (UTC)

I propose adding a userright abusefilter-immune. Users with this right would not have their edits checked against any filters at all. This userright could be grouped in with the sysop packages, and possibly as well as other privileged groups such as rollback or autoreviewer. Since the majority of filters do not check against old users, this should really speed things up for the server, as well as minimizing the damage in case any accidents happen. Triplestop x3 19:01, 28 December 2009 (UTC)

Support

1. Not a bad idea. TheWeakWilled (T * G) 14:54, 29 December 2009 (UTC)

Oppose

1. Oppose—it's not the Abuse Filter, it's the Edit Filter... a key difference. If it existed soley to weed out abuse, exempting trusted users would be a perfectly logical step. But it does more than that: it checks for accidental removal of references, for instance. Secondly, after creating a new filter, admins are likely (encouraged, I think) to test it by making some dummy-edits themselves – this would be problematic if they were all immune. Thirdly, the issue of to whom the right should be assigned outside of the sysop-bundle would cause so many problems as to make it unviable. ╟─TreasuryTag►prorogation─╢ 14:58, 29 December 2009 (UTC)
2. Oppose As much as I love the idea, I would have to say no. There are two main reasons. If almost every user has the right, there is barely a need for a filter. Plus, admins do a test, like Treasury Tag (talk) mentioned, admins would not know if it works. Each filter has conditions, and most stop at the first line because they just look for users with certain specifications. Btilm 17:47, 29 December 2009 (UTC)

   If you look at the filters, almost all of them have conditions checking whether or not the user is autoconfirmed or has a high enough edit count, so admins are not affected anyways. Checking admins and other users in privileged groups against the filters is a waste of CPU time since all of them would either be autoconfirmed or have a high enough edit count to not trigger the filters anyways. I think most admins make new accounts for testing or do it on another wiki. Triplestop x3 20:40, 29 December 2009 (UTC)

   Is there a good reason to force that behavior, though? (I don't know, I'm really asking)
   — V = I * R (talk to Ohms law) 20:56, 29 December 2009 (UTC)

   Don't worry about CPU time being wasted. EVula // talk // ☯

   // 05:38, 30 December 2009 (UTC)

   Exactly. Now if it was about to be turned on and off by the user, that might be different, but that would sound like being able to assign and remove user rights. Btilm 03:04, 1 January 2010 (UTC)

3. Oppose As far as I know individual filters can be told to ignore certain user rights groups so I see no reason to force this behaviour when it can be decided on a per-case basis.
   Ask me
   ) 21:04, 29 December 2009 (UTC)
4. Considering the fact that this is a blanket solution to a nearly non-existent problem (and, when it does come up, it can be tweaked on an as-needed basis, as Chillum said), I don't think we need to change anything. EVula // talk // ☯ // 05:38, 30 December 2009 (UTC)
5. Oppose— During the date delinking arbitration case User:John was swept up into the dispute for making a hand full of edits over a three month period. Arbitrator Wizardman voted to restrict John for a year. A search of the abuse logs showed Wizardman had made over 25 similar edits. [2] There is no reason to hide the actions of administrators or arbitrators. -- SWTPC6800 (talk) 06:07, 30 December 2009 (UTC)
6. There are situations where all users should be subject to edit filters, and trivial means to exclude trusted users in the general case. This is a can of worms that we definitely don't need to fish this particular pond. Happy‑melon 22:30, 30 December 2009 (UTC)
7. The edit filter is useful not only for detecting and reverting vandalism, but also finding and fixing occasional mistakes made by established editors. If those established editors were able to bypass the edit filter the mistakes would be significantly harder to find and fix. Reach Out to the Truth 14:37, 6 January 2010 (UTC)
8. I agree with all of the above. I would also point out that the software would still have to do the check that the user has the particular right, so any speed improvement would be less than trivial. Mr.Z-man 20:13, 7 January 2010 (UTC)

Neutral

1. Confused I see good arguments both ways. On the one hand, admins are mostly immune to the filters anyway, so why not just save time and skip right over them? For testing purposes, anyone can make an openly-declared sock, so I don't think that's an issue either. On the other hand, though, how much processing time would really be saved by such a measure? If the abuse filter is just going "skip, skip, skip" etc all the way through, it's probably using just a small fraction of the amount of processing time that is used when a filter actually triggers. Is it possible to put a number on how much processor time would be saved? Also, I can see actual downsides to this: if the exemption userright is open to non-admins, even if only as a bundle with some other userright, people will strive to get it, and some of them might come to see it (wrongly, of course) as a privilege to break the rules. Lastly, there is the matter of the "tag" type filters that are good for catching honest mistakes, and which for the most part do currently trigger even for long-established users, because everyone makes mistakes. -- Soap ^Talk/_{Contributions} 01:43, 30 December 2009 (UTC)

A while back i suggested that articles should have a section at the end called 'backlinks' (or something more appropriate) that lists all articles that linked to that article using Template:Main but nobody could figure out a way of doing it. Could Template:Main be modified so that {{Main|Article A}} creates a link to a hidden category [[Category:pages that link to Article A (using Template:main)]]. The editor of Article A could then very easily create a section 'backlinks' by simply going to that category page and copying all the links. I know that 'pages that link here' lists something similar but I am only interested in those links that are the result of Template:main. Lemmiwinks2 (talk) 21:25, 4 January 2010 (UTC)

You mention an earlier discussion. Could you please link to it? In regard to your proposal, there would be very few such links for a given article, and those that exist are generally incorporated into the lead section or the See also section at the end. 210.84.6.25 (talk) 09:07, 6 January 2010 (UTC)

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_53#backlinks Lemmiwinks2 (talk) 07:16, 7 January 2010 (UTC)

WP:Namespace seems to indicate that "T:" is a shortcut of "Template:" that can be used to refer to templates. I notice however that if I type in T:cite book it doesn't take me to Template:cite book as I expected. Is there any way to implement this automatically or are manually created redirects the only way? Of course that's presupposing there isn't a good reason this has not been done already. Lambanog (talk) 06:25, 31 December 2009 (UTC)

See: Wikipedia:Village pump (proposals)/Archive 56#P: and T: namespace aliases It may happen... eventually.
— V = I * R (talk to Ohms law) 06:43, 31 December 2009 (UTC)

Well in any event I created some manually for the most common {{

cite}} templates if only for my own use. Lambanog (talk

) 07:27, 31 December 2009 (UTC)

Why not make 't' short for talk? Tim1357 (talk) 03:48, 1 January 2010 (UTC)

In that case, then how would you identify between a talk of article namespace, user namespace, template namespace and the other namespaces which all have their respective talk pages (except for images)? - Woglinde 02 (talk) 17:13, 1 January 2010 (UTC)

I would think T would be for article talk as article-space is the prefixless namespace. The others could be UT (user talk), TT (template talk), etc. --Cybercobra (talk) 23:06, 1 January 2010 (UTC)

tt is the interwiki prefix for the Tatar language, so that one can't be used. Reach Out to the Truth 15:04, 6 January 2010 (UTC)

To get around this, T:TXXX is normally used as the shortcut for a template talk page; eg,

talk

| 10:43, 8 January 2010 (UTC)

Doing so creates

cross-namespace redirects, and creating more of those is not normally desirable. Amalthea

19:34, 8 January 2010 (UTC)

Does this conflict with the Tools: namespace? Josh Parris 23:38, 1 January 2010 (UTC)

There is no such namespace as "Tools:". The interwiki prefix "tools:" would be unaffected. 210.84.6.25 (talk) 09:02, 6 January 2010 (UTC)

{{

tl}} is already a short (and more elegant, imo) way to refer to templates. –xeno^talk

19:39, 8 January 2010 (UTC)

After proposing a merge for {{In-universe/Anime and manga}} with {{in-universe}} it was suggested by Anime and Manga Wikiproject to see about having a larger proposal to merge all such similar cleanup templates of which there are several and using fields for all of them that are very similar instead. The reasoning is that it would make things more easy to find as there would be fewer tags. The only downside would be that not everyone would realize you can add a field, but at the same time a lot of people don't know about a number of cleanup template tags already.陣内_Jinnai 20:15, 7 January 2010 (UTC)

Along the lines of {{notability}}? --Izno (talk) 20:25, 7 January 2010 (UTC)

Sounds like a good idea to me.

Template:game cleanup strikes me as an example of something that could be merged.--_{ZXCVBNM (TALK}

) 01:54, 8 January 2010 (UTC)

Sounds like a good idea to me also, but I wouldn't try ramming through a huge change all at once. Gain consensus and then merge each individually. You'll step on less toes, and bruise fewer egos, that way.
— V = I * R (talk to Ohms law) 10:20, 8 January 2010 (UTC)

I think merging the anime and manga one into it first to see how well it works would be best. Then, once that's working, add the functionality so the others could be added fairly easily and go from there. ···日本穣^? · 投稿 · Talk to Nihonjoe 06:02, 9 January 2010 (UTC)

We've been discussing some changes to Wikipedia:Articles for deletion for the last month or so, at Wikipedia talk:Articles for deletion#Consolidation. There's quite a bit of support for changing the name to "Articles for discussion" (see: here), with the largest change being to specifically allow disputed merge discussions to utilize the AFD process (which is really a simple acknowledgment of what is already occurring in many AFD's). We're at a point now where input on actual implementation details would be appreciated. Please comment at Wikipedia talk:Articles for deletion#Implementation discussion
— V = I * R (talk to Ohms law) 10:28, 8 January 2010 (UTC)

Hello, I post a request here about redirections, for example, a person say it is not good to replace the redirect link by the good link, for example: http://en.wikipedia.org/w/index.php?title=Free_software&action=historysubmit&diff=337234319&oldid=337231283 For me I think the best solution is the good link. Thanks in advance, regards — Neustradamus (✉) 21:05, 11 January 2010 (UTC)

This has already been discussed on this user's talk page several times:

WP:NOTBROKEN. Raywil (talk

) 21:39, 11 January 2010 (UTC)

Is it feasible to have a central list of edits that have deleted a whole section or a substational portion of it, so that public-spirited editors can review them and revert as necessary? Or would such a thing just become instantly overwhelmed? I am perennially concerned about the amount of Wikipedia material that is deleted by vandals or people making test edits and lost forever because no one notices. 86.150.102.84 (talk) 21:46, 10 January 2010 (UTC).

No content is lost forever, it will always be in the page history. --Cybercobra (talk) 22:01, 10 January 2010 (UTC)

Sure, but content is effectively lost forever if no one notices within a reasonable length of time, and where there is no continuity amongst editors such that a deletion will be apparent when browsing the article. After that, no one is realistically going to look back through years of edit histories checking every edit to see if content was removed for no good reason. 86.150.102.84 (talk) 00:02, 11 January 2010 (UTC).

Edits which look like they blank a lot of material are automatically tagged and can be viewed chronologically here and here – ╟─TreasuryTag►quaestor─╢ 22:03, 10 January 2010 (UTC)

I don't understand how this is usable. How is it known whether a trusted editor has checked an edit, and which edits are outstanding and still to be checked? 86.150.102.84 (talk) 00:02, 11 January 2010 (UTC)

If one has rollback permissions, this can be somewhat inferred by whether a rollback link is present next to the edit. But this is not 100% accurate. There is no "Blanked Sections Patrol" as of yet. --Cybercobra (talk) 00:19, 11 January 2010 (UTC)

I see. Is this something that is being actively considered, do you know? 86.150.102.84 (talk) 01:22, 11 January 2010 (UTC).

Flagged revisions does something like that. Tim1357 (talk) 01:27, 11 January 2010 (UTC)

Flagged revisions have been mooted for years and years. Are they any nearer to being implemented in the English Wikipedia, do you know? 86.150.102.84 (talk) 02:06, 11 January 2010 (UTC).

Yes, they are. See the http://techblog.wikimedia.org/ . - Jarry1250 ^{[Humorous? Discuss.]} 18:38, 11 January 2010 (UTC)

Unfortunately, this seems unlikely to adequately address the problem that I have highlighted. This proposal you refer to says that "the mechanism would be activated on a per-page basis only", and goes on to imply that it would be applied only, or mostly, to "pages with a very high risk of malicious editing". These are exactly the pages where content blanking is already most likely to be spotted and reverted. The pages at higher risk of unnoticed (and hence effectively permanent) content loss are the less-visited and less-monitored ones. 86.147.160.108 (talk) 19:42, 11 January 2010 (UTC).

No, no such proposal for a patrol like that has been made. --Cybercobra (talk) 20:34, 11 January 2010 (UTC)

Until now, then. Do people here think it is a good idea? Its viability does somewhat depend on whether, as mentioned in my original post, it would become instantly overwhelmed, and on some mechanism to decide with editors should be allowed to "tick off" a blanking edit as checked and OK'd. I'm not sure how widely recognised the seriousness of this effectively permanent loss of material is within Wikipedia. In the last year, I have deliberately checked probably about 100-200 unloved articles (ones that I usually never monitor) for long-standing (months-old or years-old) loss of content. Of these, eleven were missing whole sections or very large chunks that had been deleted with no explanation or justification and never noticed. Extrapolate that to the whole of Wikipedia, over many years, and you see the problem. 86.147.160.108 (talk) 21:27, 11 January 2010 (UTC).

Patrols, like the

New Pages Patrol, provide the "check off" functionality. --Cybercobra (talk)

21:38, 11 January 2010 (UTC)

Even better! I notice that, despite everyone's very helpful and informative responses, no one else has expressed any actual support for this idea. How hard would it be to give it a trial run? It seems to me that most of the infrastructure is already in place: blanking edits are already tagged, and the patrol-page mechanism is apparently proven. Ideally, one would want a list of blanking edits that had gone uncorrected for more than, say, a day (so as to only pick up deletions that had fallen through the usual net), but that sounds like it could be entirely non-trivial to implement. 86.147.160.108 (talk) 23:08, 11 January 2010 (UTC).

It would require software development to implement such a feature, which, as you can tell by flagged revs, is notoriously slow. --Cybercobra (talk) 23:10, 11 January 2010 (UTC)

My impression (and I could be completely wrong) is that a good part of the reason why flagged revs stalled for so long is because nobody could decide if there was consensus to do it. Anyway, this seems much easier than implementing flagged revs, would you not agree? 86.147.160.108 (talk) 23:16, 11 January 2010 (UTC). [Clarification: when I say "much easier", I'm talking about the vanilla version that just patrols all blanking edits, not the one that tries to detect uncorrected blanking edits, which I can see would be considerably harder.]

I'd like to propose that the wikimedia foundation run a banner once per month promoting editing. Smallman12q (talk) 16:53, 11 January 2010 (UTC)

Better suited to

WP:VPPR. Kind regards, Spitfire^Tally-ho!

16:56, 11 January 2010 (UTC)

I do understand that it probably won't succeed...but its still something I personally would like to see.Smallman12q (talk) 18:18, 11 January 2010 (UTC)

I would like to differentiate wikipedia-internal links in an article into those with common information and those with deeper and more special information about the topic. Currently articles contain many links to other articles with which they are only generaly related. I just dont like beeing thrown out of context, beeing presented with unexpected and misleading information by a click too far. Like the STL page contains a link explaining header files in general, but not STL header files in special. Or in geothermal power there is a link to gigawatt which explains SI units but does not provide information about produced geothermal gigawatts. It could be possible to divide an article into a page with basic information and pages with detailed information or sophisticated annotations requiring higher education. The difference between links to general pages and those to closely related pages containing deeper details could be made visible via different fonts.95.88.205.143 (talk) 02:27, 13 January 2010 (UTC)

this was archived prematurely, possibly due to the holidays; discussion selectively retrieved. See Wikipedia:Village_pump_(proposals)/Archive_56#To_disable_the_immediate_indexing_of_unpatrolled_pages_into_Google_search and the related Wikipedia:Village_pump_(proposals)/Archive_56#Mark_pages_less_than_24_hours_old_for_no-indexing.

Proposal Based off the discussion here, this proposal would disable the immediate indexing of all new page into Google until the pages have been patrolled. This would help prevent blatant hoaxes, attack pages, clear BLP violations and test pages from being immediately appearing on Google searches. Basket of Puppies 21:37, 10 December 2009 (UTC)

Discussion

• Question Is this technically feasible? I strongly support this idea, but I seem to recall it being shot down before on such grounds. How do you propose to implement this? Am I wrong in thinking {{NOINDEX}} will not work in the mainspace?  Skomorokh  22:41, 10 December 2009 (UTC)
  • I believe it would require a software change of some sort. Doesn't sound too complicated though. Rd232 ^talk 22:56, 10 December 2009 (UTC)
    • From my understanding, it doesn't work in the mainspace currently but that can be changed by the devs. Additionally, if I recall correctly, noindexing only saves it from search engines that "listen" to the coding that requests the page not to be indexed. The internet is an unwieldy place, and I don't think brushing new articles "under the carpet" from certain mainstream search engines and/or mirrors will attain the goal we're seeking. Killiondude (talk) 22:58, 10 December 2009 (UTC)
      • It depends on the goal. If the goal is to deter novelty-article spamming, not making it into the "big" search engines cuts out much of the reward. If the goal is to censor from all mirrors, that is pointless and, except for material that would be WP:oversighted anyways, a bad idea. davidwr/(talk)/(contribs)/(e-mail) 23:02, 10 December 2009 (UTC)
• Comment Special:Newpages is marked "noindex, nofollow." davidwr/(talk)/(contribs)/(e-mail) 23:03, 10 December 2009 (UTC)

More discussion is needed on

1. the principle
2. the practical aspect re search engine indexing: how soon after removing a noindex instruction is a page going to be indexed;
3. the mechanism for identifying "new" pages for noindexing, and for declaring such new pages suitable for indexing.

Rd232 ^talk 17:20, 13 December 2009 (UTC)

On point 2, I believe Google and other major search engines index and reindex Wikipedia extremely rapidly - typically hours, and more like minutes than days. On point 3, I would say I'm not sure if

WP:NPP is the best mechanism. I'm inclined to set a time limit, so that articles younger than say 24 hours aren't indexed unless an index template is specifically added. After that indexing is automatic and mandatory. This would be handled in software by respecting NOINDEX in mainspace, but only for articles less than 24 hours old. (A bot can remove the template once the article is 24hrs old, and the template no longer applies.) Only a handful of articles merit immediate indexing, and that handful should be easily monitorable. Rd232 ^talk

17:23, 13 December 2009 (UTC)

Yea the discussion here died out over the holidays, but it seemed to have died out before the actual start of the holidays. It's not a terrible idea, and I don't think that I would actively fight against it, but I don't particularly think that it's a great idea either. There are some difficult implementation details that would need to be settled first, not least of which would be some sort of editorial control over how it worked. Personally, I think that this would be too much trouble to actively pursue (especially considering the fact that there's little if any developer time/resources to go around). Also, there are existing easy workarounds to achieve the same result by temporarily (re)locating articles outside of the mainspace (in

Wikipedia:Article incubator, for instance).
— V = I * R (talk to Ohms law

) 13:19, 6 January 2010 (UTC)

• I'm aware of a recent incident where an attack page remained in the cache of a popular search engine for more than a day after we deleted it; So if this can be done I think there would be some benefit. I also like the idea of not releasing articles onto Google et al until they've at least been through a little bit of wikification and categorisation. ϢereSpielChequers 00:28, 12 January 2010 (UTC)

At the moment there's no simple way to indicate that an "non-free" file is actually "sort-of-free", that is it is released under some sort of license which doesn't allow commercial use and derivative works. It would be useful to be able to indicate this. I am not suggesting that we should allow uploads with these licenses, just that we have some machine-readable way of recording the fact. Does anyone have any ideas on how this could be done? And how we could find such images automagically? Angus McLellan (Talk) 22:37, 11 January 2010 (UTC)

I don't understand. How do the licensing templates not suffice? --rannṗáirtí anaiṫnid (

coṁrá

) 22:43, 11 January 2010 (UTC)

Ah .. is it that those templates may say what license a file has but do not add the file to a category. Maybe that would be the simple solution? --rannṗáirtí anaiṫnid (

coṁrá

) 22:47, 11 January 2010 (UTC)

There are lots of Creative Commons licenses we do not accept. Look at where {{

cc-by-nc-nd-3.0}}, {{cc-by-nc-3.0}}, {{cc-by-sa-nc-3.0}} redirect to. For some re-users of Wikipedia content these licenses might be free enough but they won't be able to tell that those were the license terms as we change those to simply non-free. See File:Hogelrendering.jpg for an example. Angus McLellan (Talk)

22:57, 11 January 2010 (UTC)

Those redirects seems screwy. Provided the content also meets our NFCC, I don't see why those licenses should be blanket disallowed like that. It's not free enough to be Wikipedia-Free, but I don't see why the information that acceptable non-Wikipedia-Free content is somewhat free should be truncated. --Cybercobra (talk) 23:09, 11 January 2010 (UTC)

OK. They might be "free enough" for others. But how would we use them? What would we be "recording" for others? --rannṗáirtí anaiṫnid (

coṁrá

) 23:42, 11 January 2010 (UTC)

It's rather vain of us here and now to assume that Wikipedia will last forever, or that whatever replaces it will necessarily be in the USA, or that it will use the same licensing policy. So it's a good idea to future-proof our work as much as we can. This information might be valuable to someone now or in the future. Best to preserve it while we can. Angus McLellan (Talk) 00:08, 12 January 2010 (UTC)

I see. (I think.) If I get you right, the idea would be to store (for example) CC-NC images on our servers (and allow people to find them?) but not to allow them on the 'pedia right now. I don't think it's a question for the 'pedia but maybe the Commons.

I think there would be problems with user unfamiliar with licenses not understanding why we they wouldn't be allowed use them. I also don't see why would should be giving over server space and resources to files that are of no use to us. If I get you right, I'd say start a project of your own (on your own servers) to collect such images.

Alternatively, are you just saying to not actually delete them but keep them locked away somewhere inaccessible so that they may be used again in future if policy permits? --rannṗáirtí anaiṫnid (

coṁrá

) 00:20, 12 January 2010 (UTC)

Sorry, none of the above. We'd only use them as non-free content so they need to meet

the criteria and would be deleted if they didn't. This is not an attempt to keep even more non-free files. We have too many to be manageable as it is. I'd like to preserve the licensing information even though we won't use it. Just about the only case I can think of where it may be useful for us to know is if we have to decide between two non-free (in Wikipedia terms) images it would be least bad to keep the freer one if there was little to choose between them. Angus McLellan (Talk)

00:31, 12 January 2010 (UTC)

We've got various "modifier tags" that can be added to a non-free license tag, such as {{

Non-free with NC}}. It's simply a matter of using them. --Carnildo (talk

) 23:39, 11 January 2010 (UTC)

Thanks for the heads up on those Carnildo. I wasn't aware they existed. I think I shall make one for each possible not-free-enough CC license and then go and nag people about changing the unacceptable CC licenses to redirect to a modified db-f9 page with instructions on how to keep the original license data. Probably won't do that much good but it can't hurt either. Probably also worth adding the instructions elsewhere too. Now all I need is someone to tell me what piece of bot magic can find all the files which once had a redirects-to-speedy-delete CC license but don't any more. And then to code the bot for me. Well, if you don't ask you don't get. Thanks again! Angus McLellan (Talk) 00:05, 12 January 2010 (UTC)

Ah, you mean when we are using an image under a fair use claim according to

This is probably a horrible idea, but I just found myself wondering about this. For the low traffic, more out of the way articles, wouldn't it be a good idea to start redirecting their talk pages to someplace more central to the article topic? using an associated WikiProject talk page springs to mind, or a category talk page, or something like that...
— V = I * R (talk to Ohms law) 17:12, 13 January 2010 (UTC)

Seems like a decent idea, the only problem is how do you decide which pages to have redirects, where they should all redirect to and who's going to go redirect them all--Jac16888^Talk 17:18, 13 January 2010 (UTC)

An alternative would be to have a bot track posts to low-volume talkpages on a WikiProject subpage, thus preserving the traditional and expected location for discussion while drawing attention to posts that might otherwise be ignored.  Skomorokh  17:21, 13 January 2010 (UTC)

Yea, who doing the work, and exactly how the work would be accomplished, would definitely be a sticking point. Just off hand, I'd (perhaps naively optimistically) think that we could hash out a guideline detailing the exact process details... Anyway, the bot idea is certainly interesting. That's already got my gears turning.
— V = I * R (talk to Ohms law) 17:51, 13 January 2010 (UTC)

You could use something in the direction of the Article Alerts system. But that would only work if the talk page is tagged for a specific WikiProject. But I do like this idea. Killiondude (talk) 18:01, 13 January 2010 (UTC)

I also like this bot idea. WP:Article alerts looks like a good system. Flatscan (talk) 04:29, 14 January 2010 (UTC)

Redirecting the pages probably wouldn't work because most talk pages house WikiProject banners. Skomorokh's idea has merit, though. –xeno^talk 17:53, 13 January 2010 (UTC)

Not to toot my own horn here, but I do have Ohms Law Bot (task list · contribs), which already does something similar to the bot idea which we're discussing here. It creates lists of articles, based on category trees (the category and all sub categories), which can then be used as sort of customized watchlists by pointing Special:RelatedChanges at the list page. That idea could easily be expanded to work large portions of Wikipedia. The only thing is, I don't want to run something like that from my personal system(s). I find it useful to do for myself, and I wouldn't mind doing it for a few other people, if there interested, but really making it a Wikipedia wide project would be somewhat taxing on my personal computing resources... I suppose that I could request a toolserver account, but I'm not sure what all is involved in that.
— V = I * R (talk to Ohms law) 18:16, 13 January 2010 (UTC)

It would be great with a bot that:

• Watches talk pages tagged with a certain Wikiproject template,
• records edits when the talk page has not been edited by an other user for a long time,
• there is no edit by an other user within a couple of days after,
• it is not a bot edit or edit to the templates only,

and copies it over to a central page under the Wikiproject. Old comments would be removed when the list gets too long or after a certain time. The key is to reduce the amount of noise so people actually watch this central page. --Apoc2400 (talk) 13:31, 14 January 2010 (UTC)

• The user page User:Hallucegenia complains about one new user's difficulty choosing a username, in the face of so many usernames having been already used. As time goes on, the time may come when all sensible usernames have already been taken.
  1. How can I, or a non-admin new user, find if any possible given username has already been taken?
  2. If a username has not been used for x years, let it be made able to be registered by a new user?

  Anthony Appleyard (talk) 11:18, 8 January 2010 (UTC)

See Special:ListUsers and Wikipedia:Changing username/Usurpations. Many readers have accounts but never edit. I don't think it should be allowed to automatically take over a name without trying to ask the owner. PrimeHunter (talk) 11:39, 8 January 2010 (UTC)

I find it hard to believe that we've run out of available usernames, given the nearly infinite amount of combinations that one can derive from 26 alphabetic characters, 10 numerical characters, and another few dozen assorted characters. We do have WP:USURP for names that simply haven't been used, but we usually don't allow new users to usurp existing accounts. EVula // talk // ☯ // 21:50, 8 January 2010 (UTC)

But perhaps this comment misses a key point of the original proposal -- There may be almost limitless possible usernames, but many fewer pronounceable, memorable, or easily distinguishable ones. For purposes of this discussion I think all three of those attributes are desirable, and I don't think anyone's suggesting that almost all the names are presently gone. It's more a matter of wise planning ahead of resources. - Regards, PhilipR (talk) 10:28, 15 January 2010 (UTC)

Isn't the restriction against usurping accounts that had been active at one time due to our licensing requirements/need to attribute the edits made by that user at that time? Shereth 22:45, 8 January 2010 (UTC)

Vehemently oppose. Many of us have been around long enough, or come and go over long periods of time that it will open the door to confusion. If an old username reappears I do not want to have to wonder if it is the same person or has been usurped. <redacted> alteripse (talk) 12:18, 11 January 2010 (UTC)

Your second sentence is a completely unnecessary personal attack. You might want to remove that. — Martin (MSGJ · talk) 12:55, 11 January 2010 (UTC)

I don't care whether he wants to remove it, I have done so.

damned, that is totally unacceptable. Happy‑melon

13:22, 11 January 2010 (UTC)

Oppose. Usernames should not be re-used for the reasons above and many other technical and legal problems (database primary keys, attribution of licensed content, etc.). If you can't get the username you want, just add a random number to the end and that will probably be free. OrangeDog (τ • ε) 12:56, 11 January 2010 (UTC)

Though if a user has no edits, and hasn't logged on for say five years, it surely can't do much harm to allow someone else to use the name if s/he wants? We'd all be happier seeing simple and readable names rather than random strings.--Kotniski (talk) 13:33, 11 January 2010 (UTC)

Which is currently allowed via the WP:USURP process :) Shereth 14:31, 11 January 2010 (UTC)

Which is hardly likely to be familiar stuff to a new user choosing a username. If old, unused names could be vacated automatically, then anyone happening to choose one would get it without any extra fuss.--Kotniski (talk) 15:36, 11 January 2010 (UTC)

A quick way to notice if a certain username is taken or not is to to type "User:Username". If there's a userpage there, there's a user. If there isn't, try to edit: the software will warn you if you try to create a userpage of a nonexistent user. If no warning appears, there's a user with name, even if without a userpage. Notice: the testing should be limited to checking the edit box, then go back or follow another link, don't save. Don't create userpages for users that didn't do so, or for names without a corresponding account.

A possibly more direct approach would be to search for "Special:Logs/Username", which will return nothing for nonexistent users, and will show the date of account creation even for accounts which have never been used to edit (unless they're very old, I believe, but in that case why not usurp?) --King Öomie 15:53, 11 January 2010 (UTC)

Oppose The contributions of our editors are copyrighted material that is licensed under CC-SA, which requires attribution. That attribution is via the contributor's user name. It seems to me that if we reissue a user name to another person, even if the original user has been inactive for 50 years, we could be violating the CC-SA license terms, in spirit if not in letter. There are plenty of possible user names without resorting to random character strings. --agr (talk) 15:23, 11 January 2010 (UTC)

• I would support vacating usernames of users that haven't logged in for 5+ years and have 0 edits (deleted or otherwise). –xeno^talk 15:30, 11 January 2010 (UTC)

  I would agree with Xeno; for me it's less about disused names, so much as unused names. If you create an account, and don't edit in 4 years, say (or whatever length of time), then you aren't going to have a history that so upset Alteripse. GedUK  16:06, 11 January 2010 (UTC)

  As mentioned above, you can take over a registered, but unused username by the usurpation process. A proposal to automatically remove unused usernames was also discussed at Wikipedia:Delete unused username after 90 days, and that proposal failed. You may want to read it, as many of the objections were not time dependent. Prodego ^talk 16:47, 11 January 2010 (UTC)

  What it came down to, looking at Bugzilla, is that someone asked if it would be done, and our then technical supremo replied (without any explanation) "Not really, no." Maybe when we get a new supremo, the reply will be different. But given the countless other bugs and feature requests waiting in the eternal pipeline, I wouldn't expect this one to have a very high priority.--Kotniski (talk) 09:50, 12 January 2010 (UTC)

  5 years (which I would support) is also substantially more lenient than 90 days (which I would oppose). This is also a very aged proposal, in 2006 I'm sure the situation wrt to desirable username availability was not as dire as it is in 2010. –xeno^talk 17:21, 13 January 2010 (UTC)

  I agree with that. I think that 5 years is probably a bit overkill, but it's probably more palatable to most to start off with a fairly lenient and then adjust from there if there is the need to do so. I'd advocate for something to simply show users as inactive along side of this, so that we would could see and track what's going on with the user base prior to actually removing anything from the database. I proposed something along those lines earlier, primarily with an eye towards the eventual implementation of some form of flagged revisions. It should be simple enough to add an "active" bool field to the table storing user data, and then set that based on the last login datestamp. Something like 90 says could be used to mark a username as inactive, and then 5 years/0 edits could be used for removal. It'd make tracking and user base statistics much more valuable, for sure.
  — V = I * R (talk to Ohms law) 16:16, 15 January 2010 (UTC)

• Oppose: There are more possible user names available than Wikipedia can ever use. Reassigning someone else's user name is a recipe for confusion and disaster.—Finell 02:58, 16 January 2010 (UTC)

Resolved

 – agreed upon version has been implemented Spitfire^Tally-ho! 18:13, 9 January 2010 (UTC)

An IP user seems to insist on overkilling the same point in the same sentence: Although it's not technically against policy in itself to be