Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

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

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

Get rid of PROD

I've been thinking about it for a while now. The process involved in PROD, while ideally designed to reduce the workload at afd, leaves too many articles open for deletion that simply don't have anyone watching them. Articles that have inherent notability (such as many facets of geographical locations. Towns and such in countries that do not have any involved English editors) can often be deleted without notice to anyone. These articles are not "less important" because they do not have any sources, or because they haven't changed in several years, or because they contain a bare minimum of information. These articles have broken the ground where other editors will one day expand upon and fill in information.

In short, PROD only determines that nobody is watching an article, not that its deletion is uncontested. All non-speedy deletions merit some discussion. - ʄɭoʏɗiaɲ ^τ _¢ 19:20, 3 November 2009 (UTC)

I don't know of an admin that would delete an article through PROD that they believe has poor reasoning to be deleted... I don't totally disagree with you, but there are people who watch WP:PRODSUM too.--Unionhawk ^{Talk E-mail Review} 19:24, 3 November 2009 (UTC)

This sounds more like an argument of deletionism versus inclusionism. As noted above, WP:PROD doesn't automatically delete pages after seven days. It still comes down to a judgment call by the acting admin. --King Öomie 20:44, 3 November 2009 (UTC)

Interesting page, thanks. I might have seen it before, but can't remember. I've just declined a PROD I saw there. –Whitehorse1 12:40, 6 December 2009 (UTC)

Admins should not be deleting article on-sight merely because they are an expired PROD. Spurious nominations can (and should be) declined. Shereth 20:46, 3 November 2009 (UTC)

Well you can look in the deletion log, and ask an admin to have a second look at deletions that look as if there ws a prod on a notable topic. Do you have some examples you would like restored? Graeme Bartlett (talk) 20:48, 3 November 2009 (UTC)

You are assuming an admin opens the article and looks at it. There are several different tools designed to allow one to delete entire categories (like old PROD categories) without the bother of having to manually open each page. Dragons flight (talk) 20:55, 3 November 2009 (UTC)

That would be bad, and I would be disappointed if that occurred (without review). People have been shot down at RfA's for missing a single CSD borderline case. If we have admins deleting entire categories of content without review, that would be a very bad example. —TheDJ (talk • contribs) 21:48, 3 November 2009 (UTC)

I would expect that an administrator deleting all expired prods without bothering to look at them would be admonished, if not desysopped. That's a severe misuse of tools. -- Atama頭 22:07, 3 November 2009 (UTC)

Well perhaps you should talk to the frequent deleters of PRODs and ask them about their process. (The history of PRODSUM makes it easier to identify who is is really doing the deletions.) For example, NuclearWarfare (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) is a frequent closer of PRODs and often deletes 20 such pages in a single minute. I would assume he uses a tool to accomplish deletions at that speed. Now, he could have reviewed every one of those beforehand, in which case there is no issue. Historically though there are certainly examples of people using tools to clear deletion backlogs with no review. For example, I remember someone deleting some 700 disputed fair use images without looking at their content or considering the validity of the dispute. Such people can get yelled at, but they are rarely desysoped. Dragons flight (talk) 22:45, 3 November 2009 (UTC)

I'd like to point out that when I was an admin, I often handled several days of PROD at a time. I'd open up dozens or hundreds of tabs, go through them all (removing more than a few nominations, although in general PROD seemed pretty accurate & I consider myself an inclusionist) either editing them or opening up the deletion field, and then I'd make a second pass. So even though the log would show many deletions a minute (and even per second if I was typing particularly fast), I was still reviewing them all exactly as they should've been. Doing it this batch way saved me vast amounts of time because I didn't have to wait for several seconds of loading & rendering time for each page. From the outside, I don't think there's any easy way to see whether NuclearWarfare is employing a batch method or not. (Although I suppose you could look to see whether there are miscellaneous edits or PROD removals in the 20 or 30 minutes preceding a mass-deletion.) --Gwern (contribs) 00:52 10 November 2009 (GMT)

• oppose if an article has no one watching it, I don't see it as much of a step towards creating a genuine article on the topic. Stubs are good up to a point, as sort of an outline for future development, provided it's actually a good outline. But I would think that the unwatched status of unwatched stubs might be correlated with them not being particularly good outline items. In cases where that's not so, the article can always be recreated. There's a legitimate concern that the editors who do care might have large watchlists and not notice the PROD, but that could be dealt with by formalizing the courtesy notices into a requirement. --Trovatore (talk) 20:54, 3 November 2009 (UTC)
• Oppose. Prod is a valuable process. There is a group of regular prod patrollers who could always do with extra help. I regularly prod patrol, and in my experience the vast majority of articles deleted by prod have no chance of meeting our criteria. We delete maybe 60-80 articles per day via prod, and I rarely deprod more than two from a single day. Prod avoids the drama and sucking up of time of editors that AfD involves, and it is less severe than speedy deletion. Admins don't just blindly delete expired prods as they can contest the prod themselves if they see fit, and any prodded article can be restored at any time. Another option if you don't have the time to properly improve a prodded article is to move it to the Article Incubator. Fences&Windows 21:20, 3 November 2009 (UTC)
• Oppose - I wonder what basis Floydian has for this argument, as it doesn't seem to match what WP:PROD states or how proposed deletions are actually processed. Articles that do not have any sources, haven't changed in several years, or contain a bare minimum of information would be as unlikely to be deleted via PROD as they would via AfD or CSD. As said above, every article deleted through PROD has been reviewed by an administrator who uses his or her own judgment regarding the deletion justification given when the deletion is proposed. Should we get rid of speedy deletions because someone might incorrectly put an A7 tag on a notable article subject that isn't being watched? -- Atama頭 22:05, 3 November 2009 (UTC)
• Oppose - PROD helps keep the workload at AFD manageable. Users' time is not an infinite resource, we should allocate it to discuss articles that actually might warrant a discussion. If anything we need to use PROD more. Any article deleted after a unanimous AFD could potentially have been PROD'ed. Mr.Z-man 23:16, 3 November 2009 (UTC)
• Alternative: WT:PROD#Userfy PRODs instead of delete?. Rd232 ^talk 00:57, 4 November 2009 (UTC)

The basis I have, which initially got me going on this idea (aside from my own opinion that as long as an article isn't utter BS of defamatory than it usually deserves a place here) was the over PRODing of articles by Less Heard van U (who is an admin I believe, and may have been deleting those articles after 7 days), who was doing so solely on the basis of A) a lack of sources and B) a certain size requirement. - ʄɭoʏɗiaɲ ^τ _¢ 03:00, 4 November 2009 (UTC)

If you think the articles should have remained, tell the deleting admin, and they should restore it as a contested PROD.--Unionhawk ^{Talk E-mail Review} 03:09, 4 November 2009 (UTC)

That's an issue to take up with the admin, or his/her behavior. There's no benefit to changing our policy based on one incident. BTW, you can see who deleted an article in the logs. Would be best to do that before making accusations. — The Hand That Feeds You:^Bite 18:58, 4 November 2009 (UTC)

PROD was intended to replace AFD and CSD. Somehow that process stopped halfway, and now we have 3 systems, instead of one good one. I wonder how much time it would take to take things a few steps forward again, sometime soon? --Kim Bruning (talk) 01:30, 5 November 2009 (UTC)

Kim, I think your memory is betraying you on this one. I don't believe anyone seriously proposed PROD as a replacement, but rather it was originally proposed as a way to take some of the load off a chronically overworked AFD. Dragons flight (talk) 01:56, 5 November 2009 (UTC)

I know at least some folks (like me ;-) )wanted it to be side-by-side and then eventually replace, because AFD at the time was really bad, and admin deletion sucks in general. AFD has improved since then, CSD hasn't. It might be nice to actually work on updating the systems with what we've learned since last time, and simplifying besides :-) --Kim Bruning (talk) 02:10, 5 November 2009 (UTC)

I don't know why we need multiple systems and huge bureaucratic structures for deletion proposals. There should be one template that you stick on the talk page if you think a page warrants deletion. Have a bot date these templates, then an admin comes round after the appropriate time and decides what to do (based on the arguments given, if any, plus his/her own knowledge about wider consensus). No fuss (well fuss about whether to delete the page, obviously, but no additional complications spawned by the process itself). Ah, but that would be too simple, we have to let the wikibureaucrats have somewhere to play... --Kotniski (talk) 16:14, 5 November 2009 (UTC)

We don't have to let 'em play at all! I think you could sort of treat it like a hygiene issue analogous to -say- malaria at the panama canal: Eliminate the breeding grounds for them and/or the vector (simplify and tidy areas where too much bureaucracy has encroached), and inoculate people against them (by getting people to understand IAR and consensus as early as possible)

Do you think we can still stamp out the disease? ;-) --Kim Bruning (talk) 22:21, 5 November 2009 (UTC) To be clear, I'm not sure AFD is as much of a problem area as it was years ago. I think the bureaucrats have retreated to other areas.

Getting rid of PROD would at least concentrate the problem in one area (AFD), rather then spreading it out. The real issue with the current deletion process is simple: it's not structured enough. Surveys and widespread general opinion have shown for quite a long time now that at least the perception, if not the reality of, our current deletion process is simply too random. I know from my own personal investigations that the admins who regularly participate in AFD definitely have a brain on their shoulders, and there is at least a DRV process now in order to take care of the more egregious deletion problems. Those two items make me fairly confident that the majority of deletions that do occur are at least defensible. The fact remains that the process itself is still far too random, however. We all know that there are articles that almost every would agree should be deleted, yet when those articles manage to be identified they can still be difficult to delete. More serious is the fact that many "borderline" articles continue to be deleted on a daily basis. What some deletion advocates seem to (continuously!) fail to grasp is just how permanent and therefore demoralizing and damaging deletion is to author/editors... I don't want to turn this into more of an Inlcusionist rant then it already is, so I'll end here by simply saying that I support deprecating the confusing and unnecessary PROD procedure.
— V = I * R (talk to Ω) 05:00, 7 November 2009 (UTC)

FWIW, the majority of deletions are via CSD. In terms of deletions per day, there are about as many articles deleted via PROD as via AFD, and about 10 times as many articles deleted through CSD as AFD and PROD combined. Mr.Z-man 05:33, 7 November 2009 (UTC)

Yeah. Honestly, I only use PROD if it's only borderline CSD. Most of my prods get deleted under speedy criteria.--Unionhawk ^{Talk E-mail Review} 05:43, 7 November 2009 (UTC)

The thing is that you guys are right. Nobody is disputing the point that probably 99.9999999+% of all deletions are perfectly acceptable... but, none of that matters. The 0.0000001% of deletions that are not acceptable are the ones that are noticed, and the fact is that they should be. No matter how much potential good that the proper deletions gain the project, the fact is that the few instances of bad deletions do enough damage to far outweigh the good. At least, in my opinion.

There are those who take similar views and create an ideology that "all deletions are bad", which is just as much of a problem as doing nothing with the current deletion process is. I personally feel that a temporary moratorium on deletions (and a short one at that, possibly even just a few hours) is at least called for. However, that action is predicated on the belief that we can and should actually make a change that will better the project as a whole. Article deletion for it's own sake shold be stopped. Preventing article deletions for the sake of preventing deletions should be stopped as well. The process as a whole needs to be tweaked, at least, and intentionally slowing it all down certainly couldn't hurt (although, admittedly I do recognize that doing so will anger a certain percentage of the editorial population). At the very least, if all but the most egregious deletions take 7 days (or possibly even a couple of days longer)... who or what is harmed by that?
— V = I * R (talk to Ω) 06:56, 7 November 2009 (UTC)

I would say that even if 5% of deletions by Prod were erroneous, the system is working fine. When people notice that their article is gone, they generally contract the deleting admin, and the article is restored. Abductive (reasoning) 07:01, 7 November 2009 (UTC)

No, no, no... anything as "in your face" as deleting articles simply cannot stand up to this line of thinking. If we were talking about normal open editing procedures then I would agree with the point that you're making here, but the simple fact is that we're not.

Article deletion needs to be treated with the same... "respect" (for lack of a better word) that blocking is treated with, and for the same reasons. I'm not arguing that the deletions are a mistake at all, just as the vast majority of blocks are perfectly acceptable. However, in the exact same manner that good blocks still create controversy and emotion, deletions will and should cause the very similar reactions.

Think about this: if there was some sort of a "speedy block" policy/procedure being proposed, what would your reaction be to that? Granted, the analogy is far from perfect here, but at least give it a chance.
— V = I * R (talk to Ω) 07:21, 7 November 2009 (UTC)

I guess I was just wondering why you seem to have a problem with the lack of a formal process for PROD and not for CSD, even though PROD can be overturned by anyone for any reason at any time. Why are you assuming that all of the bad deletions come through PROD? It isn't a "speedy" procedure at all, so your analogy doesn't make any sense. PROD takes as long as an AFD. Mr.Z-man 17:05, 7 November 2009 (UTC)

Actually, if I had my druthers, I would prefer to severely restrict the use of CSD, along with simply switching the PROD procedure to use AFD instead (which is effectively what we're talking about here). I don't really believe that any change in the deletion process is possible, but this at least started a discussion about it. It's just... complicated. For newer editors, and especially for part time editors (which, in my view, are probably the most important editorial members of Wikipedia), the fact that there are three different processes with a fourth follow up (CSD, PROD, AFD, with DRV to follow up) is simply confusing and overwhelming. The WP:DELETION document is in a perpetually confusing state. Whether someone comes along and decides to start one of the deletion processes on an article is way to random, and CSD and PROD almost always occur too quickly for non-regular editors (and even many regulars) to really follow the process (never mind the fact that there are simply too many deletion discussions to really follow). PROD does take as long as AFD, but it's a mostly silent procedure so the perception is still there of fast change.

Anyway, as I said earlier I don't really think that there are many bad deletions, if there are any at all. This isn't actually a discussion about reality though, it's a discussion about perceptions. All of you who oppose this proposal are on solid factual grounds, but the fact is that doesn't change the perceptions of those who are supportive. We're talking past one another still, at this point.
— V = I * R (talk to Ω) 21:31, 7 November 2009 (UTC)

• Oppose. The proposer has brought up some hypotheticals, but I don't see any evidence that clearly notable articles or stubs are being routinely deleted via the PROD process simply because nobody is watching them. Sure, it could happen, but it's very unlikely. The system works, there is oversight to it, there's a strong fail-safe worked in to curb abuse (anyone can ask for it back at any time, an article can only be marked with a PROD once and only if it meets certain criteria.), and while having three separate processes can be confusing to outsiders, it's not that hard to explain things. I'm not entirely convinced PROD is necessary anymore, to be honest, since I'm not sure the problem it was intended to solve exists anymore. But I see no reason it should be dismantled because of what might happen in theory (if we're doing that, let's drop CSD first. In theory, one could get the main page deleted that way). --UsaSatsui (talk) 14:59, 7 November 2009 (UTC)
• Oppose. Most PRODs in my experience are merited (and I deleted hundreds if not thousands of PRODs), usually have been looked over by a second user (excluding the deleting admin), and they do us a genuine service in considerably lightening the load on AfD, letting people focus on truly borderline articles. The userfication proposal has merit, but that's a separate issue (though I encourage Floydian to take it up next!). --Gwern (contribs) 00:57 10 November 2009 (GMT)
• Oppose I regularly partrol PRODs, and regularly deprod about 5-10% of what's PROD'ed. I routinely restore prods per request... just check my talk page archives. The problem may be with individual admins not doing their jobs well, but not with PROD itself. Jclemens (talk) 04:23, 10 November 2009 (UTC)
• Oppose. It's too easy to stop, if anyone really cares. Unschool 06:14, 10 November 2009 (UTC)
• Oppose. PROD is vital for its drama-reducing effect on the deletion process.—S Marshall ^Talk/_Cont 21:49, 10 November 2009 (UTC)
• Oppose, but that's not to say that the process doesn't need serious improvement. Unwatched and uncared-for pages are a problem (I've seen many decent articles go), and the deletions shouldn't be done blindly. That said, the process has its place. As an idea it's much better than what AfD has become. Let's delete AfD instead. I'm not kidding. --wwwwolf (barks/growls) 21:21, 11 November 2009 (UTC)
  • "You are User:Ed Poor, and I collect my 2 pounds", or however the game goes? I'm getting Strong Deja-vu here. ;-) --Kim Bruning (talk) 15:19, 19 November 2009 (UTC) perhaps it's a glitch in the matrix?

• Oppose with alternative - require articles that have been around more than, say, 30 days to have 3 people agreeing to the deletion instead of just 2. This would allow today's "very easy" prods for new articles that weren't speedy-able but have a higher standard for lightly-watched articles. davidwr/(talk)/(contribs)/(e-mail) 02:05, 18 November 2009 (UTC)
• Comment while I don't follow PRODs it does seem likely that, as I hae observed with CSDs, they do get deleted on the basis that thye are correctly and validly nominated. When I used to do CSD's it was delete, delete, delete.. wait lets examine this one: edit- not speedy, save - the page has been deleted by someone else - sigh, undelete. It may be better now of course. Rich Farmbrough, 21:19, 18 November 2009 (UTC).
• Comment I don't know what the answer is, but the system as it is doesn't always work as it should. I see a lot of AfDs which were contested PRODs, so although it's designed to lighten the AfD workload it has the potential to add to it instead. I think some editors try to use it as a short-cut process for articles which end up at AfD anyway. Sometimes I wonder how many people actually read the bit that says PROD is supposed to be for uncontroversial deletion candidates. It serves its purpose correctly when it's used for articles like How to be a spy, but on the other hand we have candidates like Wendy-O Matik, which probably has the potential for a decent article even though the current version needs a complete rewrite, and The Novocaines, which looks a perfectly acceptable article aside from the lack of citations and perhaps questionable notability of the subject: since the article was only created in October 2009 it's unlikely to have been completely abandoned by its author, and I think this one would have been better dealt with by tagging it appropriately and perhaps later AfD if concerns were not addressed. I would certainly support Trovatore's suggestion of making the courtesy notices on talk pages a requirement, which would lessen the chances of editors overlooking PRODs on a busy watchlist, but I also think that 7 days is a pretty short time period: editors could return from holiday, internet connection problems or real-life demands on their time to find their articles deleted. This isn't a major disaster with PRODs since articles can be reinstated on request, but it's still a bit demoralising especially for newbies who may be unfamiliar with procedures. Contains Mild Peril (talk) 05:33, 25 November 2009 (UTC)
• Concur w/CMD. In large part, the problem is editors who do not do a search on their own per wp:before, prior to prodding. The same problem afflicts AfDs.--Epeefleche (talk) 21:01, 29 November 2009 (UTC)
• Oppose per MrZ. ╟─TreasuryTag►stannator─╢ 21:04, 29 November 2009 (UTC)
• Strong oppose - AfD is already overworked. At times, AfD discussions need to be relisted multiple times because no one added any comments after the first relist. I think that PROD is a good solution - it's easily awatched through WP:PRODSUM, and apparently there are a lot of users who do so. עוד מישהו Od Mishehu 11:50, 6 December 2009 (UTC)
• I regularly check the prod categories for anything that shouldn't be deleted. --NE2 11:58, 6 December 2009 (UTC)
• Keep Prod All our deletion processes have lots of errors, but at least Prod is far less bitey than Speedy. ϢereSpielChequers 19:30, 11 December 2009 (UTC)
• FYI: there's a related discussion here: Wikipedia talk:Articles for deletion#Consolidation
  — V = I * R (talk to Ω) 12:05, 14 December 2009 (UTC)
• Comment I both like prod and find it imperfect. I wonder if an article is prodded and the prod not removed if the article could be taken out of the articlespace, the page blocked from editing, but the talk page kept open? Also, is there any searchable record of deleted prods similar to the AfD archives? Шизомби (talk) 06:53, 20 December 2009 (UTC)
• Comment As long as it's specifically detailed out that deleting admins have the responsibility of making sure that the PROD is actually a valid one, that bulk deletions are against policy, and one can't use an arbitrary "length limit" as a deciding factor, I'm fine with PROD. As for publicity, why not include PROD articles in the AfD List as well? ηoian ‡orever ηew ‡rontiers 03:59, 25 December 2009 (UTC)

Namespace for books

Proposal

See also: Wikipedia:Village pump (proposals)/Archive 45 § Namespace for books

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)

I'll make the bot request. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 13:53, 28 December 2009 (UTC)

WP:BOTREQ#Move Wikipedia-Books to the Book: namespace (diff). Headbomb {^ταλκ_{κοντριβς} – WP Physics} 14:06, 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)

WP:NOTNEWS - Encouraging compliance by redirecting to Wikinews

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 here. As said above, there are tooltips embedded in my proposed changes to these templates; for one, a very long Wikinews title might mess the template formatting, so only pop it up when the user mouses over the link to it. I was reluctant to link to 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:

• User talk:Brian McNeil/Current

  Example:

• User talk:Brian McNeil/Current related

  Example:

• User talk:Brian McNeil/Obituary

  Example:

• User talk:Brian McNeil/Recentism

  Example:

--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)

Listing what links to a page

• 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. ~Amatulić (talk) 00:36, 30 December 2009 (UTC)

Add Jabber XMPP option like IRC

I propose to improve Wikipedia to support also XMPP URIs.

Jabber/XMPP is a open source protocol used by a lot of people all over the world. There are users of Google Talk, Gizmo5, LiveJournal, Nimbuzz, Ovi, Jabber.org and a lot of other servers ... and there are a lot of XMPP clients...

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

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:jdev@conference.jabber.org?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)

WP:COINFLIP

not sure if this is the correct place for this, however here is my idea. bear with me, i know it may sound a bit stupid, but it could work i believe

ok, say for example 2 editors cant agree on something within an article. lets say that they dont agree about which shade of blue should be used as a header for an info box describing different shades of blue. obviously any shade of blue will work right? not so fast. we have all seen edit wars, heated discussions, compassionate arguments, civilized arguments, and simple disagreements on wikipedia right? well instead of being serious all the time, lets take a step back and make it a tad interesting. because sometimes both parties may be correct, and there isnt a concensus on which side should have the upper hand. yes it does happen. how do we resolve it? sure we vote and all, but sometimes a vote isnt available, or it is involving something that cant be voted on, etc. below is from the wikipedia article coin-flipping:

Use in dispute resolution

^{Coin tossing is a simple and unbiased way of settling a dispute or deciding between two or more arbitrary options.} In a game theoretic analysis it provides even odds to both sides involved, requiring little effort and preventing the dispute from escalating into a struggle. It is used widely in sports and other games to decide arbitrary factors such as which side of the field a team will play from, or which side will attack or defend initially. In team sports it is often the captain who makes the call, while the umpire or referee usually oversees such proceedings. A competitive method may be used instead of a toss in some situations, for example in basketball the jump ball is employed, while the faceoff plays a similar role in ice hockey.

im just toying with the idea, but maybe it could work. maybe its a dumb idea. i dunno im just putting it out there. heres some ideas:

1. obviously have a random coin toss generator of some sort.
2. make it so both parties will register for the coin toss, and all revelent information and points of view for both sides will have to be noted somewhere within the WP:COINTOSS protocol. what i mean is both parties involved have to put somewhere why they are flipping the coin to resolve the dispute, their arguments for/against etc.
3. make some sort of disclaimer stating that the cointoss is final. whatever the outcome, the losing party must agree to abide by the toss, and cant change whatever the winner wanted (say in our case light blue won over dark blue). dark blue cant be inserted into the table by the loser of the coin toss. it must stay light blue until someone else changes it, starts to argue etc.
4. make the coin toss case specific. all tosses are available to be viewed by anyone, results fully available etc. basically full disclosure to the community.
5. now im not saying that this is to be used on major things, just small things that the 2 editors are involved in an argument, but seek a civil resolution. obviously if its a flame war, this aint gonna fly.
6. make this a simple easy process. one that wont drag in an administrator or arbitrator to lay down the law and sometimes making a decision that a third grader could have made because it is so trivial. basically make it headache free, a simple quick and easy process.
7. again make this a simple and easy process. and at the same time, make it fun. if you were to lose, oh well. at least its a fair game. a civil end to a minor dispute.
8. also make the cointoss free to anyone to use. maybe you need the cointoss because you and your friend are at the computer arguing on who should go first in playing the xbox, and noone has a coin. crap what do you do? go to wikipedia, they have a coin. <---(lol sounds dumb, but id use it if i didnt have a coin)

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 crapshoot to settle something, when consensus already seems like that sometimes. Also, "the cointoss is final" - most things on Wikipedia aren't final. Temporarily decisive, that's about it. Шизомби (talk) 13:12, 21 December 2009 (UTC)

I don't think this sounds stupid, but I don't think it's practical, for two reasons:

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" MBelgrano (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 Wikipedia:Third opinion to settle disputes between two editors. At least that way, the person offering the third opinion gives the matter some thought, and the decision therefore seems more binding than a coin toss. ~Amatulić (talk) 00:39, 30 December 2009 (UTC)

Proposal to Expand Chinese Wikipedia

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? MBelgrano (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)

Build a wall

A different proposal emerged

We all saw some of the discussions in the talk pages where 2 editors are endlessly arguing against each other, repeating accusations without saying anything new. I propose in these cases that we designate a separate section for each editor "Statement by user A" and "Statement by user B" with a template that instructs the users to focus on making their cases and to write the versions they like to see in the article. Sole Soul (talk) 09:30, 22 December 2009 (UTC) Update: A slightly different proposal emerged, see the template below. The template if approved would be used in addition to direct discussion. Sole Soul (talk) 01:44, 24 December 2009 (UTC) Or we can treat editors like adults... and let them deal with it themselves. We arent here for social control, we're here to make an encyclopedia. If two individuals cant agree on the wording to put in an article, that's sad but they need to work it out themselves somehow. This is more bureaucracy and instruction creep to make decisions and resolve conflicts for us. We are adults, we should learn to work together without others telling us how to do it in a uniform way. Uniformity and conformity is for chumps.Camelbinky (talk) 00:51, 23 December 2009 (UTC) Your objection is a philosophical one I think. I'm interested in which way would maximize the benefits and reduce the negatives. We already have separate sections for each user in ArbCom requests and RFC. I'm not saying that we do this in all cases or to enforce it upon users. Sole Soul (talk) 10:07, 23 December 2009 (UTC) And what happens when a third editor wants to join? MBelgrano (talk) 13:46, 23 December 2009 (UTC) He/She joins. Sole Soul (talk) 15:01, 23 December 2009 (UTC) So after they write their statement, then what? Not being able to directly engage the other person isn't very conducive to coming to a compromise, as they're essentially prevented from working together. Mr.Z-man 16:14, 23 December 2009 (UTC) The statement will be updated (not repeated tens of times) in response to the other user statement. Keep in mind, this approach will only be applied in certain situations were incivility and lack of communication are problem. See for example Talk:Mark Levin. Sole Soul (talk) 17:16, 23 December 2009 (UTC) My point is that its difficult to come to a compromise when you can only communicate indirectly. With a mediator, such an approach could work well, but otherwise any calming effect would likely just because it became more difficult to discuss. Mr.Z-man 19:32, 23 December 2009 (UTC) I agree with you if building consensus is the real goal of the discussion, but sometimes this not the case. My proposal is a way to make building a consensus the goal of the responses instead of a response for a response sake. Sole Soul (talk) 20:11, 23 December 2009 (UTC) I think you're still missing my point. While this may increase the signal-to-noise ratio, preventing people from directly communicating will make it rather difficult to build a consensus. Mr.Z-man 00:26, 24 December 2009 (UTC) Keywords: Certain situations. Sole Soul (talk) 00:59, 24 December 2009 (UTC) I should add: I said below "We can make it in addition to (not instead of) the direct discussion to summarise the stances". Sole Soul (talk) 01:05, 24 December 2009 (UTC) this would be an easy enough template to build - a table or div-based template with a fluid number of columns (one for each participant) to enter their username and a brief statement. I'll start one at {{inbrief}} so that we can try it out in practice and see how it flies. we can always delete it later. --Ludwigs2 20:32, 23 December 2009 (UTC) Thanks. Just a try. Sole Soul (talk) 20:36, 23 December 2009 (UTC) We can make it in addition to (not instead of) the direct discussion to summarise their overall stance Sole Soul (talk) 20:39, 23 December 2009 (UTC) well, there's a completed (if under-documented and fairly ugly) version at the above link, for demonstration and revision purposes. Take a look at it, tell me what more you want to see in it (I'm thinking maybe a box at top for a question statement), and I'll revise it in a bit. --Ludwigs2 22:08, 23 December 2009 (UTC) ok, I've tweaked it a bit - loks like this now:

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

Please describe the pros and cons of this template
Pro position	Con position
this template is useful, because of a lot of stuff that I'm too lazy to type out right now. deal with it.	this template is horribly ugly and really not something I'd want to share with my significant other, because, you know...
Endorsed by: Ludwigs2 23:46, 23 December 2009 (UTC) Sole Soul (talk) 23:53, 23 December 2009 (UTC)	Endorsed by: Ludwigs2 23:46, 23 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 Wikipedia:Articles for deletion/Valhalla Vineyards closes with no consensus (in spite of my view that the 'keep' arguments have been repeatedly shown invalid), I'd be tempted to re-list it using this template to briefly summarize the positions of the opposing sides. ~Amatulić (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)

New goal for 2010

Moved from WP:AN. ╟─TreasuryTag►UK EYES ONLY─╢ 16:26, 23 December 2009 (UTC)

Sadly to say, there is disagreement and arguing in Wikipedia, such discussion about another named user. A cursory look at the complaint suggests that he is not liked and doesn't write articles for the most part.

Would there be any support for the stated Wikipedia goal that all editors should devote a minimum of 33% of edits to articles and edits directly involved in article improvment? That means articles, article talk pages, Wikiproject pages, etc. AN, ANI, AFD, RFA edits would be considered other Wikipedia space type edits.

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. Noodle snacks (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:CSD or 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)

Making the edit toolbar more intuitive

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. Anxietycello (talk) 04:53, 31 December 2009 (UTC)

Let's use these holidays to make a difference

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)

Proposal to end AFD relisting

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)

AFD proposal

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)

Main Page tweaks

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 Template talk:Wikipedialang#Restructuring proposal on Talk:Main Page.

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)

User-specific categories?

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)

Interlanguage links

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. Shimgray | talk | 23:10, 27 December 2009 (UTC)

To add to this - if you install this script, then the most common ones will get translated for you. Shimgray | 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)

Grid computing

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)

Proposed abuse filter changes

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. Chillum ^{(Need help? 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)

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)

Flag related discussion at WP:Footy

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 WP:V and to a lesser extent WP:OR as such I've mocked up an example of a proposed changed. If accepted the change would automatically hide the flag used in {{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)

Ignore watchlisting by inactive users

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 Wikipedia:Targeted Flagging, where this idea germinated).
— V = I * R (talk to Ohms law)

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)

Request TagsComple

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. Paul2387 (talk) 19:06, 30 December 2009 (UTC)

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 Paul2387 (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 User:Davidgothberg's explanation was related to general requests rather than user rights requests. Paul2387 (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)

Make "T:" a shortcut to refer to templates

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)

Proposal regarding AWB's general fixes at Village pump (technical)

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)