Wikipedia:Village pump (proposals)/Archive 82

There is a discussion about revising the language of this template at Template talk:Purge#Edit request: plain language. ~ Ningauble (talk) 19:48, 29 November 2011 (UTC)

• I have proposed that this affect more than just the template, if done. Again, please comment there. --Philosopher ^{Let us reason together.} 04:23, 30 November 2011 (UTC)

Because of WP:DENY purposes, I am proposing that if a user is labeled as an LTA, his/her future socks are moved to a generic category, say Category:Wikipedia long-term abuse and perhaps Category:Wikipedia suspected long-term abuse. This way, the LTAs cannot use their sock categories as trophies, since we will be mixing all the new socks into one category. New socks should be only added to the original categories if they provide an example of greatly changed behavior. If necessary, all socks can be moved out of the original categories and into one or more of these new categories. All one would need to do to identify an unknown sock in the category is to ask the tagger.

I know this will break some templates, but all we need to do is to add "See Also" links on the original category pages to the corresponding generic sock category, or, if the generic sock category is to be removed for WP:DENY purposes, redirect the sock category page to the generic sock page.Jasper Deng (talk) 00:53, 1 December 2011 (UTC)

What's the pride of being caught? ~~Ebe123~~ → report on my contribs. 22:56, 1 December 2011 (UTC)

Some people know that they will be caught and try to get as many socks as possible for bragging rights. The Encyclopedia Dramatica article on Grawp is a good example of one LTA.Jasper Deng (talk) 23:01, 1 December 2011 (UTC)

I'll keep discussion here short, as I would appreciate discussion to take place on the proposal talk page, but due to a few cases in the past (such as Ireland article names, Macedonia 2, Abortion and Senkaku Islands) where there have been issues over article naming, I've come up with a proposal for binding RFCs. The full proposal is at Wikipedia:Binding RFCs, and I would appreciate comments on the idea. Thanks, Steven Zhang ^{Join the DR army!} 01:07, 2 December 2011 (UTC)

Nobody answers to this crucial proposal for several weeks. Please read this very politely detailed written suggestion and give any opinions. Current Events is of course currently useful, but also really needed to be repaired. Which category do you think the information "Saboteurs blow up Egypt's gas pipeline to Israel and Jordan with the explosion occurring west of al-Arish in Sinai." belongs to? "Armed conflict and attacks," "Politics and elections" or "Disasters"? All of them! If there is a wrong (or inadequate) custom, we need to change it, or at least discuss about it. Somebody break the silence. LyJPedia (talk) 07:13, 28 November 2011 (UTC)

Just letting you know out of courtesy that I have looked at the two differing ways the page in question is displayed (yours and the standard) and honestly am not close enough to the project to be able to offer anything like a qualified opinion. That said, although linking and categorization are good, they can be a little over powering if almost everything is blue. Black section titles have an air of quality that linked section titles just don't (in my unqualified opinion). fredgandt 18:45, 28 November 2011 (UTC)

Thank you so much for giving an opinion out of courtesy even though it's an opposite view. This issue's gonna to have to be discussed someday. LyJPedia (talk) 08:42, 29 November 2011 (UTC)

This idea is basically to group entries according to nation rather than by subject.

It has the same classification problem: What single country would you list global financial news under? How about "All of them!"? For that matter, which country do you think the information "Saboteurs blow up Egypt's gas pipeline to Israel and Jordan with the explosion occurring west of al-Arish in Sinai." belongs to? How about Egypt and Israel and Jordan? And under what country would you list events happening in the ocean, in space, or that are purely international, like decisions of UN agencies?

But fundamentally, I dislike it because it promotes a regional/local point of view: It suggests that readers should only care about what happens to their own country. I shouldn't care about science; I should only care about <name of country>.

Also, the talk page comments are accurate: there are too few items on the page to bother with this sort of regionalism. The other day, we had three items under "Law and crime", but your examples basically had a single event per country. WhatamIdoing (talk) 23:51, 2 December 2011 (UTC)

I think you asked me, so I answer to you anyway.

1. Not "All of them". That could belong to "Worldwide" section, which could be at the top of the alphabetical-ordered names list .

2. That doesn't belong to "Israel" and "Jordan" because it's about Egypt's gas pipeline and explosion in Egypt. But even if it's not, you can put such an international information into each continent's "Continentwide" section.

3. So, this suggestion is absolutely not about "regionalism," just like I can't devalue the current custom as "subjectivism." Though I personally prefer regionalism rather than globalism without substance.

I currently kinda withdrew this proposal, because I agreed that it's not appropriate yet for the current condition of this page. But I'm sure this type of change will help its growth someday. LyJPedia (talk) 11:50, 4 December 2011 (UTC)

It is a brave suggestion, but we have enough problems agreeing on what is a "country" without attaching news headlines to them. This is a solution to a problem nobody's posed doktorb _words^deeds 12:15, 4 December 2011 (UTC)

I've proposed changing the orphan article notice to a hidden category. Please comment there if you have an opinion on this. Thanks! Kaldari (talk) 03:21, 5 December 2011 (UTC)

I made a proposal yesterday evening at Template talk:Cquote#Proposal to track improper usage. My proposal was the first edit in over 2 weeks, however, so I'm bringing it here instead. The basic reasoning is as follows:

• {{cquote}} is reserved for pull quotes. This is stated at MOS:QUOTE and on the template's documentation.
• But it's widely used for generic block quotations, which contradicts the MOS.
• There was consensus at TfD to correct the usage of the template, or change the MOS, rather than deleting it.
• I've made a cursory search of the WT:MOS archives, but found no recent evidence of consensus to scrap that rule.
• The template supports attribution parameters, like author. Since it's supposed to be used for pull quotes, which shouldn't need attribution, the template itself encourages misuse.
• However, removing the parameters now, while the template is widely misused, would break a lot of articles' attribution, which is even worse.
• Therefore, I propose that this template categorize any uses of those parameters into a new tracking category: Category:Articles with attributed pull quotes.

Once we've emptied that tracking category, we may want to scrap the attribution parameters. We should probably also tie this into WP:MAINT at some point. --NYKevin @746, i.e. 16:54, 19 November 2011 (UTC)

I guess. In my opinion, {{cquote}} is pretty, and the general block quote templates are ugly, and something like cquote should be used for quotes generally. So I personally can't get too exercised about editors voting with their feet in this way. A better solution might be to change the MOS and the cquote documentation to encourage more general use of the template. Herostratus (talk) 20:32, 19 November 2011 (UTC)

It's been almost two months since the TfD in question and so far as I can tell, no one cares enough to build a consensus to change MOS. If you want to preserve this usage, I'd recommend starting an RFC over there soonish. Obviously I would put this proposal on hold if such discussion materialized. --NYKevin @961, i.e. 22:04, 19 November 2011 (UTC)

• Support Cquote is being used as a decorative quote and is not appropriate for the encyclopedia. I have yet to find any article where it is actually being used as a pull quote. ---— Gadget850 (Ed) ^talk 01:03, 20 November 2011 (UTC)

• See Kamie Ethridge. My goal isn't to undermine your point, but support it. I like the looks, but accept the community consensus that they should be reserved for pull quotes. I've seen it used improperly many times, and proper use is very rare.--SPhilbrickT 16:48, 21 November 2011 (UTC)

• Although I agree its intrusiveness is undesirable in articles, it sees much legitimate use outside the article namespace (here for instance), where such decoration is entirely benign. I'm not sure removing the parameters altogether is a constructive development. Happy‑melon 00:02, 21 November 2011 (UTC)
  • OK, perhaps we could disable them in article space only. Of course, they will continue to work until we've emptied this tracking category -- I don't want to break large numbers of articles. --NYKevin @705, i.e. 15:54, 21 November 2011 (UTC)
    • I will discuss namespace detection on the template talk. ---— Gadget850 (Ed) ^talk 16:27, 21 November 2011 (UTC)
• Diff: [1]. Note that this is between two different pages. The main template has not been edited. Moreover, it appears that I'm proposing the removal of the {{doc}} and noincludes, but I'm not. --NYKevin @751, i.e. 17:00, 21 November 2011 (UTC)
• Per WP:SILENCE and Gadget850's support, I've added a {{sudo}} to the template talk page. --NYKevin @825, i.e. 18:48, 27 November 2011 (UTC)
• Oppose. Let the editors handle this. The automatet tracking will generate inadequate amount of interruptive editing and disputes, both unrelated to the cquote usage, as many new editors will come to the articles that are out of their scope of interest. — Dmitrij D. Czarkoff (talk) 19:30, 28 November 2011 (UTC)
  • The category has been created and populated. It currently has over 2,300 members. Do you really think that local editors, who are often unaware of the rule, can handle this on such a large scale? And getting people who are familiar with the MOS to edit the articles is precisely the point: they can and will improve the article, at least by fixing the {{cquote}} uses, and possibly by bringing the article as a whole into better MOS compliance. Are you suggesting that increasing the number of eyes on an article is a bad thing? --NYKevin @090, i.e. 01:08, 1 December 2011 (UTC)

Before doing all this, let's have an RfC on the question in general, see Wikipedia talk:Manual of Style#Quotes, pull quotes, blockqute templates, and cquote templates. Herostratus (talk) 16:04, 5 December 2011 (UTC)

I have always been primarily a reader of wikipedia, though I do help out when I see something I feel I can do.

Over the years, I have noticed that a number of articles have gotten really, really good and then have begun to decay. A committed group works on an article, brings it to a decent status, and then moves on. Meanwhile, less experienced or knowledgeable editors wander across the page and slow start filling it with unverified information or even start changing previously excellent sections. Then maybe someone else recognizes that the section has become full of inconsistencies and decides to just remove the entire paragraph. Thus, what was once an accurate well-written piece entirely disappears, not all at once but slowly through multiple edits. While this can technically be dealt with using present policy, it requires a large amount of dedication and there is nothing like fixing the same problems over and over again to incite fatigue.

What if there was a list of criteria by which certain articles could be considered "finished" or "closed?" What I am basically talking about is long-term protection, but for the sake of maintaining quality. I don't mean they could never be re-opened, but that there would have to be a consensus that it was time to re-open. This seems like more work, to go around judging articles and getting consensus, but I think for certain articles it would actually be less work than continually re-improving once good articles. Exactly what level of protection would have to be worked out, but I know I am basically at the point where I am very reluctant to do any improvements at all because I know that no matter how much I work on an article, that work could be gone in 6 months. Wikipedia is good at reverting obvious vandals, but less good about maintaining quality on less-watched articles where hard work is not washed away in a single prank but rather through a slow process of less than careful edits when no one is looking. Wickedjacob (talk) 13:06, 15 November 2011 (UTC)

Don't think much of that but it might be possible to make the 'article milestones' on talk pages more prominent and do more with them like list the last one on the article page. Dmcq (talk) 13:15, 15 November 2011 (UTC)

• I'm very much in favour of a mechanism whereby articles could be closed to public editing once they reach a certain point in their evolution. I know it's a bit heretical, but you're not the first person to tell me that they're reluctant to contribute to Wikipedia for this reason. Selecting articles for this type of protection would be a far more useful activity than (or could be combined with) the selection of "good" or even "featured" articles.--Kotniski (talk) 14:34, 15 November 2011 (UTC)

Well, while you have a point, one of the main functions of WP is that articles are considered NEVER complete. While it's true that for some articles it's rare that anything substantially new to the world content could be added, even FAs almost always have little things here and there that can easily be tidied, sources that no one happened to use with good unique info, and so forth. Closing editing to our best articles would be just as bad as closing articles to the really bad ones. Not everyone knows how to easily make an edit request, and for little things are unlikely to bother. What needs to be done, I think, is a much more push toward "if you think you're helping please do it" so the reluctance will be gone. Yes it's possible some will degenerate, but I'm sure the net value of articles as a whole only goes up, and would ever more if less people were "reluctant". Plus, if those who brought the article up to quality "move on" from it....well then they didn't care about their work so much to see it maintained. ♫ Melodia Chaconne ♫ (talk) 14:46, 15 November 2011 (UTC)

I don't quite understand what message you want to send to "reluctant" editors to make them more willing. (The message we send at the moment is "Your contributions are valuable, but not so valuable that we're prepared to do anything to protect them, so if you want them to be of continued value, we'll need you to log on to Wikipedia twice a day for the rest of your life to fight with vandals and idiots." Something like that, anyway.) --Kotniski (talk) 15:01, 15 November 2011 (UTC)

(edit conflict)In response to the moving on point you make; I don't think it's so much that they don't care about their work, as much as there's just so much to look after. For anyone who has created hundreds of articles (I say this as a guess - I've only created two or three), looking after those articles could easily become their only on-wiki activity. For editors who help out by copyediting articles on request, or collaborating on a certain subject, there really isn't any way to maintain those articles all the time, without using all their time. Nolelover ^{Talk·Contribs} 15:08, 15 November 2011 (UTC)

(edit conflict)Yes this is arguably a good idea. It's probably a perennial proposal and isn't likely to gain main traction at this time. I recall back in 2005 seeing a chart showing the lifespan of an article: a rapid rise in quality at first, after which the article kind of just bumped up and down a little as people added stuff, took stuff out, futzed with wording, people adding unref'd or trivial or POV material and other people deleting it, etc.

There are, basically, two paradigms for moving forward. One is to continue steady as she goes. The other is consider changing the nature of the Wikipedia to take into account various changes in the nature of the Wikipedia, such as all the really important stuff having already been written about, declining numbers of contributors, and so forth.

The Foundation is committed to steady as she goes. Their thrust is entirely oriented toward maximizing the number of active editors and reversing any decline, using various outreach and editor-retention strategies. I'm skeptical whether this is possible or even necessarily desirable, although I could be dead wrong about that. But as long as this is the operative strategy, then locking down articles is not likely to fly. Herostratus (talk) 15:09, 15 November 2011 (UTC)

I don't see why not - I see it very much as an editor-retention strategy ("if your work goes towards making something really good, we'll protect it for you" - makes editing Wikipedia seem just that little bit more worthwhile). --Kotniski (talk) 15:53, 15 November 2011 (UTC)

You make a good point. I would consider supporting this, although it's probably quixotic at this time. Herostratus (talk) 17:41, 15 November 2011 (UTC)

Take a look at a 1911 encyclopedia article. Those were "locked" onto paper and were good at the time. But even if the facts haven't changed, styles and tone do. Quick sample: "After the death of Shelley, for whom she had a deep and even enthusiastic affection, marred at times by defects of temper; Mrs Shelley in the autumn of 1823 returned to London. At first the earnings of her pen were her only sustenance; but after a while Sir Timothy Shelley made her an allowance, which would have been withdrawn if she had persisted in a project of writing a full biography of her husband. In 1838 she edited Shelley's works, supplying the notes that throw such invaluable light on the subject. She succeeded, by strenuous exertions, in maintaining her son Percy at Harrow and Cambridge; and she shared in the improvement of his fortune when in 1840 his grandfather acknowledged his responsibilities and in 1844 he succeeded to the baronetcy." Rmhermen (talk) 16:05, 15 November 2011 (UTC)

WP just celebrated its tenth birthday. In that span, have grammatical styles really changed that much? Yes, in 100 years, a lot can happen, but this is a solution for a short term (in the sense that WP may very well not even be around in 2111) problem. Plus, Jaga's idea below would help to solve your objection. Nolelover ^{Talk·Contribs} 17:32, 15 November 2011 (UTC)

The FA process in March 2002: But if you come across a particularly impressive page, why not add it to the list as your way of saying "Thanks, good job"? Things have indeed changed... --Stephan Schulz (talk) 17:54, 15 November 2011 (UTC)

Right, "locked for 100 years" would be an OK compromise, I think... Herostratus (talk) 17:41, 15 November 2011 (UTC)

Instead of closing an article altogether, we could create a new level of page protection between semi and full. To edit, you would have to have a user right ("experienced user"? whatever) that is automatically conferred upon your 1000th edit but can also be granted or taken away. Then, when an article becomes featured, or just plain complete, it can be protected at this new level. It would slow decay, but not keep dedicated editors out. --JaGa^talk 16:48, 15 November 2011 (UTC)

Yes, that's how I imagine this working. Something a bit similar to these flagged revisions we seemed to be trying out some time ago, but packaged in a more positive and less confusing way.--Kotniski (talk) 17:47, 15 November 2011 (UTC)

Or we could just have pending changes... (This user cowers in fear as the brickbats start being thrown.) —Tom Morris (talk) 14:19, 25 November 2011 (UTC)

• Fully Support There is nothing more disheartening than watching a good article turn bad. All articles are open honey jars, attracting flies. There are some articles which are as complete as they'll ever be, so why not say "Well done everyone, this is complete". Heck, create a new project to nominate complete articles if needs be. Let's not pretend that Wiki is perfect - there's enough work to be done. BUT for those articles where no work can possibly build on what's gone before, why not bring up the drawbridge? doktorb _words^deeds 17:08, 15 November 2011 (UTC)
• No. If an article is good, and you want to keep it that way, no one is stopping you. But even featured articles can be improved, and we should never imply that even on our "best" articles that the work is done. It is never done, new information becomes availible, better pictures can be added, language can be made even better, etc. etc. No, this is a phenomenally bad idea. If you don't want to see decent articles degrade, stop it. But don't let "good enough" get in the way of "better". There is no good enough at Wikipedia. --Jayron32 18:34, 15 November 2011 (UTC)
  • Yeah, in theory. In practice, I'm not so sure. I think that nobody is saying completed articles can't be changed by anyone ever. The question is, should the same editing paradigm -- "anyone can edit it in any way" -- apply to stubs, mediocre articles that need work, and really good featured-article-quality articles? It does now. Should it? Why? It seems kind of like a one-size-fits-all approach that may no longer be optimal. Herostratus (talk) 18:43, 15 November 2011 (UTC)

This looks like a proposal that has come at the right time. All longtime contributors have had to deal with attempts that slowly downgrade the quality of a finished article. There is already a method available to stop most of these attempts: permanent semi-protection. This can be done by changing the policy of Wikipedia:Protection policy Each WikiProject can then designate which articles deserve this semi-protection and an admin can perform this task. This wouldn't exclude all vandalism or botched attempts at “improving” an article, but would certainly be a great help. JoJan (talk) 20:01, 15 November 2011 (UTC)

Support restricting (not closing). Is there be a way of spotting articles were the main contributing author is no longer active? (As these pages would be prime victims of non-patrolled vandalisms and good faith erroneous edits) --Squidonius (talk) 20:26, 15 November 2011 (UTC)

No. That's what the watchlist is for - you can throw an article on it and forget it, yet be alerted when it is changed so you can take a look at whether the changes were good and/or whether they can be improved. --Philosopher ^{Let us reason together.} 02:16, 16 November 2011 (UTC)

Personally, I don't know if this really works with massive amounts of articles on a watchlist (perhaps someone with, say, more then 1k can comment on how easy it is to follow every change), but even if I'm totally wrong, what's to say the watchlist is the "only" way we fix these articles. I mean, the "watchlist everything" method obviously isn't working now'... Nolelover ^{Talk·Contribs} 13:33, 16 November 2011 (UTC)

I have 3,982 pages on my watchlist, excluding talk pages, primarily split between deleted articles that I watch for re-creation, and active articles that I'm not really involved in but still want to keep an eye on. It works. --Philosopher ^{Let us reason together.} 08:42, 17 November 2011 (UTC)

And I had less then 300 at its max. Call me incompetent if you wish (no, I won't take offense :), but it was too much. Nolelover ^{Talk·Contribs} 13:10, 17 November 2011 (UTC)

I am the 5000th and something most active editor ever in en:WP (w/ ~9k edits), and I also can not keep up with 300 watchlisted pages. u:Philosopher, you are either lying (to us or to yourself) or you are super-human, and as such not a reasonable reference for the rest of us. - Nabla (talk) 20:15, 20 November 2011 (UTC)

Of course it depends on what one watches. I have 527 on mine, including all the village pumps and 35 have been changed in the past day. I can easily imagine watching 5000 pages that get almost no edits, especially if one considers archives and other pages that aren't supposed to be edited. Considering Philosopher said many of them are "to watch for re-creation" (i.e. they don't even exist) that right there is a large number of pages that won't get edited. ♫ Melodia Chaconne ♫ (talk) 20:54, 20 November 2011 (UTC)

However, if you have a bunch of redlinks on your watchlist that you're just watching for recreation, then that doesn't help this problem at all. The "watchlist method" only works if actual articles (not WP: pages, not userspace) are on people's watchlist and are actively being checked. I just cleaned my WL of a bunch of articles that, even when they would pop up, I didn't really check. All this to say that there are a lot of problems with believing that people watching articles alone will solve this problem. Nolelover ^{Talk·Contribs} 21:18, 20 November 2011 (UTC)

• Comment: At one time, a similar idea did exist on Wikipedia. It was Wikipedia:Stable versions, but it's been inactive for some time. It might be a better idea to invest your time in reviving this project, or one like it. elektrikSHOOS (talk) 17:45, 16 November 2011 (UTC)

Comment. Regarding the Watchlist, I'd like to say my tuppence's worth, I find it quite flawed:

• as mentioned by Nolelover if you have too many it become unwieldy,
• when expert editors become non-active their pet in-depth esoteric pages loose their watchmen (I have gone on "wikipedia vacation" for a while due to work stress only to "come back" to derelicted pages)
• successive edits are not visible in the watchlist, only the last (I have seen vandalisms becoming fixed due to reverts of the last edit not all edits)

The watchlist does help, but does not solve the problem in my opinion. --Squidonius (talk) 20:35, 16 November 2011 (UTC)

Support restricting . Going by other multi-volume encyclopedias (like the old print editions of E. Britannica) I should think about 100,000 articles cover most of the essential areas of science, philosophy, deceased historical biographies of high notability etc. Most of these articles, should be ready for semi-protection right now as they are likely to be closely watched. This would be a start -and from the experience gained in completing this effort, a firm policy can be hammered out. That leaves a huge number of many times that figure that beginners can still wreak. There are good psychological reason too. It will not only help to stem the loss of good editors with knowledgeable and in-depth expertise but should encourage new editors to work on expanding stubs and learn wiki-code and WP policies without having edits immediately reverted. It seems that new editors are drawn to the well written and nearly complete article for the very reason they are good and are commonly read. This leaves an inexperienced editor very little room to make meaning full contributions. If they start on stubs, it will lead them to explore for templates and all the other bells and whistles we have – using the good articles as example of what can be achieved. By now, I don't think there is a schoolchild that hasn't heard from numerous friends and other sources, that to become a new editor it is an up-hill struggle in battle against the entrench Mafia of experienced editors already here. What we say on these discussion pages and within WP about welcoming and helping new editors just doesn’t reach them any more. It bonkers to carry on as we are. This is a historical practice that may once had a point -rather than a useful one. --Aspro (talk) 15:32, 17 November 2011 (UTC)

It is proposed herein to restrict editing of "mature" articles to stop them "rotting". We all agree that article get a burst of improvements get to an excellent level, but go down hill afterwards. However, several question remain open, in my mind at least:

• When is an article mature? E.g. Is it when it gets to FA status or according to other criteria?
• Who can edit the "restricted" articles? Protection stops IP users. Or are talking about something more stringent, although defining who is an expert is quite problematic, are they self-appointed (i.e. mavens) or are they nominated?
• Who gets to "restrict" articles (admins?) and what process do other editors undertake to request it?

.--Squidonius (talk) 22:57, 17 November 2011 (UTC)

Comment: Good question; Who can edit the "restricted" articles? . A sub page showing the 'new edition' can be edited 'freely' and viewed openly and all can vote for the original to be replaced. The history of the original article will show all competent editors -they can ask for privileged voting rights. --Aspro (talk) 23:13, 17 November 2011 (UTC)

This recent discussion about preemptively protecting pages against vandalism has some content related to this thread. I suggested then that an automated guard could be employed to close articles that (measured by edit frequency) were under possible attack. For this proposal, similar methods could be applied. I also suggested that safe versions could be cached and presented to the public during times of page closure (just in case the closed page was in a damaged state) and that the safe version could be established by admins (just a suggestion that could be expanded to include community review etc). An extension of that idea could be to have drafts: a primary, agreed and established draft with edits to it stored for review rather than immediately applied. Another wiki I worked on uses (or used (can't find an example page)) a draft system on some more official pages (that contain legal statements or policies etc) that presents an agreed correct page. While the page can be freely edited, only the reviewed and accepted changes are applied to the final draft. I agree that levels of protection could be employed across the board here in any number of ways and believe the benefits out-way the costs. I almost waffled. fg 23:41, 17 November 2011 (UTC)

Strongest possible support Wikipedia needs to do something to retain its long term contributors. Having the quality of an article you worked on a lot degraded by mindless edits I believe is one of the things that drives long-term contributors away from this project. Wikipedias efforts to get more and more new editors involved into editing isn't the thing that will keep the project working, but measures to create an enjoyable environment for long-term contributors is. Please, please, please implement this. This will help to get people do more content writing and will reduce the amount of necessary gnoming on those articles. Toshio Yamaguchi (talk) 09:47, 2 December 2011 (UTC)

No article is ever "finished" of "perfect". I can see the value of some form of protection against quality rot by casual editors, vandals etc, but there must always be some way of allowing access by those of us who can and wish to improve an article. Perhaps a good quality article can be stored as a closed page for general access, so that people looking for information see a good quality product, but an alternative version will be open for improvement, with an icon in the header giving the option to the new edition under consrtruction? This way, if the page gets better, it can be subsituted after a review and the process started again. If it rots, it can be periodically reverted, and all the time the reading public sees the protected version first. This procedure may even discourage vandalism and edit warring if it is applied to cases where these are a problem. Since all versions are saved anyway, this shouldnt increase overheads. Decision to apply the process could just be a couple of requests to an admin, as the development version is still universally editable.

This form of protection could be automatically applied to all featured articles, and possibly to all good articles. Further down the line it is an option for problem and contentious articles, which could be given this protection after reaching a consensus, to tide them over while the squabbling continues on the development page.

The tool bar would be missing the "edit" button on the protected page. Instead a button would lead to "development version", where the edit button would be in its normal place. Some form of tab or icon indicating the status of the protected page would be clearly shown at the top of the page. I dont know what this should be called. Something like "Stabilised version N: This page can not be directly edited. Make changes to the development version". where N is the version number of the stabilised article. This way an interested reader can compare stabilised versions easily by referring to the edit summaries where they would be recorded. Peter (Southwood) ^(talk): 07:07, 18 November 2011 (UTC)

You realize that what you have proposed is also called pending changes? Nolelover ^{Talk·Contribs} 13:54, 18 November 2011 (UTC)

I did not, thank you for the information. Peter (Southwood) ^(talk): 06:22, 22 November 2011 (UTC)

It seems that two questions are which articles get protected and who can edit these protected articles. For the which, an easy start could be "all Featured and Good articles, automatically, and no others" for now. (This could possibly be broadened later, not sure how though). Who is a harder question. Right now we have (not counting Developers) four classes of editors:

• Anon IPs
• Non-autoconfirmed editors. Editors are autoconfirmed after four days and ten edits.
• Everyone else (except admins)
• Admins

Anon IPs cannot do many things (such as create pages I think) and non-autoconfirmed editors have a few restrictions (can't upload files or move articles). But after autoconfirmation one has the same rights at the most veteran editor, so the "everyone else" category includes editors from four-days-and-ten-edits to ten-years-and-100,000-edits (and on up). This is quite a broad range. Too broad? Maybe.

Suppose this was refined with a new category, I'll call it "established" but the name doesn't matter. So then we have:

• Anon IPs
• Non-autoconfirmed editors. Editors are autoconfirmed after four days and ten edits.
• Non-established editors. Editors are established after X months and Y edits.
• Everyone else (except admins)
• Admins

Only established editors can edit Featured and Good articles (they can also request permission on the talk page for a specific edit such is down now for fully protected articles, or just informally suggest a change.) I don't know what the values for X and Y should be, this is a detail. (1 month and 100 edits, 3 months and 300 edits, 6 months and 600 edits, whatever.) Obviously this would require a software change and also would not entirely solve the problem.

The problem is, this would be a huge change culturally. It would require a software change and that's a big deal to get pushed through. With the reluctant exception of restrictions on anon IPs and non-autoconfirmed editors, which is mostly to restrict drive-by vandalism, we've always treated all editors as equal (admins have no special standing as regards content.) This makes little sense to me and most organizations don't do that I don't think, but it is what it is.

Any proposal to be simple and automatic, so you have objections like: non-established editor who is Professor Emeritus of Asian History at Columbia can't edit the article, established editor who is nonetheless a complete idiot can. The refutation of that is while specific individual-case objections can be raised against most anything, from a system-dynamics standpoint it'd be an improvement, but a lot of people won't buy that.

So I'm not seeing a way forward on this, beyond just continuing to talk it up and hope for a sea change. Herostratus (talk) 15:52, 18 November 2011 (UTC)

Unfortunately, I have to agree. While there is definitely a problem, there's no way in Hades that any sort of Pending changes-esque solution will be accepted in the near future, and the prospects of another "class" of editors probably aren't much better. Big, sweeping "cultural changes" aren't generally the easiest things to pass on WP. Nolelover ^{Talk·Contribs} 16:38, 18 November 2011 (UTC)

non-established editor who is Professor Emeritus of Asian History at Columbia can't edit the article,

Some of the above suggestions 'will' allow new editors to edit. However, this time they will be improving the 'new' edition of the article (on a sub-page) which will replace the old one. To make sense of the above suggestions, what we need is a table showing how this proposal is structured. A commonly agreed glossary of terms I think is needed as well- as this is geting like the tower of babel. For instance: Stable page or current edition or current impression, Sub-page or pending changes or second edition proof or something etc.

As I see it we can:

• Freeze the current page of a featured article.
• The normal edit tab is replaced with a 'edit next edition' tab.
• The 'next edition' tab takes any editor to a sub page where the original 'copy' of the article can be improved.
• Any editor on the talk page can then ask at any time for a vote on whether the new edition can/ is ready/should replace the old version.
• An admin says yea or neigh.
  

What is the problem wit that?!!

New editors may even get better advice and guidance from experienced editors this way, since they are no longer messing up the 'live' articles and frustrating those competent editors have taken much time and effort to get right.--Aspro (talk) 17:56, 18 November 2011 (UTC)

• I think this is the Mediawiki extension that would provide the ability to have stable (protected) and editable (unprotected) versions of each article, for different levels of user. I gather from the page's hat that Wikimedia are almost certainly not going to be implementing anything like it here within our lifetimes. I'm afraid we may just have to stick with page watching and vigilante-ism! If the Tool apprenticeship goes through we'll be swamped with eager young gun slingers too. Yee-haw! fg 18:10, 18 November 2011 (UTC)

I've decided that I flat out oppose this idea (sry). I have to side with Jimbo on this. There are currently 6,910,843 articles and they were created by all and sundry. Viewed in detail the content is in perpetual flux but, viewed from a perspective most readers have, this is an incredibly stable and full encyclopaedia. The ethos has proven itself. The proof in this pudding has been tasted. We are looking after it now.

I'm a programmer. I like and believe in code. I would have a T-shirt of ClueBot if I were a T-shirt person. If an automated way could be found to more rapidly guard pages, I'm all in favour. Machines are totally unbiased and ruthless. No sweet talking will sway them and they cannot have bad days (unless badly written). People are fallible and make mistakes and act in bad faith or in good faith but poorly. However, en-mass humans do manage to display The Wisdom of Crowds. That's how this remarkable project started and how it should continue. We each do our little part and natural equilibrium will continue. The OP (original proposal) was to find a way to save rotting articles. If those articles are worth anything to anyone, they will be turned around in time and rise again to good or better status. The idea to find, save and protect the gold-that-was is so very tempting, I was almost suckered in. But no; we must trust in the incredible system that got Wikipedia this far. Free editing for all, all the time (unless common sense dictates otherwise). Knowledge is constantly shifting and one can only assume it always will. We (Wikipedia) must adapt. If adaptation results in article occasionally falling by the wayside (think genetics) then so be it. Nearly 4million! We should have a party!! fg 18:41, 18 November 2011 (UTC)

Your missing the point! All articles can still be edited. Its just that the frozen page is frozen. A tab is still there to edit the page which will replace it. It is just a temporal displacement. WP will still be an encyclopedia that anyone can edit.--Aspro (talk) 18:24, 18 November 2011 (UTC)

Fred Gandt rightfully points out that this whole discussion is against rotting articles — a problem acknowledged by all in this discussion.

There are legions of editors, some are waxing and some are waning. Under the assumption that all editors have the same knowledge, wikipedia pages will continually get better eventually with some occasional periods of "article rot" as the decreasingly-active experts are substituted by increasingly-active experts. The problem is many editors are the sole experts of a set esoteric topics: editors have "pet articles" and often they and they alone are the only users that knows about the topic well enough to edit it. Consequently some (but not all) articles that rot tend to go down hill until they are noticed again, but without the expertise are deleted, merged or severely reduced. I am however not sure of what proportion of articles go down hill and never come back. --Squidonius (talk) 21:44, 18 November 2011 (UTC)

PS. Trying to find examples, I keep thinking of several cases where a interesting piece of information disappeared due to vandalisms being removed but not reverted and due to the last edits of a series of deleterious edits being reverted. These two are issues with the watchlist. So I am not too sure about my own stated theory above... --Squidonius (talk) 21:49, 18 November 2011 (UTC)

Correct me if I'm wrong (really) but articles would only disappear (by deletion) if they had gotten too small to be considered worth keeping, right? Assuming this is correct: A possible software solution could be to watch pages for significant shrinkage. If an article reaches an alarming stubbyness it is immediately added to a category for adoption. Volunteers could then pick them up, find out why they have shrunk from perfectly reasonable to not even a stub, and take it from there. This way would at least prevent forgotten articles fading away through lack of active guardianship. fg 21:59, 18 November 2011 (UTC)

Evolution by open editing is a noble goal, but we risk losing our dinosaurs. Not in this case with a bang, but with a whimper. Peter (Southwood) ^(talk): 06:22, 22 November 2011 (UTC)

• {{Stable version}} is a way of marking milestones, see Talk:Risk_aversion for how it works. It might need to more slick to be really useful. Rich Farmbrough, 17:32, 25 November 2011 (UTC).
  

I would automatically apply full protection to FAs, so that all the edits go through prior consensus process. The protection automatically expires when the article is demoted. — Dmitrij D. Czarkoff (talk) 08:52, 30 November 2011 (UTC)

I strongly support restricting articles once they reach good or featured status (or maybe even 'B' status). Wikipedia is a project, and a project needs stability. If there are sweeping events that render the article outdated the article could be reopened for everybody, and of course make sure that if there is a large dispute over neutrality, accuracy, information that should or should not be there, etc there's not too much of a bureaucracy to unprotect it if there is general consensus to do so. In short, protect the articles, but not excessively. Falconus^{p t c} 12:27, 5 December 2011 (UTC)

I love the stable version template that Rich Farmbrough has created. I think it would be a good, light-touch way to solve most of the problems identified here.

As a further improvement, perhaps we can combine it with the article milestones template and so give something like:

Yaris678 (talk) 13:38, 5 December 2011 (UTC)

Yes, the Stable Version looks promising, kudos to Rich. I wonder if it'll get deleted, though? One thing that Rich (or anyone) might want to consider is opening an advisory and well-advertised WP:TFD on it. If it fails, so be it. If it passes, it's then more-or-less (somewhat) protected going forward, and the TFD discussion would be good advertising (and might generate useful suggestions for tweaks). Rich, waddya think?

A support structure for this could be, maybe, a Wikiproject Stable Versions, designed to see that that the template's properly applied and, particularly, keep on eye on tagged Stable articles with a mind to looking at changes with a gimlet eye. I'm not willing to lead such a project but I'd be willing to pitch in some if someone else wanted to start it up. Herostratus (talk) 14:35, 5 December 2011 (UTC)

TFD is mostly for merging and deleting. I'm not familiar with that corner of WP, but I'd have thought opening a dedicated stream on the village pump would be more sensible. Alternatively, people could just start using it... and see how the whole thing develops organically. I think a WikiProject might be an idea at some stage... but under the organic model, we'd just set one up if it becomes necessary to coordinate things... if the use of the template really takes off. Yaris678 (talk) 15:29, 5 December 2011 (UTC)

Would it be possible to place it on the actual article? Unless I have a reason, I personally don't generally go to the talk page of an article; if the template is only ever placed on the discussion page, I doubt that it will serve much good, or that the general users will know that they exist. Falconus^{p t c} 19:55, 5 December 2011 (UTC)

Update: I added the template to the talk page of today's featured article, and am about to look into adding it to tomrrow's. Let's see what reception it gets. Falconus^{p t c} 20:16, 5 December 2011 (UTC)

I like the idea of keeping it on the talk page. It means that people who are interested can use it... but by making it less part of the "public face" of the article it becomes less of a hot-button topic. Yaris678 (talk) 11:56, 6 December 2011 (UTC)

Good thinking - sticking it on talk page of today's featured article. This is what I mean by organic development.

A thought on use on TFA: Obviously people are fairly quick to spot the worst vandalism on TFA. Also, I am sure that for most articles, after it is TFA, people have a more thorough look at the net change during the TFA period. The template obviously makes this easier. However, I think the most important use of the template may well be after this time. If the "thorough lookers", once they are happy with the changes made, update the template with the new ID, that means that in future, when there is less attention being paid to the article, it is still possible to find a reasonably up-to-date, stable version of the article to compare to.

Yaris678 (talk) 13:35, 6 December 2011 (UTC)

Update: I've applied the template to the talk page of a page that suffers from spam. Yaris678 (talk) 15:30, 6 December 2011 (UTC)

It seems to me that this functionality could be merged into Template:ArticleHistory, which is already existing and used on a good number of pages (especially ones which have moved through the major assessment grades).

Hrp drp, I see Rich suggested (nearly) exactly that. However, the one thing I would question is the edit frequency of these templates due to keeping track of the most stable version... --Izno (talk) 16:03, 6 December 2011 (UTC)

I thought it was me that suggested that (although perhaps I could have been clearer, and maybe I have missed something Rich wrote).

In terms of edit frequency to the template: (1) I don't think it is essential to have the absolute-latest stable version recorded. This template just gives us an option to record a stable version of the article if we find one. (2) If keeping track of edits to the template becomes an issue, we could place it on a subpage and transclude it into the talk page. That way the edits to the template instance are recorded separately to comments on the talk page.

Yaris678 (talk) 16:15, 6 December 2011 (UTC)

Hey all, I would like to ask what do you think about idea of implementing new flag "tool" to mediawiki, it would act same as bot flag apart of that it would be allowed for most of users (probably confirmed users), it could be enabled when editing with special parameter so that all edits using AWB, Twinkle and various user scripts and other tools would be flagged and could be hidden from RC. It would help to all people who are complaining about automated edits, currently users have no option to rid of changes done by such tools, this wouldbe even helpful for tracking changes done by tools (in RFA people could just click show only non automated edits when reading one's edits). Thank you for response. Petrb (talk) 07:49, 30 November 2011 (UTC)

Btw by saying it would act same I don't mean it would be same, users with bot flag actually don't have extra permissions, that is user right Bot what gives user extra permissions, so this flag wouldn't allow users to edit more, just tag contributions. Petrb (talk) 07:53, 30 November 2011 (UTC)

There's a distinction, as I understand it, between the account "bot flag" and the API "bot flag". What I think you are talking about is something allied to the second, which makes sense. What would be even more nifty would be if the there was a "tool revert" flag for Huggle reverts and similar, which was also applied to the reverted edit. In fact this type of thing might be useful for "undo" and "rollback" too. Rich Farmbrough, 15:22, 30 November 2011 (UTC).

Yes it would be applicable even there of course. Petrb (talk) 15:26, 30 November 2011 (UTC)

Is this the same as the m:flood flag or is that something else? --Philosopher ^{Let us reason together.} 20:24, 5 December 2011 (UTC)

I specifically like the idea that every rollback edit (and the edit rolled back) are marked say r so that: A Editors can eliminate (in the user interface) all edits so marked, both from RC and the watchlist and also(unlike bot contributions that you still sometimes what to review) from the article edit history itself; B Users have a simple method to audit the use of the rollback function. I don't think this should apply to undo since much of that seems to be used as a statement for constructive edits, not as simple vandalism removal. Crazynas ^t 06:15, 7 December 2011 (UTC)

I think these changes would make the editors' lifes easier:

1. Add an option to mark a watchlist entry "read", so that in "all edits" mode (as opposed to "most recent") the editor will see only the changes since that point.
2. Automatically mark read all the changes prior to the editor's own last edit on per entry basis.
3. Add an ability to sort watchlist on entries (as opposed to a single timeline).

To make things clearer:

Note: the hide link hides not only the edit it corresponds to, but also every edit of that article prior to that one.

This would help keeping watchlist easier to read. — Dmitrij D. Czarkoff (talk) 09:34, 30 November 2011 (UTC)

If the first two suggestions ran side by side, an editor who selects to not see their own changes, viewing his or her watchlist after doing some work, would see nothing. All the changes that had occurred while they were working would be excluded as they preceded the editors last edit.

We can already select how far back our view of the watched changes go down to mere minutes. I (for example) show - 500, all changes, 2days. I can then request only the last 0.02 of a day.

I don't understand point 3. fredgandt 09:59, 30 November 2011 (UTC)

I made the wording more explicit: after user edits Example article, all prior edits to Example are marked as read; the edits to other articles aren't marked. Point 3 means that if user selects an option, the edits to the same article are grouped together. I could — Dmitrij D. Czarkoff (talk) 10:43, 30 November 2011 (UTC)

I understand better now but think even that just adds confusion to a simple process. The end result would be something so similar to viewing only recent edits, why not just view those? The whole point (for me) of viewing "all edits" as opposed to just "recent" is so I can watch how something is being edited (over time) rather than just that it was edited. fredgandt 11:09, 30 November 2011 (UTC)

I want to be able to see all edits since the last one I've seen. Eg., I get very puzzled, when I see a watchlist entry with a summary Typo. When all edits are shown, some important edit can get lost between some more recent edits to other articles, or can be mistaken (eg., User2 makes two edits with summary "More info", so I mistakenly get the recent one for an old one, as I don't remember the exact time and date that one was made). Making it possible to hide edits before a timestamp can help avoid such problems.

Support point 3 (post clarification) as a togglable option. fredgandt 10:57, 30 November 2011 (UTC)

I would just like an automatic flag to indicate that I have looked at an edit. I am happy to keep the full list visible, but when I next log on I would like to see at a glance what I have not checked yet. Peter (Southwood) ^(talk): 16:13, 30 November 2011 (UTC)

• You many want to take a look at User talk:UncleDouggie/smart watchlist.js. --Yair rand (talk) 20:30, 30 November 2011 (UTC)

As an alternative to point 1, why do we not have the already-available option enabled that shows "Pages which have been changed since you last visited them are shown in bold", like all other projects? — Edokter (talk) — 16:23, 30 November 2011 (UTC)

It's much less useful in practice. — Dmitrij D. Czarkoff (talk) 16:42, 30 November 2011 (UTC)

Sometime small change is good change. I'd be happy with the list as it is but with boldening as an indication. fredgandt 21:05, 30 November 2011 (UTC)

Seems we need class "mw-watched" wrapped around those pages that are featured on changed lists. After a few quick looks around Mediawiki I have discovered...nothing useful. fredgandt 09:57, 2 December 2011 (UTC)

It's an option ($wgShowUpdatedMarker) that a dev would need to enable in enwiki's configuration. — Edokter (talk) — 13:14, 2 December 2011 (UTC)

Aren't you a dev? fredgandt 13:20, 2 December 2011 (UTC)

Nope, just an admin. — Edokter (talk) — 13:39, 2 December 2011 (UTC)

Ah. I thought you might be since you do a lot of tech work. fredgandt 13:48, 2 December 2011 (UTC)

If you want to make changes to configuration of any wmf project, you usualy just need a concensus :) or good reason Petrb (talk) 13:42, 2 December 2011 (UTC)

So we should propose this separately? I would love it. I forgot it was missing. As soon as Edokter mentioned it I went back to my old haunt and, sure enough, it's in use. One click of the "Mark all pages visited" button and no more bold text, so for users who didn't like it there would be little change. fredgandt 13:48, 2 December 2011 (UTC)

I don't know if it matters "how" is it proposed, however once it's clear if it's wanted or not (by community), you can just create a ticket and it would be probably updated (unless there are some implications regarding that option, which I doubt). Petrb (talk) 13:55, 2 December 2011 (UTC)

Of course. I was rather thinking for the sake of clarity, it might be better to propose simply "Switch on the thing" than expect users to find their way to this bit of this proposal. Wp:TL;DR can have a terrible effect on the outcome of these things. fredgandt 14:00, 2 December 2011 (UTC)

I'll propose the change below and see what happens. — Edokter (talk) — 14:05, 2 December 2011 (UTC)

Good man! I'll walk the dog and pay my water bill  fredgandt 14:07, 2 December 2011 (UTC)

• I have listed this proposal at Template:Centralized discussion. Cunard (talk) 08:58, 4 December 2011 (UTC)

For what it's worth, this feature is already accessible with a script, User:Ais523/watchlistnotifier.js (which I use and is very handy). I think it would be easy enough to implement here. Perhaps make it opt-in as a gadget? Steven Zhang ^{Join the DR army!} 01:04, 7 December 2011 (UTC)

I propose that User:Mindspillage/disputes be elevated to guideline or policy. Since it is only three paragraphs, I will quote it here:

Disputes are never solved by escalating them.

If you feel wronged by another user's words, nothing is ever gained by responding on the offensive. Respond with courtesy and respect—even if you don't think it's deserved—or don't respond at all. Even if you are certain the other party is not acting in good faith, escalating the dispute does nothing to help you. By continuing it, you are no longer without blame for any problem that arises; you have fanned the flames. A dispute that would have faded away for lack of interest gains vigor with another participant. If you respond on the offensive to someone who has attacked you, why would their reaction be anything other than another attack? They have already shown themselves to be willing to attack once, to not following the guidelines of civility. Sinking to their level only encourages them to continue.

When in doubt, be kind. When not in doubt, be kind anyway. A courteous and civil response to a potentially inflammatory statement has many possible outcomes. If the offense was due purely to misunderstanding, you have avoided making an unwarranted attack on someone who has done you no wrong. If you were intentionally attacked, you have avoided sinking to the level of the person who did it. When you respond with hostility, you behave no better than they do, and you give legitimacy to their opinion of you. If someone believes you to be hostile, and you respond unkindly, you confirm that. If you respond with nothing but civility, your attacker is the one who looks bad, not you.

The hardest thing about following this guideline is stifling your ego. You have not "lost" by not answering a perceived attack in kind, or by failing to get the last word. If you don't react to a perceived slight, their attack has completely failed to do what it was intended to do.

Are there any reasons that would not be appropriate as a guideline or policy? 67.6.191.142 (talk) 20:47, 5 December 2011 (UTC)

Sounds like a good policy for an infant's school, or perhaps a closed order of nuns. Malleus Fatuorum 20:51, 5 December 2011 (UTC)

It is possible to be kind but uncivil (e.g. being overly condescending), or to be civil but unkind (e.g. being blunt but honest). Kindness is not a higher form of civility, and it is the latter that is required for this encyclopedia. I've seen a number of (now-blocked) editors who used kindness to hide their misdoings, while editors remaining firm in the policies had to be blunt with them. Ian.thomson (talk) 21:08, 5 December 2011 (UTC)

"If you respond with nothing but civility, your attacker is the one who looks bad, not you." Yes, that's exactly true, to our detriment. It has become clear that if you're capable of maintaining a tone of superficial civility, then you can get away with pretty much anything else on this project. If Wikipedia fails, that dynamic will be at least partly responsible.

I am categorically opposed to "strengthening civility rules", because we're already too lazy in that regard - we already resolve disputes on the basis of civility alone without considering more complex, but equally relevant aspects. MastCell ^Talk 23:28, 5 December 2011 (UTC)

Do you have any evidence supporting that assertion? I have seen civil editors blocked over accusations of both, in separate instances, POV pushing and disregarding consensus (which was barely a plurality, just that the side they were on was less vocal and the opposing side was less civil.) I have heard this argument before, but where is the evidence supporting it? 67.6.191.142 (talk) 23:38, 5 December 2011 (UTC)

"Do you have any evidence supporting that assertion? It seems to me that your experience is sufficiently limited that I can't esteem it. Consensus and POV pushing don't related to civility at all. And as an IP editior, can we really trust your opinion. I've heard your argument before, and I've never seen a demonstration from first principles, please provide your sources (and his sources, and the flying nun)." Civil invective is just as bad as incivil invective, no? The three paragraphs above make nice reading for an essay about defusing conduct in certain circumstances. They hardly relate to the 16th century Italian duelling culture of administrators, who, if anything, are less encyclopaedic than the Italians as the Italians had real cause to fear bleeding to death through abdominal wounds. Fifelfoo (talk) 03:34, 6 December 2011 (UTC)

I'm with the IP - I don't know if I've ever seen civility take precedence over anything else, and would like to see an example. Not in a "prove it" way, but in a "OK, I'm listening, let me understand where you're coming from" way. --JaGa^talk 04:15, 6 December 2011 (UTC)

We actually have a case of an editor getting in trouble for polite incivility here, amid the editor getting in bigger trouble for outright incivility in reaction, and an admin getting away with calling people dicks. Ian.thomson (talk) 04:31, 6 December 2011 (UTC)

Back to the proposal: the thing is a philosophical stance; the wording makes it impossible for it to become policy. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 03:38, 6 December 2011 (UTC)

I was thinking that too. I agree with the sentiment, but I don't see how to make it policy. --JaGa^talk 04:09, 6 December 2011 (UTC)

I think this old page has a "standard that all editors should normally follow" that's worded quite well: "...editors should always treat each other with consideration and respect." "Try to treat your fellow editors as respected colleagues with whom you are working on an important project." "Welcome other people to edit the articles but do discourage non-constructive edits." Ian.thomson (talk) 04:31, 6 December 2011 (UTC)

Actually, I laid out a system for making civility stick some time ago - it's not difficult to do - but the idea ran into intense opposition from people who didn't want their behavior curtailed by civility considerations. whaddayagonnado… --Ludwigs2 15:55, 6 December 2011 (UTC)

I agree. With no disrespect to Mindspillage's essay, it does not recommend any behavior that existing civility policy does not; it merely justifies and encourages that behavior, by encouraging people to think about things in a certain way. While justifying policy is a good idea, justifications are not part of policy, just as Wikipedia:Criteria for speedy deletion is distinct from Wikipedia:Criteria for speedy deletion/Explanations. And we certainly can't (and wouldn't want to) enforce that people think about civility in a certain way. Dcoetzee 07:24, 6 December 2011 (UTC)

• So be kinder to bullies because resisting looks bad: Any such "please be nicer" guidelines really need to say, "Please kindly report abuse to WP:WQT and stop bullying instantly or sooner". I have been suspecting that more and more guidelines are being rewritten to "please protect bullies" and be nicer to them, and do not tell them they cannot do things without consensus. Instead, we need to ensure how essay WP:WikiBullying reminds people to seek consensus: no deleting whole sections of WP:Verifiable text without prior discussion and consensus. Fortunately, WP:BULLYING already defends an editor in reminding others to follow policies, as not being an act of bullying. ("Stating a real policy when it is necessary is not considered WikiBullying"). Perhaps that essay needs to be elevated into a guideline. -Wikid77 (talk) 12:11, 6 December 2011 (UTC)

There are far more serious issues that plague this project than people not being all fluffy-bunny-nice with each other. Biographies created on fringe notable people in order to denigrate, the long-running Israel-Palestine topic area war, the drive to supercede policy on "not censored" to cater to religious fundamentalism, and so on. Each of these damaging movements or areas feature a host of editors who are leagues more problematic than someone who drops an occasional "fuck" into a discussion. Tarc (talk) 20:21, 6 December 2011 (UTC)

• Oppose - Since you use the word "propose," I'll use bold type. It's a nice essay but nothing that can or should be elevated to a guideline or policy. Carrite (talk) 20:23, 6 December 2011 (UTC)

A second attempt has been made at coding the policy. Please review User:Od Mishehu/Arbitration Committee Elections, and express your opinions at User talk:Od Mishehu/Arbitration Committee Elections. עוד מישהו Od Mishehu 21:20, 6 December 2011 (UTC)

If you look up 2012 straw poll results and find the map of U.S.A. you will find someone has changed the state of illinois to look like Newt Gingrich won the straw poll there. This is a Lie. Dr.Ron Paul won illinois, someone should please change the color of illinois back to yellow as to keep wikipedia as accurate as possible. thanks! — Preceding unsigned comment added by Ronpaul2 (talk • contribs) 23:47, 6 December 2011 (UTC)

First, the proper place to discuss this is the article talk page at Talk:Straw polls for the Republican Party presidential primaries, 2012. Second, per the reference linked from the Nov 19 Illinois straw poll info, (the most recent) Gingrich did win it. Unless you can provide sources to the contrary, there is nothing we can do to help you. Monty₈₄₅ 23:51, 6 December 2011 (UTC)

Hi, I thought about a little improvement which is worth considering: In the end of every article of Wikipedia, there will be a section with questions summarizing the page, with references to the answers inside the article itself. It could be a good way to help people study the article. As usual, the questions will be written by users.

Example(The article about Michael Jordan):

Michael Jordan:

Michael Jeffrey Jordan (born February 17, 1963) is a former American professional basketball player, active entrepreneur, and majority owner...

...

...

...

Questions:

In what sports has Jordan professionally played? (Answer is hidden until the user clicks, then a reference or answer appear, maybe the relevant text is highlighted) What year did he take his first championship? (Answer is hidden until the user clicks, then a reference or answer appear, maybe the relevant text is highlighted) etc...

The main idea behind it is using Wikipedia as a learning tool, what is actually happening today by fact. — Preceding unsigned comment added by Noamgranot (talk • contribs)

My first thought is that this would not be a very encyclopedic addition, and could be considered frivolous. Wikipedia and its editors are trying to improve and maintain it with in mind, its public image. In the past it was not taken seriously, but is now. I think this might reverse that trend. fredgandt 07:06, 6 December 2011 (UTC)

Do you know about Wikiversity and Wikibooks? I think those projects are more appropriated places for developing content in a way that helps the students. On Portuguese Wikibooks, there is b:pt:Template:Explicação which could be used for this kind of hidden answers. On Wikiversities, there is a Quiz extension. Helder 09:26, 6 December 2011 (UTC)

BTW: There was also this thread on wikitech-l about an alternative quiz extension. Helder 09:37, 6 December 2011 (UTC)

Agree with above comments in response to this proposal - Wikipedia is an encyclopaedia, and we should keep it that way, but Wikiversity is probably more appropriate for this type of thing. ACEOREVIVED (talk) 11:03, 7 December 2011 (UTC)

Discussion was moved to Wikipedia:Bot owners' noticeboard#Wikispecies needs help!. עוד מישהו Od Mishehu 06:59, 7 December 2011 (UTC)

Hi, this is just a quick notification to inform everyone that we have a brfa open, for a bot with administrator rights. The task it's self is fairly simple, it needs the rights to edit a full protected page in it's user space. See also, Wikipedia:Bots/Requests for approval/Fbot 10 for the original BRFA. Thanks! --Chris 02:40, 7 December 2011 (UTC)

Nevermind folks, the request has been withdrawn because Δ came up with a workaround that allows the bot to function without an admin flag. Sven Manguard Wha? 10:50, 8 December 2011 (UTC)

My proposal is as follows. We currently have a section headed "Redirects for discussion" to discuss problematic redirects. Can we also have a section headed "Names for discussion" to discuss articles where it may be considered that the name of the article could be changed? I was prompted to make this comment by the article headed List of pies. Since this list also includes tarts, such as the Bakewell tart, personally, I think it would be better if it were called "List of pies and tarts". Yes, I shall be leaving a message on the talk page of this article, and also contacting Wikipedia: WikiProject Food and Drink about this particular article, but since there may be other articles where it would be better if the title were changed, I thought that I would leave this proposal here. ACEOREVIVED (talk) 20:13, 7 December 2011 (UTC)

WP:RM Phil Bridger (talk) 21:17, 7 December 2011 (UTC)

Many thanks for that - I had not seen WP: RM before now! ACEOREVIVED (talk) 22:16, 7 December 2011 (UTC)

There may be a problem however with WP:RM in that it currently does not give clear direction to guidance in the header of some basic pointers/FAQ such as Q. "what if the proposal is not for a specific name, but any better name among many options?" Q."can I unilaterally rewrite/move the page while the RM discussion is ongoing?" etc. For example I recently did a RM proposal with redlink "new title (or something similar)" in the new title box. Now technically I believe that's not allowed, despite potentially being helpful given that many RMs end not in the exact title, but there's no guidance on this easily/clearly linked at WP:RM page head. So maybe a pre-RM WP:Names for discussion before RM space might be helpful? In ictu oculi (talk) 04:40, 10 December 2011 (UTC)

I've made a proposal that a watchlist notice be added to MediaWiki:Watchlist-details. Input on this matter would be appreciated. -FASTILY ^(TALK) 08:20, 9 December 2011 (UTC)

Witam, chciałbym zasilić Wikipedię poprzez darowiznę skromnej sumy wręcz powstał problem. Nie posiadam karty kredytowej - i nie mam jak ofiarować darowizny. Dobrze by było zrobić coś w stylu: PayU lub coś w stylu "kup teraz" (czyli daj darowiznę) klikasz wpisujesz kwotę i sposób zapłaty z jakiego konta czyli jaki transfer... wybieramy np. swój bank, konto i poprzez wybór zostajemy przekierowani na swoje konto logujemy się i dokonujemy przelewu wpłaty potwierdzając hasłem czy to sms (kodem) tak powinno być - uważam, że tak powinno być. — Preceding unsigned comment added by 178.37.168.37 (talk)

• Google translation (corrected a bit by human)

"Hi, I would like to fund Wikipedia by even a modest amount of donation, but there's a problem. Do not have a credit card - and I do not have a way to donate. It would be nice to do something like PayU or something like "buy now" (i.e. give a donation), you click, enter the amount and method of payment, and from what account, so what transfer ... for example, choose your bank account and by selection we are redirected to your account log in and make a transfer payment to confirm the password or sms (code) it should be - I think it should be like that." fredgandt 01:11, 10 December 2011 (UTC)

Proposal to create a new namespace. Suggest TemplateS:

• Any template created in this namespace would automatically substitute when saved.
• If subst: or safesubst: is added it should be ignored (as wherever used it will always subst).
• The preview display should be as is presently the case with e.g. {{subst:Example}}
• If used in another template, the syntax should be e.g. {{{Example}}} instead of {{{{{|safesubst:}}}Example}}
  • Although if safesubsted, the safesubst: should be ignored.
• If a TemplateS is included within another template (either in the Template or TemplateS namespace) it should sit and wait to be transcluded before substing.

In simple terms, a template namespace allowing the creation of templates that should always be substituted, without the need for the use of subst:

This would cut down on accidentally not substituted templates where they should have been. It would cut down on unnecessary transclusion. It would save a lot of explanation and confusion. Any present templates that should always be substituted (e.g. {{subst:Uw-vandalism1}} etc.) could be moved to the new namespace and continue to function just the same way but with automatic clean-up of errors. Etc. etc.

However patronizing this is going to sound: Please keep the comments free from hyperbole (this would be the worst thing ever!), presumption (this would be too difficult to implement), and negativity (this is a shit idea). This may not be 42, and I'm quite sure there are lots of technical issues involved. If you think the idea is shit, explain how it can be improved. Most importantly, where there's a will there's a way. fredgandt 20:48, 9 December 2011 (UTC)

How about introducing a new magic word, e.g. __AUTOSUBST__ instead? When a template containing this magic word is used, it will be automatically substituted. Also, triple-braces are used for template parameters. Another syntax will have to be used. Perhaps a nosubst: prefix. - ctzmsc3|talk 21:17, 9 December 2011 (UTC)

I like the magic word idea. Simple way to get an auto substitution without the fuss of my proposal. fredgandt 21:54, 9 December 2011 (UTC)

Although I have had second thoughts (see below) fredgandt 00:55, 10 December 2011 (UTC)

I have to say this: This would require a major rewrite in core, so perhaps it is best to submit a feature request at Bugzilla first to see if there is any support in doing so. This is standard advice for proposals requiring a major rewrite. A note about why this will not work: template space is technically no different from any other namespace. The parser will transclude or substitute anything you can throw at it. I myself would love to see parser functions not being substituted at all, but that also requires a rewrite. — Edokter (talk) — 21:19, 9 December 2011 (UTC)

My thinking was that, for example, to transclude Wikipedia:Example we use {{Wikipedia:Example}} but to transclude Template:Example we just use {{Example}}. My thought is thus, that since certain page names in certain namespaces are assumed by the tranclusive process, to be the source of templates, a new namespace could (when assumed).........

I have just found an enormous hole in my plan.

How would the software know...?

Hole fixed. As long as there were no Template: and TemplateS: templates with the same name, all is well.

.......parse the result of the transclusion as if substituted.

Simply put: If {{Example}} works (it doesn't transclude User:Example or Example or Wikipedia:Example) then we use that part of the system to add the new namespace and providing there are no templates in both template namespaces with the same name, each would behave uniquely.

You (Edokter) and I will it seems forever disagree about substituting parser functions. I believe that once they have done their job, they should be substed. The only time I see a use for an unsubsted parser function or magic word is when the refreshed page should return a new value. Example (not parser but...) substing {{REVISIONUSER}} is always correct unless you specifically want the page to show the last editor every time it's loaded. Or a parser function {{#ifeq:A|A|Yes|No}} is written in stone. It will never tell you anything else. Not substituting it is a waste of resources with no justification. Obviously that is a long a complex converstion with many what if's.

I actually didn't know we could go direct to Bugzilla to make feature requests. For the immediate future, I'd like to see where this leads. I rather like the idea of a magic word to use in the template (suggested above). fredgandt 21:54, 9 December 2011 (UTC)

Although I have had second thoughts (see below) fredgandt 00:48, 10 December 2011 (UTC)

• Like the new magic word idea (I'm assuming that would take a lot less of a rewrite in the wikimedia code?)Crazynas ^t 23:35, 9 December 2011 (UTC)

Although the magic word idea does seem simple, I have my doubts.

The creation of a custom namespace is very simple. See mw:Manual:Using_custom_namespaces#Why_you_would_want_a_custom_namespace (zooms in on section highlighting exactly what this proposed namespace would be for).

The new namespace would be in almost all ways an exact copy (in function) of the Template: namespace (so easy to create the basics).

• Here's where the magic word idea gets complex when considered against the new namespace.

A new magic word would need to be recognised throughout Wikipedia, by all scripts that might encounter it. This could mean (not 100% sure) a great deal of interweaving and rewriting. Like trying to play Pick-up sticks in reverse; not only when correctly used but also when incorrectly used. Without each and every script knowing what to do with the magic word if it finds it, we could end up with a great many spanners in the works.

The proposed new namespace would be a stand-alone development area where the few tweaks required could be carried out, without disturbing anything else.

The tweaks would be where the technicalities are not fully known to me, but I can hazard an educated guess that not much more would be required than an instruction to add "subst:" to the raw text of any template transcluded from the TemplateS: namespace (unless already there etc. etc.).

These tweaks could amount to little more than a series of ifs and else ifs. fredgandt 00:48, 10 December 2011 (UTC)

The main problem with a magic word is irreversibility. A vandalised or accidentally __AUTOSUBST__'d {{Convert}} woudl be a nightmare.

The name-pace idea is cute, though. Rich Farmbrough, 19:11, 10 December 2011 (UTC).

If it's implemented correctly, then __AUTOSUBST__ vandalism shouldn't be a big problem. As I understand it, adding __AUTOSUBST__ to a template and clicking "Save" wouldn't automatically subst every existing transclusion of the template. It would only cause subsequent transclusions to be substed. In other words, only when someone adds the template to a page and clicks "Save" would the template get substed. Most high-use templates are protected anyway, so it's unlikely that even a clever vandal would be able to do too much damage.

I like this proposal, but it will require thinking like this to ensure that more problems aren't introduced. The current solution to this problem is to add {{substituted|auto=yes}} to the template so that it gets added to Category:Wikipedia templates to be automatically substituted and a bot will go around and fix non-substed transclusions. —SW— ^yak 20:20, 12 December 2011 (UTC)

That's ({{substituted|auto=yes}}) good to know. Thanks I still think a new namespace is simplest all round. fredgandt 20:32, 12 December 2011 (UTC)

UNESCO's Open Access to Knowledge and Information could not ask for a better platform than Wikipedia.

What if government committed to these ideals incrementally shifted their tax-funded knowledge resources to Wikipedia? This would pose a considerable increase editing burden on Wikipedia, but would also dramatically increase the quality of the information resources, shifting to a true "real-time" encyclopedia.

I am trying to include this in a proposal for healthcare reform in Ontario, as it pertains to certain policies/procedures in our province's healthcare system that are often poorly understood/obscured. I would like to train/encourage my colleagues to participate in Wikipedia Medicine project and the other initiatives relevant to human health.

Ideas/Feedback? Always appreciated. Laith Bustani (talk) 14:25, 10 December 2011 (UTC)

• How would we cover events that are politically controversial? Wikipedia doesn't have ads to avoid any appearance of bias, this would be worse. -- Eraserhead1 <talk> 15:24, 10 December 2011 (UTC)
• Response: Hi Eraserhead1. Thanks for your feedback. I think the governments would have to subject themselves to the editorial policies of Wikipedia or risk deletion of their content, just like anyone else. That is the beauty of the concept, governments would be accountable to a universal, democratic/systematic means of validating their communications. Laith Bustani (talk) 16:01, 10 December 2011 (UTC)
• My current policy focus is healthcare, which is unique because everyone is affected by it, and my colleagues and I are actively looking at ways to improve engagement and transparency in the data analysis that leads to new recommendations for healthy living in its broadest sense.Laith Bustani (talk) 16:05, 10 December 2011 (UTC)
• Government programs are often politically charged, I don't see how we could have large scale contribution from government without a large dose of political bias coming with it, based on what ever party happens to be in charge at the time. Governments are not immune from having conflicts of interest either. Monty₈₄₅ 17:39, 10 December 2011 (UTC)
• Oppose - there's no way we could remain neutral if we did this. Sven Manguard Wha? 19:30, 10 December 2011 (UTC)
• Comment - confused here. All U.S. government produced material is PD and all country articles were expanded or started by importing the CIA Factbook. All U.S. city articles were created or expanded by importing U.S. census data. Thousands of articles are illustrated by images from the U.S. military, the U.S. National Archives, the German archive[2], Queensland Library and many other government libraries and archives. But I don't see how having governments directly involved would make us more an encyclopedia or more "real-time". You certainly don't expect that the U.S. government would edit the 2011 NATO attack in Pakistan until after their investigation is completed? Or that U.S. and Pakistan government would cooperate to build a neutral article on the death of bin Laden while Pakistani jets were still flying combat patrol. (Or choose your favorite 'friendly' pair -- Israel/Gaza, Georgia/Russia, whatever) Rmhermen (talk) 20:06, 10 December 2011 (UTC)
• Comment- Thanks Monty845, Sven Manguard, and Rmhermen for your points. The same "difficulties" "biases", etc. exist in the way that information is currently handled. The scary thing is that that we pretend these problems don't exist and at least with regards to health policy, we end up with a muddled web of recommendations that are often contradicting/confusing and biased. The strength of wikipedia is not the software, but the community. I can replicate a "wiki" for all sorts of things, but without the human editors to maintain integrity of the knowledge, it is a waste of time. I guess what I am saying is this: I am committed to trying to adopt the democratic editing principles behind Wikipedia to public health policy and even (this would require some tweaking on the privacy side of things) electronic medical records. What I need to know is the best way to "integrate" this effort with Wikipedia's existing treasure trove of knowledge. If there was a "win-win" way of doing this without replicating the wikipedia infrastructure/community, that would be amazing and go a long way of convincing the government that this is a good idea. Laith Bustani (talk) 22:50, 10 December 2011 (UTC)
  • Even restricted to the matter of health, individual governments give conflicting recommendations. The U.S. and EU differ whether several compounds are generally safe for human consumption, the U.S. withdrawal of RotaShield was not appreciated in Africa, the continued use of DDT in Africa is not appreciated by some Americans, etc. I am not seeing how this relates to Wikipedia the encyclopedia. Rmhermen (talk) 23:14, 11 December 2011 (UTC)
  • Comment: Rmhermen, the problems you (and others) point out here are actually opportunities. The problem with the world health organization and other governmental regulatory agencies is 1) lack of resources (mainly human) 2) lack of a prospectively agreed-upon, teachable system for resolving conflicting/contradictory recommendations. As a physician, I have to process conflicting recommendations all the time. When I recognize that recommendations are opinions, and trust the opinion of the person who I am trying to help above those of "experts", then amazing things happen. Yes, I have to be conscious of laws, regulations, my personal abilities/limits, etc. This is the "art" of medicine. What I see the wikipedia community/platform as making possible is a "transparent" debate/discussion of universal health issues/treatment recommendations that will take them from being improperly applied/generalized to highly customized/refined through broad-based, and ongoing editing. It pushes the concept of "real-time" historical record, but because of the diversity of its community, and it's Wikipedia:Five_pillars its it has perhaps more integrity than any governed body I know. I have no delusions that this is a "perfect fit", or that there are not real "problems", but I would not be surprised if Wikipedia's founders were challenged with the same logistical impossibilities when they originally came up with the idea.Laith Bustani (talk) 16:55, 12 December 2011 (UTC)

As a former public health worker myself, I fear your naivete has led you astray. We already have a massive problem gathering sufficient administrators and editors to edit the existing 3.8 million articles in the English-language Wikipedia alone. There is no way on Earth we could assemble the additional volunteers to maintain even the flawed level of accuracy and integrity which the existing Wikipedia articles display, for all the additional subject matter you are proposing to dump into our laps. --Orange Mike | Talk 17:02, 12 December 2011 (UTC)

• • Response: Orangemike, I freely admit to my Naïveté in this regard. Do we have statistics on the number of editors and the contributions they make to Wikipedia's integrity (last I heard, studies cited 96% accuracy, surpassing Encyclopedia Britannica). What is the processing cue like? OK, now, what if in exchange for governments agreeing upon wikipedia as a "good-enough to start" place to start embracing UNESCO's principles, how difficult do you think it would be to teach the skills required to 1) write higher quality articles 2) learn the editing tasks essential to maintaining Wikipedia's integrity? You see, if you are telling me that even on Wikipedia, there is way more work to do than people to do it, what hope in hell do I or any other government have in setting up a separate "walled garden" to replicate the process. I see this as a potential area to develop win-win relationships with small groups that are ready for this type of experimentation. I am holding up my hand and saying "pick-me, pick-me" as a test case for the application in healthcare policy. With respect to health care conditions/treamtent, though I have signed up for the Wikipedia medicine project, I do not routinely reference Wikipedia in the treatment of my patients and stick with more traditional information sources (journals, UpToDate, etc, colleagues). That being said, I have been amazed at the quality of some of the content and think that if I could get more of my (smarter, less naive) peers to participate, then we might go a long way to capturing/cleaning up the knowledge/experience that is wasted every time a treatment is initiated for an individual and the results of the treatment lost. Laith Bustani (talk) 22:41, 12 December 2011 (UTC)

That material could never be used in Wikipedia - unless you first get it published in a reliable peer-reviewed journal (preferably it get collated into a review article) and we decide it is a necessary addition to a encyclopedia-type article. No original research is a basic rule. Rmhermen (talk) 23:04, 12 December 2011 (UTC)

I'm not really certain what it is you're trying to achieve. To have accurate information about public health on the English Wikipedia? Great, you can get started by fixing these thousands of problems. To have health policy makers use the English Wikipedia to communicate with each other and to decide what their next policy will be? No, thanks: that's not an encyclopedia's job. We'll report what they've decided after they have WP:Published their decisions. Being involved in interpreting raw data and making these decisions would be a violation of the WP:No original research policy. WhatamIdoing (talk) 23:49, 12 December 2011 (UTC)

To get some highly needed outside input on this issue, please see Wikipedia_talk:Articles_for_deletion#Bold.2C_revert.2C_discuss where I argue that AfD should be Afd. Debresser (talk) 14:40, 11 December 2011 (UTC)

Oh, my. I thought it was another round of Wikipedia:Perennial proposals#Rename_AFD, but this is actually a discussion on the capitalization of the initialism, i.e., whether the page should refer to itself as "AfD" or "Afd". Don't we have anything better to do with our time these days? WhatamIdoing (talk) 00:07, 13 December 2011 (UTC)

Hey Ya'll - I am going to copy and paste this e-mail i've sent to three wikipedia admins/contacts. I got shot down by all three, the last one gave me this link.

See here, and if you do this -- more donations will come. Thanks.

Howdy,

I know you probably get a bunch of e-mails all day every day. But I think I have a good idea. Other public non profit organizations use this idea, and i suggest wikipedia use it too. I didn't know who to contact, so I ended up here, although i'm in South Carolina. My suggestion (ready?)... have an online gift thing that you can give to wikipedia in OTHER PEOPLES NAMES and wikipedia e-mails the person you're gifting, confirming the amount you gave IN THEIR NAME, FOR THEM, instead of getting them a stupid little gift...

Do you hear me? This is much better than getting someone a crappy dollar store gift, this is me donating to wikipedia and pawning it off as a gift ;)

They will like it, I would love it (showing off my support....) and less crap is given (they're just going to throw away my gift, or re-gift)

Please let me know how you feel about this idea. If you don't like it, I would still appreciate a response.

Thanks, Greg — Preceding unsigned comment added by 68.209.77.205 (talk)

Seems like a perfectly reasonable idea to me. Psychological trickery that would probably work. fredgandt 21:14, 11 December 2011 (UTC)

Who would want to receive a gift like this? Whilst Wikipedia is wonderful, I reckon most people would prefer a gift donation to be made to a charity that saves lives (or puppies or whatever they're into). Presents have to be meaningful, and unless the recipient is already a keen Wikipedian, then I think the gift would be a bit misplaced. Bazonka (talk) 21:19, 11 December 2011 (UTC)

Assuming by your indent that you are talking to me; It strikes me this would work in the same way you can buy people a square foot of moon or a Scottish Lordship. Not all gifts have to be meaningful or serious. Apart from anything, it is whether this would encourage giving that matters. I think it probably would, since people like to give things they might not have thought to buy for themselves. fredgandt 21:26, 11 December 2011 (UTC)

Actually it was a response to Greg. I have no problem with this proposal in principle, but I just reckon that there are other charitites that would be more appropriate for gift donations. Bazonka (talk) 21:40, 11 December 2011 (UTC)

You need to talk to User:Meganhernandez, who is in charge of the 2011 fundraising campaign. I'll let her know about your question. WhatamIdoing (talk) 00:10, 13 December 2011 (UTC)

When cancelling an edit on a section (more often than not after finding the code you were interested in or looking at a preview of something), the page we are returned to is top of page, with no hashed section title.

I'd like to be auto scrolled to the section I didn't edit, in the same way we are scrolled to the section if we did edit. fredgandt 21:20, 11 December 2011 (UTC)

Is it not simpler to click your browser's Back button? — This, that, and the other (talk) 10:11, 12 December 2011 (UTC)

Simpler for whom? Certainly simpler for WMF but no so simple for however many millions of users per day. I see the current behaviour as being contrary to expected behaviour. fredgandt 11:34, 12 December 2011 (UTC)

Hmmm. I have never used the Cancel link. Looks like all it does is reload the page without linking to the section. I always used browser back or backspace. ---— Gadget850 (Ed) ^talk 11:56, 12 December 2011 (UTC)

I always use the back button for this reason. It should not be hard to add a section to the link. However, a bigger peeve of mine is that the Cancel link should be a button. — Edokter (talk) — 17:27, 12 December 2011 (UTC)

I see the individual MediaWiki messages, but where is the edit summary and related built? Directly through the software or in an interface page? -— Gadget850 (Ed) ^talk 18:00, 12 December 2011 (UTC)

Totally agreed Edokter. Not being a button is also contrary to expectation. The addition of the section title to the URL would be a doddle for WMF. The question is, whether anyone feels it should be requested. So far, it seems people don't even use it. fredgandt 18:11, 12 December 2011 (UTC)

From [[3]]

Dear readers of this Talk:Non compos mentis. I am having troubles with Compos Mentis, as it is not mentioned in the English Wikipedia. I would like to refer to Compos mentis from my article about a new word called: Mentification. So I would like to change the subject of the page to Compos mentis and explain about it, and after having done that, in the same page I will let it be followed by the original explaination about Non compos mentis. To mention Compos mentis first is for reason that Compos mentis is more essential compared to Non compos mentis. I will leave all explanations as well as all references intact concerning the original term Non compos mentis. For your information: the term Compos mentis in my language (Dutch) has the same basic meaning in legal terms as in English, although the approach is in Dutch more from the neutral side, as Non compos mentis holds implicitely a judgement about the status of the mind and therefore the term: Non compos mentis seems like a prejudgement. A comparable situation would be with the term: Billable hours (at work) as there are also Non billable hours that would not directly lead to a specification on the clients bill. So to explain Non billable hours, one would explain billable hours as well, and first. My question to you: Would the proposed change above be all right with you? I will just wait for a couple of days. If I hear nothing, then I will make the change with all related consequent changes. Else we can discuss the subject further. Bouwhuise (talk) 23:16, 11 December 2011 (UTC)

Bouwhuise (talk) 07:56, 12 December 2011 (UTC)

List_of_legal_Latin_terms#C has "Compos Mentis" listed. FYI. fredgandt 11:37, 12 December 2011 (UTC)

Proposal to create a new magic word we can insert into long threads to create an [edit] link without creating a new section.

• I envisage being able to add the magic word (e.g. {{EDITPOINT}}) anywhere within a section, and have an [edit] link created at that point in the thread (floated to the right of the page as with all normal edit links). This would not create an {{anchor}}, section or subsection heading, or be recognised by the toc.
• When followed, the editor would be presented with an edit page populated by all the text of the section the EDITPOINT is in, from that point onward (including text in sub-sections), as would be normally expected, but not any text from that section that is above the EDITPOINT.
  • An alternative to this would be that all text from that section is presented as normal, with the exception that the raw text is then automatically scrolled to the point at which the EDITPOINT is featured. This may be a more practical and appealing usage, but may have technical difficulties the primary proposal doesn't.
• The reasoning is that when wanting to edit half way through a long section, we are presented with the whole section and its subsections, with little to no obvious indicators throughout the unformatted raw text to follow in order to find the point at which we wished to make our edit.
  • With EDITPOINTs inserted at intervals, we could access the section far nearer to the point we wish to edit than at present. We could simply use the nearest EDITPOINT that is above the focus of our attention.
• I believe this would make editing easier, would be relatively simple to create and install, and would have few downsides.
  • There is one obvious possible downside: Overuse. A simple solution for this is to Assume good faith. A more cynical approach might be to allow only a given number per section. Uses of templates are already limited (good thing too), so the scripting is almost entirely in place to handle the task already. This possible downside (even if not monitored or controlled by the software) is as easily dealt with as all other editing faux-pas, so would cause little extra work for guardians.
• Summary: A simple new mark-up that creates an [edit] link without creating a section. When followed, the editor gets an edit page populated by all text from the section the EDITPOINT is in, but automatically scrolled to the point in the raw text where the EDITPOINT used is situated. only from that EDITPOINT onward. This would make it easier to hone in on the point in that thread we wish to edit (reduced searching of the raw unformatted text).

Thanks for reading. fredgandt 08:43, 4 December 2011 (UTC)

Questions: I am concerned that the feature would just be used to make every paragraph an EDITPOINT and deter people from making logical section headers, as they would have in the past.

• Q1: Would points be overused, and flood a page with [edit][edit][edit][edit][edit][edit]?
• Q2: Since headers were no longer needed, would header titles suffer?
• Q3: How about create non-indexed headers "==Break2=={{nonindex}}" shows header "Break2" as [edit] but not in Table-of-Contents box?
• Q4: Should a page be "fractionalized" instead, by a menu option "Fract" which re-displays the page with dozens of "[edit]" links, for each paragraph of the page (with no need to embed editpoints)?
• Q5: How would a page redisplay to the edited thread unless editing by header? I do not think it could, and after an edit, the page would display to the top and no longer jump down to the section just edited.

Those are some other questions to consider before stating Support/Oppose. -Wikid77 14:27, revised 18:23, 6 December 2011 (UTC)

Compare to header [Edit] as a name: The concept is intended to not list any EDITPOINT headers in the Table-of-Contents box. However, that it might be ok to name a small section header as "====[Edit]====" to show a left-side "[Edit]" break (with a right-side "[edit]" button). For example, there is an header as "[Edit]" here:

This section, with header "====&nbsp; [Edit]====" is a 4th-level header which clearly indicates that it can be edited, without needing to create an {EDITPOINT} marker here. However, the header "[Edit]" will also appear in the Table-of-Contents box, above. Logically, users might see such break points are obvious edit-buttons, without the need to conceal editpoints. As more users insert headers named "[Edit]" as text edit-points, then the concept would be understood more widely, without adding special features. Does that seem like a good idea? -Wikid77 18:18, 6 December 2011 (UTC)

• Strong support - eminently sensible. Pesky (talk …stalk!) 08:53, 4 December 2011 (UTC)
• Support. Seems like a good incremental short term solution, and I'm pretty confident it could be implemented easily (but would require minor Mediawiki code changes). Some concerns: if the page is very large, including all text all the way to the end might be too much text. Perhaps just to the end of the section? Also, should the {{EDITPOINT}} tag itself be included or not? How would edit conflicts be handled? Alternatives: I think the better long-term solution here is a real in-place WYSIWYG editor that lets you edit as you read without switching views or formats, but that's a long way off and very hard to get right. As an intermediate alternative, it might be nice if there was some kind of "edit here" feature that let you just right click any piece of text and choose "Edit here" and it would open up an editing view scrolled directly to that location. Dcoetzee 09:25, 4 December 2011 (UTC)

• As I see it, this is a small step in the right direction, not a giant leap. I proposed that the text presented in its raw format is all the text from the section the EDITPOINT is in, from that point onward. Edit conflicts would be dealt with in exactly the same way as they are now. This is basically just an invisible section heading that even the toc doesn't see. The actual tag would of course be visible in the edit window, otherwise nobody could ever remove or more them. fredgandt 09:54, 4 December 2011 (UTC)

• Support. The number of times I'd have used this recently just at WT:NOT would have saved me a good hour at least (not including fewer edit conflicts). Thryduulf (talk) 12:45, 4 December 2011 (UTC)
• Weak support: to me it seems that those edit points are useful before inserting them, not after; another concern is that the articles would get littered with edit points. Still, that might be useful, so why not? Though I would prefer an option to add (visually) tiny edit point to every block element on the page. — Dmitrij D. Czarkoff (talk) 13:27, 4 December 2011 (UTC)
  • What do you mean by "block element"? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
    • It was about HTML elements with block properties, though I get that Mediawiki abuses HTML markup, so this could be limited to the topmost sub-elements of the article (each text block, blockquotes, etc...) — Dmitrij D. Czarkoff (talk) 16:09, 4 December 2011 (UTC)
• Comment: this isn't going to happen; the devs will say it's covered by LiquidThreads, and anyway editing is based fundamentally on sections, so the best you can do is scroll to a pre-specified point in the wikitext. That latter idea though can be done by a script. The timestamp with (UTC) at the end of each signature is fairly unique; a script could add a little mark at the end of each (UTC), and when clicked it goes into edit mode and searches for that timestamp in the wikitext. Rd232 ^talk 13:45, 4 December 2011 (UTC)
  • Is liquid threads ever coming though? It's being trialled on some user talk pages on Wiktionary, but it's not ready for general release yet and hasn't had any significant changes for a couple of years. It's good in theory, but I've yet to be convinced it will actually do what it's trying to do. So in the meantime, why not implement this interim proposal that is technically possible without requiring years of development? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
    • Well for one thing, the client-side script I suggested would be a better solution than the magic word. For another, I severely doubt that if a bug was filed today it would result in a change to Wikipedia's functionality in less than 2 years, even if the developers agreed in principle. Developer time is simply too limited. Rd232 ^talk 19:39, 4 December 2011 (UTC)

    The Extension:LiquidThreads is being rewritten, and you can follow the status of the LiquidThreads 3.0 development on this page: mw:LiquidThreads_3.0/status#2011-10-31. Helder 22:20, 4 December 2011 (UTC)

  • LiquidThreads is for discussion pages, not articles... I don't see the relevance. Dcoetzee 04:49, 6 December 2011 (UTC)
• Rd232 is correct: whatever the merits, this proposal will not be implemented. For one thing, inserting "===Break 1===" is almost equivalent (yes, it's not the same and has defects, but it's very similar). Re LiquidThreads: That's the knockout; devs would not want to work on some tweak that would be obsoleted by LQT. My opinion: LQT would kill good editors, and I hope the community manages to repel it (in brief: too obtrusive; encourages "this is a forum"; POV pushing would never end; too hard to remove unhelpful comments). Johnuniq (talk) 02:25, 5 December 2011 (UTC)

What about automatically inserting edit points every x bytes in a section over a length of y bytes? That way it would be impossible for people to go nuts with it. Add an option to show/hide edit points in the preferences, or for each page individually, and anybody that doesn't like them wouldn't have to deal with them. Put me down for a Weak support. Falconus^{p t c} 11:58, 5 December 2011 (UTC)

Although I agree with those suggestions and think they would improve the overall proposal, I think asking for more than the simplest upgrade could lead more certainly to it not being added. I'm going to be updating the proposal to simplify it (technically) with just that in mind. Very basically, I think proposing the alternative (in the proposal lead) method is more likely to be considered for creation and installation, since it is nothing more than an adaptation of the code controlling nd displaying section headings. fredgandt 20:36, 5 December 2011 (UTC)

• Support. They don't have to be used in articles. If an article section is that long we would make section breaks.Jasper Deng (talk) 22:42, 5 December 2011 (UTC)

• I've struck out (crossed through) and inserted (shows underlined) some text in the proposal lead since having a think about it. The proposal seems to be getting bogged down in technical details. Can we first establish simply if there is a rough consensus for some sort of functionality that allows this kind of thing? Once we know if the basic idea is worth exploring, we can get techy-wid-it!
  • I've started work on a user script and a template that may or may not amount to something useful. I'll keep you posted. I would prefer the function/feature to be part of the Mediawiki software though. fredgandt 19:42, 6 December 2011 (UTC)
• Support - sensible idea for pages with longer sections. A can see issues arising with these edit points being overused, however, so there would need to be clear instructions on how to use them (perhaps a new WP namespace page on edit point guidelines). Chris (talk) 00:54, 13 December 2011 (UTC)

• Week support: "==Break2=={{nonindex}}" could be used too.. as well as the normal breaks. Weighing it with the possible litter we can get yet the usefulness of such edit-point. --lTopGunl (talk) 23:47, 13 December 2011 (UTC)

To add a Support/Oppose note, edit this section and place text above the header "End of EDITPOINT" so that new text will be listed in the Support/Oppose section. -Wikid77 14:03, 6 December 2011 (UTC)

Jimbo is looking for input regarding the passage of SOPA and how it will effect Wikipedia.here. Crazynas ^t 22:55, 10 December 2011 (UTC)

Wikipedia:SOPA initiative in the unlikely event that we get to that point, some advance planning would be good. Crazynas ^t 10:31, 13 December 2011 (UTC)

• Please visit this discussion on Wikipedia talk:Merging to comment. Protonk (talk) 00:53, 14 December 2011 (UTC)

I feel that when multiple non-registered users are participating in a discussion on a talk page it is sometimes difficult to keep track of who is saying what (as strings of numbers are less memorable IMO than names). Therefore I propose that the current mechanic which governs how external links in square brackets are displayed (i.e. by labelling them as the n^th link on the page, where the number changes automatically – e.g. [4] [5] [6]) be grafted/exported/whatever onto IP signatures, so that in future they automatically look something like this:

Comment 1. 1.23.456.78⁽¹⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 2. 9.01.234.56⁽²⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 2a. 1.23.456.78⁽¹⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 3. 7.89.012.34⁽³⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 3a. 9.01.234.56⁽²⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 3b. 1.23.456.87⁽⁴⁾ (talk) 14:56, 12 December 2011 (UTC)

Except that this is evidently a mock-up, and the aesthetics can be played around with, but you get the idea. My thinking is that the "[7] [8]" technology already exists, so it would reduce the workload in creating this feature? It Is Me Here ^{t / c} 14:56, 12 December 2011 (UTC)

Just a note, and I say this as a someone not very familiar with the underlying software and mechanics of Wikipedia, but when you create three external links, of which the first and third are the same, they will not have the same number (see here). So I am not sure, whether applying the external links mechanics to the IPs (if that's possible at all, I don't know) would have the effect you want to achieve. Toshio Yamaguchi (talk) 15:09, 12 December 2011 (UTC)

I don't think there's much chance of this being incorporated into MediaWiki, but it would be easy enough for someone to write a userscript that adds your indicator after all IP sig links. Anomie⚔ 16:51, 12 December 2011 (UTC)

There is no way to do this with the current method of applying the link icons; see Help:External link icons. -— Gadget850 (Ed) ^talk 17:40, 12 December 2011 (UTC)

The proposer is presumably thinking of citation links, which can be made to repeat numbers, but which involves quite a bit of overhead. --erachima talk 18:30, 12 December 2011 (UTC)

Those are done by the Cite software extension. ---— Gadget850 (Ed) ^talk 12:53, 13 December 2011 (UTC)

There's an RfC on making the the {{Orphan}} tag invisible. It's at Template talk:Orphan#Proposal - Change this to a hidden category template. I'm spamming it here because it's a highly visible template and so this is an important issue. (Arguably a CENT RfC might be in order since this is template that many readers see often. It might be called for to bump it up to that level if anyone wants to.) --Herostratus (talk) 16:48, 13 December 2011 (UTC)

The Articles for deletion process currently operates as follows:

In some cases, this process is unsatisfactory. If no meaningful contributions are made to a discussion on its first day, it is likely not to be visited by contributors until the eighth (closing) day. Many people will only click on today or closing, and not seek out any of the intermediate days. So some AfD's disappear, undiscussed, into limbo for a week, during which time nothing happens - the AfD is effectively inactive.
So, I propose the creation of an AfD holding pen for new discussions. The following process will then take place:

• A discussion is opened in the AfD holding pen (or whatever we want to call it). This pen can be accessed through the Deletion discussions box - technically, it will be just the same as a daily deletion log, but won't be limited to one day's AfDs only.
• It stays in the pen (potentially for several days) until the discussion has properly begun, i.e. someone has contributed who is not the deletion proposer or the page's creator. It is then moved to that day's deletion log.
• The AfD then follows the current procedure until closing day. Perhaps the length of discussion time can be reduced to less than a week.

This will reduce the number of AfDs that are relisted by ensuring that all undiscussed AfDs are still easily accessible via the Deletion discussions box.
I don't think that the holding pen would get overloaded, because things should be moved out of it fairly quickly. We may want to consider a maximum holding time before an Admin can retire the AfD as unresolved, though I suspect that this would not be reached often. Bazonka (talk) 22:33, 5 December 2011 (UTC)

An interesting idea, but is there really a problem with the current system? It only takes a few seconds to relist a debate and most articles up for AfD aren't of the "urgent that this be deleted" variety. --Philosopher ^{Let us reason together.} 04:31, 6 December 2011 (UTC)

The problem is not with the few seconds to relist, but the fact that it can take a week to get there, during which time it is likely that nothing will happen because the discussion isn't readily accessible. I do take your point about urgency though; perhaps it's just me that gets frustrated by these unnecessary delays. Bazonka (talk) 07:51, 6 December 2011 (UTC)

I disagree that the debate isn't readily accessible. CAT:AFD, for example, is a great way to view all the active debates in a particular topic area - or in all areas, if you have time to kill. To be honest, I doubt I've ever used the discussions template posted here. UltraExactZZ ^Said ~ Did 20:28, 6 December 2011 (UTC)

That is indeed useful, if you know it exists. I didn't, and I bet plenty of other people don't either, because there is no simple route to it from WP:AFD. Perhaps this should be made more prominent. Bazonka (talk) 20:49, 6 December 2011 (UTC)

You could also promote Article Alerts that sorts deletion discussions by topic. </shameless plug> —  HELLKNOWZ  ▎TALK 10:14, 7 December 2011 (UTC)

As you can see, I have added some all options to the Deletion discussions template. This should help people to more easily find discussions that aren't on their first or last day. This does not necessarily mean that discussions won't remain undiscussed though, but it might reduce the number a bit. Bazonka (talk) 20:51, 8 December 2011 (UTC)

Someone has been reverting my edits to the "Deletion discussions" template claiming that it is "completely unusable", which I dispute. Some other opinions at Template talk:Deletion debates would be appreciated. Thanks. Bazonka (talk) 07:20, 14 December 2011 (UTC)

After spending some time recently RevDeling and RFOing salted titles I now believe that Special:Protectedtitles should become a restricted special page. This is because some of the deleted and salted pages I sent to RFO were (a) themselves suppressed and (b) associated logs were suppressed, meaning that when you now try to create such a page no indication is given (unless you are an Oversighter, presumably) that it ever existed, except for the fact that it is create-protected. However, even these pages which have been hidden from public view using some of our most stringent technical means still show up for all to see at Special:Protectedtitles, because they are still salted, even if their protection logs, owing to the nature of the pages' titles, are suppressed.

Therefore, if there is to be any point in the RevDel and Suppression tools in removing grossly offensive article and user names from public view, then Special:Protectedtitles must also be removed from public view.

N.B. restricting Special:Protectedtitles to Sysops and above would still leave the problem of Admins having access to a sort of oblique Oversight log, but at least this move would be a start. It Is Me Here ^{t / c} 10:52, 13 December 2011 (UTC)

I think a better solution would be that if you RevDel (or RFO) a SALTing of a page, you unSALT it, RevDel (or RFO) the unSALTing log, and if necessary add an approrpiate entry in MediaWiki:Titleblacklist. This way, you don't have the problem of admins seeing RFO material; you don't restrict the community's ability to view Special:Protectedtitles, a restriction which should only be done if absolutely necessary; and frequently the user who was thwarted in recreating the SALTed page due to SALT will try to get around it by homoglyphs - and Titleblacklist is a better way to stop such users. עוד מישהו Od Mishehu 16:30, 13 December 2011 (UTC)

But surely that would not solve my main concern (publicly viewable/un-hideable gunk, whose existence means that we are not following through with WP:DENY fully), since in your situation we would simply have gunk at MediaWiki:Titleblacklist rather than at Special:Protectedtitles?

Having said which, another thought has just struck me: is it possible to have the software check whether a salted page cannot now be created by non-autoconfirmed/non-Sysops anyway (since a lot of the titles I was sending to RFO were quite old, possibly predating AbFil, Titleblacklist and the rest of it)? If so, perhaps a list of such "over-salted" pages could be drawn up, and an OS could go through them and remove them from Protectedtitles in the way you suggested? It Is Me Here ^{t / c} 17:25, 13 December 2011 (UTC)

I imagine it would be relatively simple for a bot to take all the pages listed at Special:Protectedtitles, and check if each one of them has a SALT log entry which it can find. If the bot in question is run from an admin account, it will find just the "over-salted" ones; if it runs from an account without admin access, it will also find the salted ones where the log was admin-hidden. עוד מישהו Od Mishehu 20:04, 13 December 2011 (UTC)

How about a modification to the software to make such pages hidden in Special:ProtectedTitles, while those that are no problem can still be publicly viewable?  Hazard-SJ  ±  03:55, 15 December 2011 (UTC)

Does it just have to be ClueBot who fixes vandalism? I am sure that many acts of vandalism on Wikipedia get corrected by users who are not bots. ACEOREVIVED (talk) 10:59, 7 December 2011 (UTC)

I actually noticed during some recent huggling that a number of IPs were reverting vandalism (manually). In fact, I'm pretty sure that one IP was following the huggle feed in the IRC, because I ran into him or her reverting stuff about 20 times in two hours. Sven Manguard Wha? 16:47, 8 December 2011 (UTC)

Past research has indicated that for every IP-based act of vandalism, there are three or four well-intentioned edits by unregistered users. It's not at all uncommon to see unregistered editors fixing vandalism. WhatamIdoing (talk) 23:37, 12 December 2011 (UTC)

This discussion appears that it should be totally closed now, as it appears that ClueBot is again active - look at the history of the article Higgs boson, and if you click on the article's history, you will see that an act of vandalism was corrected by ClueBot today (December 15 2011). ACEOREVIVED (talk) 16:09, 15 December 2011 (UTC)

I would like to see the data regarding IP users, where can I find the analyses? WP:HUMAN has a graph from 2007 (4+ years ago — donkey's years for a website). Thanks --Squidonius (talk) 19:21, 15 December 2011 (UTC)

I would like to get consensus for the following bot task:

Automatically update Sony Corporation shareholders and subsidiaries#Shareholders with information from http://www.sony.net/SonyInfo/IR/stock/information.html where it says Principal Shareholders. That is, the shareholder rang, name and percentage should be checked by the bot against the information present on the website and automatically updated, when there is a discrepancy between the two pages. Toshio Yamaguchi (talk) 17:16, 10 December 2011 (UTC)

• confused why this is here and not on the Bot request page.Crazynas ^t 00:34, 11 December 2011 (UTC)

I am not a bot programmer. I want to reach a consensus here and then file a request at WP:BOTREQ. I thought such a task should have a consensus before being requested. Toshio Yamaguchi (talk) 00:56, 11 December 2011 (UTC)

You can still post your request at WP:BOTREQ. I will do it as a courtesy. PaoloNapolitano 10:56, 11 December 2011 (UTC)

Botreq would likely ask for consensus. Funnily enough I have been thinking about this sort of thing. The development cost for a single section of a single page is fairly high, but a generic solution (also called AI) is attractive. Rich Farmbrough, 21:19, 11 December 2011 (UTC).

Agreed; not a great cost/benefit ratio just for Sony, but in principle a tool like this could really help keep business coverage up to date. (Hmm. How about a bot for annual results or market cap?) bobrayner (talk) 21:11, 15 December 2011 (UTC)

I propose to create a new userright. Users with this right would be able to circumvent the spam filter. The rationale behind this is that it would make my work archiving reference links MUCH easier (see also this discussion). The way I want to work is I copy all the reference links to a page in my userspace, then go through this list, archive the links with WebCite and add the archive link to the reference links in my userspace. Then I would go back to the article and add the archive link to the corresponding reference. Toshio Yamaguchi (talk) 20:27, 14 December 2011 (UTC)

What happened to administrators? We can ask them to make necessary modifications if necessary. This doesn't often happen, so I wouldn't support.  Hazard-SJ  ±  03:48, 15 December 2011 (UTC)

Last I checked, administrators can't get around the spam blacklist; other than adding something to the whitelist. This was last week I had this problem.--v/r - TP 03:58, 15 December 2011 (UTC)

Bypassing the spam blacklist would render the page uneditable to all other users. No. T. Canens (talk) 04:13, 15 December 2011 (UTC)

Not exactly, since approx. 2010 you can edit and save paged with blacklisted links: spamlist only prevents new blacklisted links. Still, I don't think a new userright is a proper solution to Toshio's problem. — AlexSm 04:29, 15 December 2011 (UTC)

I definitely remember seeing instances this year where a newly blacklisted link prevented others from editing a page until someone found out what the culprit is. T. Canens (talk) 06:08, 15 December 2011 (UTC)

If it's any help, I recently submitted a patch that would help by telling you all the instances of offending links in one go. This makes it even easier to write a script that automatically 'nowiki's the bad links. - Jarry1250 ^{[Weasel? Discuss.]} 00:22, 18 December 2011 (UTC)

This is something that had bugged me for a very long time: How come the way we edit on Wikipedia is needlessly complicated? Although I have come to terms with it (at least with most of it), I imagine that a turn off for many new editors is how confusing everything is. They would not know how to use templates/categories/infoboxes etc. or even know how to bold or use headings. On many online sites, where you can contribute to discussions etc, there are buttons at the top of the editing box, not unlike microsoft word, that allow you to easily edit colour/bold/size etc. and a lot of other stuff without having to worry about three lines for bold and a copy and pasted line of text for colour etc. In other words, what you see is what you get. Whilst editing, you would see stuff in bold or coloured etc. Also if there were buttons along the "Advanced", "Special Characters", "Help", "Cite" row that had all the infoboxes/templates etc.. or something like that... it would make all our lives soo much easier. Why isn't this done?--Coin945 (talk) 11:19, 16 December 2011 (UTC)

There is wikiEd – is that what you were looking for? It Is Me Here ^{t / c} 15:04, 16 December 2011 (UTC)

And see Wikipedia:Village pump (technical)#Visual editor. – ukexpat (talk) 15:18, 16 December 2011 (UTC)

Ahh... thankyou very much. Both seem rather promising :)--Coin945 (talk) 04:36, 17 December 2011 (UTC)

Currently editing the section loads the whole source and sections are sometimes very long and all that content is loaded in to the edit-box as well. How about placing a small reply link (or button) at the end of talk page sections, clicking which will load the same section as an almost empty edit box and by default will have only the indentation suitable for a reply to the last comment which could be changed if required by the editor. This will prevent loading the whole text if some one only needs to reply and will also prevent mistaken editing of other comments. Or maybe even better than the reload, clicking the reply link expands into an edit box of the same format as mentioned above and clicking a save button in that would simply post the reply at the end but not reload the page instead become "your reply has been saved - reload page to see it" or something similar. The normal editing can still take place by clicking the 'edit' link while this will be an additional help. The proposal is open to be further decided as an opt-in/opt-out option that would be adjustable by individual users for themselves so as to see or not to see the reply link. --lTopGunl (talk) 15:27, 16 December 2011 (UTC)

The Liquid Threads extension does this, but we don't use it. I would however oppose implementation of the extension as many talk pages would need reconstruction.  Hazard-SJ  ㋡  23:54, 17 December 2011 (UTC)

How about having a new one which just posts the text into the source without any other changes in page structure or display by by-passing the reload following the proposal above? --lTopGunl (talk) 00:47, 18 December 2011 (UTC)

Would it be possible to remove fundraising banners for IPs from which donations have already been received this year? — Preceding unsigned comment added by Heymisterbill (talk • contribs) 20:54, 16 December 2011 (UTC)

technically, probably, but that would involve tracking and finding out whether it's a public computer (removing it from a shared computer is not good). And it would only work with cookies or something. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 22:16, 16 December 2011 (UTC)

In theory, it already does that. --Yair rand (talk) 05:42, 19 December 2011 (UTC)

While I'm doing my part to reduce the huge backlog in Category:Non-free images with orphaned versions more than 7 days old, I've several times found images in which an old version, not the current version, is preferable; for example, if the latest version is of substantially higher resolution than an older version. Unfortunately, in such cases I must delete the entire image, rather than just deleting the version, and then I need to restore the older version. If it's possible, I'd like to see the (del/undel) text for the latest revision be just as useful as it is for all older versions. Is it possible? Nyttend (talk) 13:11, 18 December 2011 (UTC)

For an example of what I'm talking about, look at the logs for File:Beastie Boys - Ch-Check It Out CD cover.jpg. Nyttend (talk) 13:15, 18 December 2011 (UTC)

Normally, one would revert to the proper version, then delete the old revisions. — Edokter (talk) — 19:45, 18 December 2011 (UTC)

In which case I need to delete even more revisions. If I could just delete the current revision, it would entail less effort. Nyttend (talk) 20:38, 18 December 2011 (UTC)

I have a suggestion that might make some money for Wikipedia and serve its goals at the same time.

I would like to be able to BUY a copy of a certain year of the entire site. I cannot say if this would be a set of DVD's or a large stand alone hard drive, but I would LOVE to have my own copy of the whole site. There are times that one's internet is not working and to have your own copy of the closest thing to an Encyclopedia Galactica would be delightful.

A second reason I think this is a good idea is that it would allow a researcher to document changes over time. For example, the word "soandso" only has a placeholder in Wikipedia 2011, but by 2012 it is a huge document. The phrase "soandso" appears to have entered the popular lexicon between 2011 and 2012.

We can learn a great deal about the past by looking at a popular encyclopedia at that time. What were the prevailing attitudes on certain subjects and what subjects might have been taboo. It would be a shame for Wikipedia to be moving forward in time and to leave nothing historical in its wake. The evolution of Wiki's or Wikipedia itself is a subject worthy of study, but unless there exists a static snapshot of a moment in time, that historical context is lost.

In the final analysis there is the fact that when civilization collapses, I'd like to know a few backups are out there somewhere.

See Wikipedia:Database download. You can download the whole site to your hard drive, for free. However, if civilization collapses, I think that the internet would be among the bottom of social priorities. Cambalachero (talk) 02:25, 17 November 2011 (UTC)

Do you know about page history? You can see all versions of every page, ever. For example, So and so began as a rather odd redirect in 2005 [9], and gradually expanded [10] [11]. (Not a great example; it's far more interesting to look at the historic versions of more substantial articles). Also, you might find nost:HomePage interesting, which is a frozen snapshot of Wikipedia from 2001 - e.g. nost:Earth.

There's various plans in place to provide a 'snapshot' of Wikipedia in various formats. I just hope they remember to write Don't Panic in large, friendly letters.  Chzz  ►  09:09, 17 November 2011 (UTC)

Wikipedia has never been for sale - Wikipedia always has been, and probably always will be, a free internet site, which is able to be accessed by any one who has access to the world wide web. ACEOREVIVED (talk) 20:53, 23 November 2011 (UTC)

Oh and by the way: you can also buy printed editions of Wikipedia! mabdul 11:55, 30 November 2011 (UTC)

• Oppose It's a good idea, but the encyclopedia is too large to try to document the entire thing. At this point, how would we easily make a distinction between actual articles and "Wiki" pages, such as the projects and special pages? What articles should be included/excluded from a printed addition. At this stage, with American culture moving away from print media and embracing the digital age, it would be like taking a step backward, rather than a step forward. Tarheel95 (Sprechen) 16:57, 5 December 2011 (UTC)
• There are various (free) versions that you can own, but they do suffer form some limitations. Cambalachero's idea is a good one in principle. Rich Farmbrough, 21:29, 5 December 2011 (UTC).
  

Provided you don't care about the images, this provides a dedicated offline copy of Wikipedia in a handheld package. Dragons flight (talk) 21:39, 5 December 2011 (UTC)

• Proposal is out of place. There is no policy or guideline of the English Wikipedia that has much to do with this. If you want to buy a physical copy from the Wikimedia Foundation, contact them directly and see if you can come to a mutually agreeable price. Alternatively, it doesn't have to be the Foundation; nothing stops anyone, really, from downloading the whole site and selling you a physical copy, but if you want to place an ad for such a person, this is probably not the right place to do it. --Trovatore (talk) 21:44, 5 December 2011 (UTC)

• My studies show that the English Wikipedia would fit on a large external hard drive, along with all media it uses (although they may have to be at reduced size). I think this could be sold for $100 USD, possibly less. I think it's an excellent idea for someone to do this. I might do it. WMF isn't going to do it, as they generally leave commercialization of content to others. Dcoetzee 10:25, 8 December 2011 (UTC)

Sure, go for it. Anyone can; it's (almost entirely^*) free. Anyone can do anything they want with it, as long as they give credit.^* Many people have copied various parts of Wikipedia to various formats; that's all great. No problem. And if they make $$$ from it, good luck to 'em.  Chzz  ►  10:23, 14 December 2011 (UTC)

• If you want to buy and carry a copy of Wikipedia, consider the WikiReader which retails for less than 100USD. You can download updates yourself or subscribe to their service and receive new copies of Wikipedia via the post. I have one on my coffee table and I love it. LeeColleton (talk) 04:11, 20 December 2011 (UTC)

Alright, this may sound silly, and may possibly be more appropriate on meta, but I don't use meta, so I'm asking here. I generally use the URL to navigate between wikis, for example if I'm looking at someone's Special:Contributions, I just have to change en. to fr., and there I am. And then, if I need to go to commons., I don't need to change .wikipedia.org, the software automatically translates it to .wikimedia.org. My "problem" is that it doesn't do the opposite translation. So if I come from the French Wikipedia, e.g. Discussion utilisateur:, I'm not redirected to User talk: when I change fr. to en., nor is wikimedia.org redirected to wikipedia.org once one changes the prefix. I propose that domain and subdomain redirects be established for all languages, at least to and from (from is already done) .en for interlanguage, and from .wikimedia.org to .wikipedia.org when going from meta or commons to a wikipedia (the opposite is already done). This could also apply for other types of wiki though I'm not familiar with them. Thoughts? P.S. I'm technically incompetent, sorry if there is something preventing this in the software or some kind of technical conflict that I'm not aware of. Regards CharlieEchoTango (contact) 07:01, 19 December 2011 (UTC)

This sounds similar to something proposed on the wikitech-l mailing list recently. Anomie⚔ 12:24, 19 December 2011 (UTC)

Good to know, thanks! Was there any follow-up on the proposal? CharlieEchoTango (contact) 03:10, 20 December 2011 (UTC)

May I suggest we start a workshop like they have on the French Wikipedia? I don't exactly know how they work, but the idea seems to be that they are pages where novices and experts congregate and discuss things. I know that sounds similar to the Ref Desks, and they are working well, but I mean starting workshops focused on specific goals, not linked merely to existing projects, but encompassing something broader. I think the best starting point would be a writers' workshop, focusing solely on improving the writing standard/ encyclopedic style of articles. The workshop would consist initially of one page, where we would nominate an article to work on, thrash out suggested improvements to the writing, and then post the changes back in the articles. Editing of content would be kept to the barest minimum. If successful, the idea could be expanded. IBE (talk) 13:50, 19 December 2011 (UTC)

• Haven't finished reading the proposal and a firm Support from me. Volunteers and students in a relaxed, easily found (and suggested (linked)) project space somewhere. would be awesome. Perfect way to boost quality, productivity, and retention (by way of encouragement). fredgandt 13:57, 19 December 2011 (UTC)
• Check with WikiProject Guild of Copy Editors. ---— Gadget850 (Ed) ^talk 13:59, 19 December 2011 (UTC)

Thanks for the link. I've noted it and will pursue it with them. Any further comments on the suggestion are welcome, but I did feel there had to at least be something very similar already. IBE (talk) 16:13, 19 December 2011 (UTC)

I uploaded files to here and not Commons with good reason; I'm fine with them being on commons, but they are easier to manage from en.wiki (such as tracking where they are, for instance) and it is a rather a rude shock when you're tryimg to assemble an article months or years later and you find they are no longer in your contributions list or upload log (yes, they somehow...disappear). Could people please obtain the explicit consent of users before rudely moving their image to commons? John Riemann Soong (talk) 05:34, 14 December 2011 (UTC)

• Bear in mind that you consent to allow this with any of your contributions. Photos simply happen to be most likely to be moved off wikipedia entirely (rather than text which is edited, deleted, moved around, etc.). I have a number of files uploaded here rather than commons for a variety of reasons and I don't usually have an issue with someone else reuploading them to commons and deleting the copy here. IF that happens just download the commons copy and re-upload it. Protonk (talk) 06:11, 14 December 2011 (UTC)

  The problem is when people delete your files and you have no idea where they went (because they disappear from your upload log, and they don't show up as a redlink because they are on Commons). John Riemann Soong (talk) 07:35, 14 December 2011 (UTC)

• Use the {{keep local}} tag, designed for this purpose. Making requesting user consent mandatory would make the majority of cases, where the uploader is no longer active, rather difficult. However, I personally find that keeping them all on commons makes them easier to track, especially with the ListFiles function. sonia♫ 06:34, 14 December 2011 (UTC)
• You're free to use {{keep local}} if you really want, but keep in mind this means any improvements made to the images or their descriptions on Commons, possibly long after you've departed the project, will not be seen on enwiki. This should not be a long-term solution. I agree that tracking files moved to Commons by user is an important issue and hope that once it's solved it'll eliminate this concern. Obtaining permission beforehand is infeasible because many departed users are impossible to reach. Dcoetzee 07:36, 14 December 2011 (UTC)

• While I sympathize with your inconvenience here, having to get the permission of the author to move or change something flies in the face of so many principles, policies, and standards on Wikipedia that the answer is, flat-out, no. --erachima talk 08:01, 14 December 2011 (UTC)

  There's nothing wrong with having the file kept locally. Yes, it can be copied freely -- but deleting a perfectly good, encyclopedic, functional copy without the author knowing about it at all is an issue. John Riemann Soong (talk) 08:18, 14 December 2011 (UTC)

Deleting an encyclopedic, functional copy where it is redundant is common and sensible-- say, for example, if a user made the same article twice under different names. Unifying all possible images in one place means that changes made will apply across all projects, making things more efficient (not to mention it being easier to find free files in one place). I doubt that anyone has meant to be rude in moving your files; they're just doing their job. The simple solution is to use {{keep local}}; it's created as a courtesy to users like you who prefer it this way, as much as it's not ideal. But your proposal is impractical and its implementation would slow file work dramatically. sonia♫ 08:36, 14 December 2011 (UTC)

I seems that an automatic notification if/when a file is moved would be helpful. At least then people would know if the (not their) files were moved, and where to. fredgandt 08:43, 14 December 2011 (UTC)

Yeah, notification could be done, but "explicit consent", no. It'd just add bureaucracy. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 08:51, 14 December 2011 (UTC)

• Oppose: moving to Commons no way harms editor — the image can still be watched, tracked and whatever. Moving images to Commons is in line with word and spirit of Wikipedia rules, and explicit author's content would just make matters worse for Wikimedia with no one's benefit. — Dmitrij D. Czarkoff (talk) 09:07, 14 December 2011 (UTC)
• Oppose, but see the problem: As WP:5P says 'all of your contributions can and will be mercilessly edited and redistributed.' However I do think that something better really should be done about the contribution list rather than deleting history. I find the business of contributions to deleted articles disappearing from history worrying too, I'd prefer they be listed even if one could not look at them. Personally I always upload to commons if possible, I view uploading to Wikipedia as something that only should be done for things with a restrictive license. Dmcq (talk) 10:26, 14 December 2011 (UTC)
• Oppose: Sleeping editors shouldn't block a move forever. A little background, before sending thousands of pix to Commons I sent hundreds (mostly more useful ones) to en and many of those have later been found by other edtitors and moved to Commons. Problem is, sometimes I don't see the notice in the original file, thus fail to follow the link and watchlist it in Commons, with the result that they are poorly categorized and not geotagged. So, if I fail to see the pre-announcement or otherwise do not object in a few days, the transfer ought to go ahead anyway. Silence implies consent. On the other hand, the thing I wish is, the moving bot should also watchlist it for me in Commons. Jim.henderson (talk) 19:39, 15 December 2011 (UTC)
• Oppose. I like the idea of an automatic notification if it's possible, but requiring consent would be problematic indeed. Commons exists for the sake of making media available to all WMF sites, so all images should be there unless there are copyright issues — please establish a Commons account and upload images there, rather than here. Nyttend (talk) 13:20, 18 December 2011 (UTC)
• Oppose per WP:OWN. I'm no fan of {{Keep local}} which is why I proposed a long time ago that it needs an optional reason parameter, but sadly that got shot down because, well, people who like OWNing their images and having to actually specify a reason for their desire to OWN might cause cognitive dissonance. And that would be bad. —Tom Morris (talk) 09:31, 20 December 2011 (UTC)
  • when a person releases an image under a free license they still actually "own" the image its just that they have given permission for the image to be used providing that certain conditions are met. Gnangarra 09:51, 20 December 2011 (UTC)
• oppose seaking permission before hand. I think it would be a good thing when the bot transfers the image to commons to post on the users talk that the move has occured, as user talk pages dont get deleted, if in the event that user becomes inactive the notifications will just sit there so that when the user is active again they'll know what happened. Gnangarra 09:51, 20 December 2011 (UTC)

There's an RfC on eliminating the need to add the <!-- Metadata: see [[Wikipedia:Persondata]] --> comment from the persondata template and perhaps even eliminating it from the articles as more significant edits are made. It's at eliminating the comment from Persondata. I'm spamming it here because it's a highly visible template and this issue has come up multiple times in multiple venues for multiple reasons and I would like to put it to rest once and for all. --Kumioko (talk) 04:10, 17 December 2011 (UTC)

The discussion of this at Wikipedia talk:Persondata#Can we stop adding the annoying, useless comment now? and Template talk:Persondata#Can we stop adding the annoying, useless comment now? show that there was consensus to remove the comment in the template, and that it has been removed, as you had wanted. Is your post here asking for something more? If not, let's close the discussion here. Senator2029║talk 15:40, 21 December 2011 (UTC)

Yes my questions are answered thank you. You can close the comment whenever you want. --Kumioko (talk) 20:21, 21 December 2011 (UTC)

Greetings. My name is Jonathan Obar, I'm a professor in the College of Communication Arts and Sciences at Michigan State University and a Teaching Fellow with the Wikimedia Foundation's Education Program. This coming semester I will be running a little experiment in one of my undergraduate classes. I thought that I would propose the idea to the community before things get rolling, and ask for your suggestions, feedback, criticism, and also your help!

Here's the idea... students these days (especially those studying communications) are fascinated by social media. The Education Program has done a fantastic job tapping into this fascination and the results are clear. A recent survey analysis that we completed suggests that more than 70% of the students (across the US) that have participated in the Education Program are enjoying the experience and prefer editing Wikipedia to writing "traditional" term papers. To students, social media is fun, but it's also relevant. Many communication students hope to get jobs with a new media focus and hope that their university experience prepares them for the position that they've been hoping for. This new class I'm developing, this small experiment, takes the Education Program to the next level. Instead of training students to be editors, why not train them to be administrators? The goal will be to provide students with a far more in-depth understanding of how Wikipedia operates, how the hierarchy of administration works, how policies are created (what the policies are), what admin tasks are completed daily, and so forth. What will also make this class different from most of the classes that are participating in the Education Program is that the entire class will be devoted to the "learn to be an administrator" concept, whereas most EP classes focus mainly on course content (depending upon the discipline) with the Wikipedia component being secondary.

In speaking with members of the Wikimedia Foundation and a variety of experienced administrators, it became clear right away that the students would not be able to actually perform advanced admin tasks. We had discussed potentially matching students up with admins as "buddies" so that the students could shadow them (it's an idea we're still considering), but I realized that this wouldn't allow students the freedom to participate in a truly active learning experience. Of course we wouldn't want students performing admin tasks without having gone through the formal RfA procedure, something that we won't be able to have the students do in such a short period of time (most of them probably don't have enough edits to get to the first level anyways). So, instead, the course will do the following:

Students will...

Step 1

• Study Wikipedia policies in general
• Study Wikipedia admin policies and procedures
• Learn how the community operates
• Introduce themselves to the community in a variety of ways
• Begin to integrate themselves into the community
• Begin to edit

Step 2 Conduct a variety of basic admin tasks like...

• New page patrol (will introduce themselves to the community first)
• Recent-change patrol (will introduce ...)
• Review images for copyright issues (will introduce...)
• Begin to organize a "bookshelf" for administrators
• Begin to build the bookshelf

Step 3

• Reach out to the admin community to chat
• Review different admin boards
• Reflect on their experiences and write about them
• (Hopefully) interview a few administrators about their experiences.

As you might imagine, I'm going to be figuring things out on the fly as I see how things go. For now, I thought that I would bring this idea to the community and ask for your feedback and suggestions. Personally, I think that this new idea will benefit all involved. From what I've heard there is a backlog of admin-related work on WP, our class could try to make a contribution in that area. I have also heard that the administrator community isn't growing at the rate it once was - our program is potentially training the Wikipedia admins of the future. The WMF likes the idea because it still gets students involved, connects a university class to WP and may lead to a new arm of the Education Program. The benefits to the students are obvious... learn the interworkings of one of the most popular social media/networking sites in the world.

Anyhow... What do you think? Anyone interested in helping out? I'd love to have some admins skype into our class, perhaps a few at a time for a discussion/debate? It'd be great if the students could interview a few admins too! Learn about what you do and why you love it!

Really looking forward to your comments.

Sincerely,

Jonathan Obar Jaobar (talk) 06:59, 20 December 2011 (UTC)

• I am supportive. We do need to train more admins. Having students learn about Wikipedia before they edit content I believe will be better then them trying to edit content before learning how Wikipedia works.Doc James (talk · contribs · email) 07:27, 20 December 2011 (UTC)
• From what I have seen in my experiences in admin coaching, people who edit for the purpose of becoming an administrator are like shooting stars: Bright at first, but they fade fast. I'm not convinced that what we need is to train administrators; what we need is to raise up editors who like what they're doing here. People who like it here and like what they're doing here tend to do a better job of things, from what I see. bibliomaniac15 07:37, 20 December 2011 (UTC)
• This is a great idea... but so far, only in theory. I don't know if you're aware of this, but the various Education Programs are on thin ice due to the vast amount of substandard content they generated -- skim WT:United States Education Program, the threads I linked to at WT:Canada Education Program and the whole of WT:India Education Program to get a feel for the issues. The most successful student projects on Wikipedia have professors that are experienced Wikipedians. This need for this is more acute since you are teaching Wikipedia and how we ward out unwanted content. This means you need to get your hands dirty shoveling crap, especially in the areas in which you want to teach (this will help you answer student questions). It's great to have the backlogs reduced, but doing so in an incompetent manner is counterproductive.

Calling Wikipedia "most popular social media/networking sites" is cause for concern.

Also, I have removed your email address as publishing it on-wiki is a Bad Idea(TM). MER-C 07:44, 20 December 2011 (UTC)

Disclaimer: I have worked with Jaobar in the past, as an Ambassador, and he is a professor at the University I attend (I have not, nor will be taking a class with him due to being in different departments). That being said, Jonathan, is a knowledgeable Wikipedian [12] with over 800 edits, and has had a successful class within the program (ie: this one of which created many good articles such as this article - all of which were made by 1st year undergrad students and in this case classified as a DYK on April 19, 2011). Hence I would not worry about the experience of the professor - instead would ask/hope that users would make any suggestions to the type of tasks these students could perform without requiring admin rights. Epistemophiliac (talk) 16:20, 20 December 2011 (UTC)

I agree that User:Jaobar has more experience than the typical EP professor. My specific concern is that he has little personal experience in the areas he wishes to cover (e.g. image tagging and [13]). MER-C 12:52, 21 December 2011 (UTC)

• I'd downplay the "admin" side given that in spite of the community's frequent stated belief that adminship is "no big deal", it is a term of art in the Wikipedia community. They are really being taught how to administrative tasks, rather than tasks that require sysop powers. Given that people are likely to get a bit tetchy about this, and given that students might get the wrong idea and go around claiming they are now Wikipedia administrators because they do new page patrolling, I'd leave off the word "admin". Think about it like this: imagine if you taught a bunch of graduate students how to teach undergraduates. You might call said training course 'How to become a professor'. But that doesn't mean they are professors at the end of it, they are TAs who have skills that would be handy for them if they choose to stay in academia. The course could quite easily be called something like "How to be a Wikipedian" or "How to edit Wikipedia" or something like that. There does definitely need to be a better name for "that thing that non-admins do that is administrative". I've used the term "admin-like tasks" but that's kind of a mouthful. There's "WikiGnomes" which I use and like, but I have a funny feeling it might not play well outside of the Wikipedia community. (Of course, if we called admins "sysops" then saying that non-sysops are "administrators" doesn't imply that they have any kind of special powers. But, there are good reasons why we shouldn't call admins sysops!) —Tom Morris (talk) 09:06, 20 December 2011 (UTC)
• There should be more emphasis on building an encyclopedia. Everything on the syllabus is worthwhile for an administrator, but the students should actually know how to build an article as well. If they cannot do this there is not a chance that they would survive a WP:RFA. For a Wikipedia maintenance person (gnome) you should also introduce categories, interwikis, stubs, use of templates, different forums for help and problems, and projects such as WP:AFC WPBiography and the more specialised projects. Also article recognition and grading such as WP:DYK WP:good article and WP:featured article should be covered. Graeme Bartlett (talk) 10:46, 20 December 2011 (UTC)
• I'm broadly supportive of this: an introduction to Wikipedia's culture and policies would be a valuable course. In particular, there are a number of skills that are secondary to editing Wikipedia that nonetheless are highly applicable elsewhere that might be useful to include in a university course, such as the basics of copyright (and free licenses), or perhaps some rough ethical considerations on things like articles concerning living persons or editing with a conflict of interest,. I share some of Bibliomaniac15's concerns: a course with the implicit goal of adminship has a significant chance of giving contributors a fast rise followed by a quick burn-out. People see the "carrot", the implicit power of the admin position, but don't understand the reality that it is a position highly constrained by the community's agreements on how that power may be used, that it is a position whose purpose is often more "janitorial" than "administrative". People who succeed long-term in this role do so in part because they personally care about the project, and are willing to ignore insults and worse to help out. I'd like to help with your project regardless, but I think that you need to be extremely clear at the outset of the course about "the mop". {{Nihiltres|talk|edits|⚡}} 15:12, 20 December 2011 (UTC)

"basic admin tasks like... New page patrol (will introduce themselves to the community first) Recent-change patrol (will introduce ...) Review images for copyright issues (will introduce...)" But these aren't admin tasks. These are tasks any editor can do. Are you trying to discuss the tools admins have (blocking, locking, deleted/restoring, editing certain pages) or just non-article writing tasks that everyone can do? Rmhermen (talk) 02:14, 21 December 2011 (UTC)

• These aren't specifically admin tasks, but they introduce the concepts that admins need to be familiar with and are often the types of work people are required to do before successful completion of an RFA. Before taking on speedy deletions, contributors need to verify an understanding of what constitutes an unacceptable article or image; before blocking vandals, contributors need to demonstrate an understanding of vandalism and the best approaches to unproductive changes. These are among the tasks that an admin trainee might be put to do. I'm not sure myself how anybody could otherwise learn how to be an admin on Wikipedia without actually being an admin, although interviewing existing admins seems a good idea. Otherwise, the only way I can think to give them a taste of adminship is to set them up on a mock wiki and let them have it. It would be good practice with the tools, but there's no way that they could replicate our culture, unless a bunch of us followed along and tried to replicate our controlled chaos. :) --Maggie Dennis (WMF) (talk) 13:32, 21 December 2011 (UTC)

• Per Rmhermen, you're suggesting a course in social-media oversight editing. There's nothing wrong with that, but it doesn't require an admin bit; especially where wikipedia offers WP:AIV WP:ANI and the entire variety of disciplinary systems that depend on quality reporting of issues. Bit holders are just our drudges. More could be got out of protecting a day's Featured Article than by bit hunting. The final dot point would break ethics laws and expectations of professional conduct from teaching academics where I live; your professional and legal obligations may vary. Also, your course content seems kind of sparse if this is a 36 hour face to face contact / 120 hour total learning obligation course. It omits some elements of social-media oversight, like content evaluation (quality & importance rating, peer review, GAN, A-class review, FAC). It also seems a bit overbalanced towards "whack-a-mole" moderating, as opposed to community culture building. Fifelfoo (talk) 02:50, 21 December 2011 (UTC)

Thanks for your comments thus far. I'll respond to the ones that stand out:

• "It's great to have the backlogs reduced, but doing so in an incompetent manner is counterproductive."

- I don't consider myself an expert Wikipedian, but I've been working with and studying the community for a year now. I feel prepared to make this next step. Remember that this will be an experiment, and I think something worth trying. Let's be optimistic! BTW, I'm aware of the concerns that have been raised in Canada and the US, and they generally have to do with professors not devoting enough time to connecting their classes to WP. This will not be a problem with my class. The problems in India have to do generally with copyright violations from what I've heard, again, something that you won't have to worry about with me.

• "Calling Wikipedia "most popular social media/networking sites" is cause for concern."

- Wikis are social networks in my opinion (Facebook and Twitter offer two of many variations), and I know a large number of communication scholars that would agree. Sorry, the Wikipedia community doesn't have the final say here. If interested in this issue, I would check out some of the work by danah boyd and Nicole Ellison on the topic.

• "Given that people are likely to get a bit tetchy about this, and given that students might get the wrong idea and go around claiming they are now Wikipedia administrators because they do new page patrolling, I'd leave off the word "admin"."

- Students will not be considered admins at the end of the course, nor will they believe that they have met the qualifications. The purpose of the course is to teach students about being a WP admin, what it means to be a Wikipedia administrator (and perhaps an expert Wikipedian), among other things.

• "There should be more emphasis on building an encyclopedia"

- Students will learn how to edit in this course. This will be the first topic that we cover, along with how to connect to the social network. - BTW, I could use some help with the latter ... can people suggest a variety of spots on WP where my students can introduce themselves?

• "a course with the implicit goal of adminship has a significant chance of giving contributors a fast rise followed by a quick burn-out"

- Again, the goal is not achieving admin status, but rather, learning about the admin system, policies, structure, culture, etc. These are communication students who want to learn about you and what you do on Wikipedia. The community fascinates us, we want to learn. If students choose to pursue adminship, they will have to get editing. They will not have the opportunity to complete 5000 edits as a part of the course, so they'll have to follow-up once the course is finished.

• ""basic admin tasks like... New page patrol (will introduce themselves to the community first) Recent-change patrol (will introduce ...) Review images for copyright issues (will introduce...)" But these aren't admin tasks."

- This course is an introduction to the admin process and structure on WP. In my opinion, administration of WP goes beyond the "access granted" duties allowed to official admins. Students will learn about these "access granted" duties hopefully from some admins that are generous enough to help us out (perhaps by speaking with some of our students) ... and also about some of the "admin" tasks completed by the community in general. Perhaps I have to rethink some of the terminology.

• Are you trying to discuss the tools admins have (blocking, locking, deleted/restoring, editing certain pages)

- Definitely. If people are willing to help out with this, we would be very appreciative. Below I'm going to ask if people are interested in being interviewed by our students. Perhaps a few of you might be interested in skyping into our class to talk about your experiences?

• "The final dot point would break ethics laws and expectations of professional conduct from teaching academics where I live"

- I assume this refers to our conducting of interviews? Our students will all have passed IRB (ethics review) before conducting the interviews, which will be both voluntary and anonymous. While your pseudonyms may be provided on a list, students will be randomly assigned to interviews, and no names or information that will identify you will be noted in their work.

• "Also, your course content seems kind of sparse"

- All suggestions are welcome. This is one of the reasons that I posted this note. This will also be an experiment. I expect to make mistakes ... and will learn from them! Thanks so much for your comments and feedback. Please offer more if interested! Jaobar (talk) 06:28, 21 December 2011 (UTC)

About looking for spots for people to introduce themselves, may I suggest getting your students to leave notes on WikiProject talk pages? While there are no real spaces for editors to have a conversation that's not related to the encyclopaedia in some way, WikiProjects will in general be very happy to welcome new users, and only too happy to point them in the direction of work that needs doing. You could maybe get your students to look at the WikiProject Council directory and choose something that they like. Note also that there are many WikiProjects that deal with Wikipedia maintenance and systems, which might be useful for the course. Oh, and there's always the Department of Fun ;) — Mr. Stradivarius ^♫ 09:25, 21 December 2011 (UTC)

Students, the scholarly community and the Wikipedia community have different definitions of social network, and I suspect the student definition is similar to ours. We tend to delete facebook-like crap with little (if any) mercy and posting such nonsense has adverse consequences. I suggest you make it clear to anyone who is going to edit that Wikipedia, as far as they are concerned, is not a social networking site. MER-C 13:11, 21 December 2011 (UTC)

Yes, while from an academic standpoint Wikipedia may be a "social network", from a practical, how-we-do-things-here standpoint, it most certainly is not. One of the first items that the course curriculum should focus on is what Wikipedia is not. From the recent, shall we say, "difficulties" in the Canada program, it is clear that the differences between writing academic papers and encylcopedia articles must be hammered home right at the beginning. Let's not encourage students to run before they can walk. – ukexpat (talk) 15:59, 21 December 2011 (UTC)

I would avoid all notions that this course is intended to teach people how to become Admins or prepare them for adminship. I used to be very active in Admin Coaching and still find it amazing that the community doesn't respect coaching. But it doesn't. Wikipedia frown upon admin coaching and people who underwent it were actually criticized and opposed because they were 'taught how to pass an RfA not to be better wikipedians.' A notion I disagreed with, but alas that view killed wikipedia admin coaching. Also, one of the issues that hurt coaching was that some coaches had check the box issues that they wanted their coachees to do. "Go tag x articles for speedy deletion", "Go patrol x number of new articles", "Go welcome X number of users", "Go participate in x number of XfD's", etc. What ended up happening is that people with little knowledge/interest in specific tasks went in and made their contributions to fullfill the coaches expectations and disappeared. They didn't learn anything and often created more controversy/issue than it was worth.---Balloonman ^{Poppa Balloon} 22:36, 21 December 2011 (UTC)

There's an RfC on eliminating {{Portal box}} and just using {{Portal}}]]. I'm spamming it here because it's redundant and is currently a highly visible template. --Kumioko (talk) 20:30, 21 December 2011 (UTC)

Isn't the normal thing to do just to tag them with {{tfm}} and then add an entry at WP:TFD? -- WOSlinker (talk) 20:35, 21 December 2011 (UTC)

Your right and I thought about doing that but since its used on over 40, 000 articles I hesitated doing that. If you think that venue would be better suited for this discussion its completely fine with me. --Kumioko (talk) 20:54, 21 December 2011 (UTC)

There should be an option to not watchlist by default pages in a certain namespace. For example, I have enabled watchlisting by default as it is very convenient, but I try to keep my watchlist below 600-700 pages at any given time. It's fairly tedious to do, because everytime I edit a WT:AFC page, block a user, or leave a message to a user talk page, the page is watchlisted. I would like a feature that enables automatic watchlisting only for specific namespaces. This also addresses the above proposal on separating pages from their talk pages (e.g. WT from WP, etc). Any support for this? — Preceding unsigned comment added by CharlieEchoTango (talk • contribs) 06:22, 8 December 2011 (UTC)‎

• Oppose due to this being potentially a pain in the rear end. I can imagine too many occasions when I would have to override the exclusion of a particular namespace manually. This proposed feature would actually more than likely cause the very issues being cited as reasons to oppose the above proposal to be able to un-watch talk and other pages etc. etc. In particular the potential to forget to watch and to think that you are when you're not seems rather strong. With the other proposal, the normal behaviour (we have now) would have to be manually undone on a per page basis, meaning the likelihood of forgetting is significantly reduced (to basically zero). Simply speaking: I wouldn't want to automatically not watch all (for example) talk pages, since more often than not I want to watch both the talk and main (just occasionally not both). Blanket exclusion of a particular namespace from being auto watched is too harsh for my liking. fredgandt 09:16, 8 December 2011 (UTC)
• Support. Anything that helps customization of autowatch would be useful. I wouldn't expect most users to use it, but I don't think it would hurt. I think a prototype of this could potentially be implemented in pure Javascript, and then anyone who wants to try it out can just include it. Dcoetzee 09:54, 8 December 2011 (UTC)
• Support as an opt in with the suggestion that it be made a "gadgets" feature - I wouldn't use this, but I understand how it could be useful. If it isn't possible to do opt-in, the simple alliterative would be to have autowatchlisitng on for all namespaces or for none of them, creating results identical to the two options we have now. Sven Manguard Wha? 10:43, 8 December 2011 (UTC)
• Comment: I would certainly think that an admin who blocks a user should, for at least a reasonable time, have that user's talk page in his watch list. I would also expect this if you leave a message. Communication is two-way. If you initiate it, you have the obligation to be reasonably attentive to replies. --Stephan Schulz (talk) 11:59, 8 December 2011 (UTC)
  • Note that for some users like myself, I currently have autowatch disabled (because I make minor changes to many articles) but would be more likely to enable it for the User talk namespace, for precisely that reason. So your argument seems to actually favor the proposal. Dcoetzee 13:12, 8 December 2011 (UTC)
    • Yes, this is a two-headed snake, which is why I put it in as a comment, not a !vote. --Stephan Schulz (talk) 15:02, 8 December 2011 (UTC)
  • Well, my message wasn't very well worded, heck, wasn't even signed, of course I keep the page on my watchlist when I leave an open-ended message, what I'm referring to is mostly related to script sent messages on user talk pages; e.g. welcomes, "Your submission at AfC was created", user warnings, CSD notices, etc. No point in watching most of the time and it grows very quickly to an unmanageable (for me) watchlist. I get your point on communications, but I also see no point in keeping hundreds of declined AfCs or various WP pages (like this one). Removing them manually every other week is tedious. Regards, CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)
    • I suspect this will get lost, but it reminds me of a feature I would like, the ability to watchlist a page, with the watchlist expiring after a month or so. Perfect for this situation and many others--SPhilbrickT 15:58, 14 December 2011 (UTC)

Yes please! -- John of Reading (talk) 16:02, 14 December 2011 (UTC)

Yes, that's something I also would like to see. Toshio Yamaguchi (talk) 16:18, 14 December 2011 (UTC)

A biodegradable watch of a page? So after n time it auto un-watches? Yep, I'd go for that. As long as it was something that could be selected on a per page basis and was not default behaviour. Perhaps this should be separately proposed. fredgandt 18:07, 14 December 2011 (UTC)

• Opppose You could do this with a simple user script. And I echo Stephan Schulz's comment above. Anomie⚔ 12:05, 8 December 2011 (UTC)
  • Which script? CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)

if (wgAction == "edit" && [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 100, 101, 108, 109].indexOf(wgNamespaceNumber) != -1) { 
    document.getElementById('wpWatchthis').checked = true;
}

• Customize the numbers in the list as needed; namespace numbers in the list will be auto-watched if you add this to your user JavaScript page. For a namespace-number-to-English guide, see Wikipedia:Namespace#Programming. Numbers -2 and -1 need not be added as you probably won't be editing in those namespaces. {{Nihiltres|talk|edits|⚡}} 16:00, 8 December 2011 (UTC)

• Well this would certainly solve my problem, thanks! I added it to my User:CharlieEchoTango/common.js, but it doesn't seem to work. Purged the cache, logged out logged in, tested on two namespaces. :/ CharlieEchoTango (contact) 16:14, 8 December 2011 (UTC)

• Nevermind, I had to disable automatic watchlisting first. Silly me. Thanks a lot, Nihiltres. :-) CharlieEchoTango (contact) 16:20, 8 December 2011 (UTC)

• It seems to watchlist the associated talk namespace regardless of the script (e.g. if I choose to watch ns4, ns5 is included with it even if left out in the script). Not a big deal, though. CharlieEchoTango (contact) 16:33, 8 December 2011 (UTC)

• That's inherent to the watchlist feature. If you watch a page, you also necessarily watch the associated talk page or content page. My script merely chooses which namespaces will have auto-watch enabled: it might make sense to auto-watchlist page pairs when you edit a talk page, but not when you just edit content. {{Nihiltres|talk|edits|⚡}} 16:50, 8 December 2011 (UTC)

(Note that the above script will not work in IE7< due to lack of indexOf support.) --Yair rand (talk) 01:18, 23 December 2011 (UTC)

• Support as an option that should probably be available by default, but I'll otherwise make my above 30-second script into a more user-friendly Gadget as soon as Gadget preferences are available (hopefully, an upcoming feature). {{Nihiltres|talk|edits|⚡}} 16:10, 8 December 2011 (UTC)
• Support with comment - I don't see that this would be a bad thing as long as its opt in and not required. I think that there is a lot of room for improvement in the way Wikipedia handles Watchlists and any functionality that allows users some flexibility in it is helpful. --Kumioko (talk) 16:14, 8 December 2011 (UTC)
• Oppose I do not see the need for such a feature. When the 'Add pages I edit to my watchlist' feature is enabled, you can just uncheck the 'Watch this page' checkbox above the 'Save page', 'Show preview' and 'Show changes' buttons. Toshio Yamaguchi (talk) 17:43, 10 December 2011 (UTC)
• Support I also agree with an opt in comment, as not every user (including myself) are user script literate. Only a few are, and I agree that so many articles I tagged for deletions, users I warned and so forth gets automatically watchlisted and removing it can be a pain. Secret ^account 06:29, 13 December 2011 (UTC)
  • This proposal would offer you the opportunity to not watch any talk pages or all; any articles or all. Are you really sure that will be helpful? fredgandt 06:59, 13 December 2011 (UTC)
• Comment Some people here might find user:js/watchlist useful. It's fairly easy to install and to use in my opinion (see instructions on that page) . I have it installed, since I also have "Add pages I edit to my watchlist" enabled (hell I would miss a whole lot of stuff if I hadn't) and it makes killing unwanted pages popping up on your watchlist mostly painless. Toshio Yamaguchi (talk) 22:58, 14 December 2011 (UTC)
• Support Per Sven Manguard. Rcsprinter (state the obvious (or not)) 20:36, 16 December 2011 (UTC)