This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
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)
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)
Binding RFCs
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, StevenZhangJoin the DR army!01:07, 2 December 2011 (UTC)
Proposal to take the "File namespace noticeboard" live
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Hi there. I'd like to get some additional consensus for this board before taking it live. Once it's taken live, I would like for it to be linked to in the "Noticeboards and related pages" template that is at the top of many of the noticeboards, (it's the big one at the top of AN, AN/I, and this proposed page, among others. Sven ManguardWha?11:31, 12 November 2011 (UTC)
The following comments were from Village pump (idea lab). This was moved after interest was expressed for it going ahead.
No. In theory these things would move over, gradually until the FNN becomes known. This would reduce effort for the file workers, because we'd have one primary center for all the threads that concern file issues, instead of having them spread out over AN, VP:P, VP:M, CENT, etc.. Sven ManguardWha?12:16, 11 November 2011 (UTC)
It's a great project that suffers, unfortunately, from poor publicity. I spent a year working in files before finding out that the project existed. Also, it's great for planning projects and has an excellent cache of resources, but it really isn't the place to hold major RfCs, for that a noticeboard that's linked to the directory, and isn't attached to any specific body (such as a WikiProject). Sven ManguardWha?09:23, 12 November 2011 (UTC)
I think the general idea makes sense (viz. centralizing general file issues that are not about a specific file), and the exact header can be tweaked and refined later / through discussion. Chzz ► 00:00, 12 November 2011 (UTC)
I also think this is a good idea as it will centralize debates and permit longer, less structured discussions then at IFD. MBisanztalk03:49, 12 November 2011 (UTC)
Question: do you have some example problems that were not handled either at all, or not well, by current venues? I have a certain scepticism about new boards, any examples would be helpful. Grandiose(me, talk, contribs) 09:56, 13 November 2011 (UTC)
Ebe123 I know he was referring to the group that works in files, but I consider myself part of the group, and very much like the name. Beats "file workers", which is what I usually refer to us as. Sven ManguardWha?07:20, 20 November 2011 (UTC)
Since you're in an RfA, and therefore any attempts at humor can and will be used against you, I'd really love to hear what you have on your mind for a name, but after the RfA is over. Sven ManguardWha?18:53, 26 November 2011 (UTC)
Support As a fileworker myself, I feel that this board would be very useful and helpful in mine and others work, and may even raise participation in file namespace related tasks. Acather96 (talk) 08:11, 26 November 2011 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Current Events reformation
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). fredgandt18: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 doktorbwordsdeeds12:15, 4 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.
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)talk01: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.--SPhilbrickT16: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‑melon00: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)
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)
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)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I suggest that in much the same way that all lot of country articles (imo it should be all country articles) have a sound file of their national anthems in their infoboxes (e.g United States, all TV shows should have a sound file of their theme song in their infobox. I know a lot of them already do have a file somewhere in the article, but I think it would be better this way. Yes, there already are sections dedicated to the theme in the respective articles already, but underneath the file, it will state the name of the theme, which will be bluelinked, and will link to the respective paragraph/article about the theme, in the same way that below the USA article, it has a blue-linked "The Star-Spangled Banner"--Coin945 (talk) 08:05, 2 December 2011 (UTC)
Except that the Star-Spangled banner is in the public domain, and all TV-show themes are copyrighted. How would we be able to host such recordings? Qwyrxian (talk) 08:09, 2 December 2011 (UTC)
Wouldn't it count as promotional material? Even if it doesn't, all copyrighted sound clips on wikipedia are 30 seconds or less. I can think of no theme (at least the way it is presented during the show) that is longer than 30 second. Therefore it shouldnt breech copyright anymore that the other clips.--Coin945 (talk) 08:11, 2 December 2011 (UTC)
There is in fact no such concept. Using a .3, 3, 30, or 300-second clip is identical under copyright laws. It is a weird urban legend that sampling under a given length is legal. → ROUX₪08:36, 2 December 2011 (UTC)
I think there is some confusion, possibly we have an upper limit of 30 seconds of audio as a pragmatic aid to complying with fair use. As to absolute length of a sample, there is, as you say, no distinction, although shorter excerpts are more likely to comply with fair use, the concept of short is related in part to the length of the whole work. RichFarmbrough, 23:37, 2 December 2011 (UTC).
If by 'entirely political' you mean 'entirely legal as in WMF doesn't want to get sued for copyright infringement,' yes. Otherwise no. → ROUX₪08:36, 2 December 2011 (UTC)
I kind of meant "policial" or "a matter of polity" but am occasionally lazy, dim-witted and/or imprecise. I try to use exactly the right words where and when i can, but sometimes it goes horribly wrong. I must be human. fredgandt09:00, 2 December 2011 (UTC)
In any case, I think I'll restate my proposal along with other comments on the policy pump.
I was just looking around Wikimedia commons and suggest that if you wanted to start anywhere it might be there. The available sound files are spread wide and in places thin. See mw:Category:Ogg_files_of_music for just one sub-category of another and another, with sub-categories of its own. Some end-of-line categories have only one file in them, while others have hundreds of relatively unrelated files (kind of defeats the object of categorization). Sorting out the files available would at least put you in a position of knowing what was already available. Then you could add those that weren't already used, and more easily know which others to track free-to-use versions/copies of. Without the mind numbing clerical stuff and the end resulting collection, there is little can be done. As for the base idea of having theme tune files in the info box (where available), I'm sure that would be quite simply organized. fredgandt09:00, 2 December 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
A heretical idea: "closing articles"
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. NoleloverTalk·Contribs15: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)
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. NoleloverTalk·Contribs17: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)
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. --JaGatalk16: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)
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? doktorbwordsdeeds17: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. --Jayron3218: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. --PhilosopherLet 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'... NoleloverTalk·Contribs13: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. --PhilosopherLet us reason together.08:42, 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. NoleloverTalk·Contribs21:18, 20 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)
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?
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. fg23: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)
Amendment to the proposal
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)
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.
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. NoleloverTalk·Contribs16: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! fg18: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,855,370 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!! fg18: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 reasonabletonot even a stub, and take it from there. This way would at least prevent forgotten articles fading away through lack of active guardianship. fg21:59, 18 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. RichFarmbrough, 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)
Istrongly 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. Falconusptc12:27, 5 December 2011 (UTC)
Stable version and article milestones
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:
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. Falconusptc19:55, 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)
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.
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.
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. RichFarmbrough, 15:22, 30 November 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. Crazynast06:15, 7 December 2011 (UTC)
Add "Mark as read" to watchlist
I think these changes would make the editors' lifes easier:
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.
Automatically mark read all the changes prior to the editor's own last edit on per entry basis.
Add an ability to sort watchlist on entries (as opposed to a single timeline).
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 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. fredgandt11: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.
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)
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)
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. fredgandt09:57, 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. fredgandt13: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. fredgandt14:00, 2 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.
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. MastCellTalk23: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. --JaGatalk04:15, 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… --Ludwigs215: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. Dcoetzee07: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)
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)
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. fredgandt07:06, 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)
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! --Chris02: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 ManguardWha?10:50, 8 December 2011 (UTC)
Proposal for a "Names for discussion" section
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)
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)
Darowizna -> tu ułatwienie w przekazaniu środków... (en "Donation -> here to facilitate the transfer of funds ...")
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)
"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." fredgandt01:11, 10 December 2011 (UTC)
"Blocked" template tweak
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Hi according to previous discussions about the archiving of talk pages of ip users, based on Chzz's suggestions I created an extension for mediawiki which allows creation of template which automatically change its content when user is unblocked, so that we could have templates which don't confuse especially new users who are using shared ip address, were blocked in past but don't understand that they were already unblocked, this extension is now installed on huggle test wp. If you need any detailed technical informations about it, let me know. Please let me know what do you think about it, if you support the idea, or have some comments how to improve this. Petrb (talk) 08:59, 12 November 2011 (UTC)
Isn't that irrelevant? we do more tests there, I am mediawiki dev, so there are some more extensions being checked, it's latest head from svn, so it seems that it's a bug (I started reviewing cu source for now to fix that), anyway if it's a problem I will disable cu there, so that you can try that tool I am talking about here, your ip address wouldn't be recorded if you just open the link I sent here (you would probably have to make some edits), but I will probably clean cu table after tests anyway. Petrb (talk) 10:36, 13 November 2011 (UTC)
If you wanted help with that, I could insert some more magic to this extension you could probably use for that ;) Petrb (talk) 20:40, 16 November 2011 (UTC)
Comment since this is a very simple extension it's quite possible that it could get deployed soon (if there was some support), so I would like to know if you wanted to change anything with that before that happens, Chzz suggested that it could return even the time when block expires so that template can show that, what do you think? is it necessary? Petrb (talk) 03:06, 15 November 2011 (UTC)
Support the simple change - giving true/false for user blocked; it's easy enough info for anyone to see (e.g. under 'contribs' which would show the latest block-log entry), but having it as a magic-word helps templates be smarter. It seems easy enough, so why not? I'd suggest keep-it-simple, and not worry about date/other data. Chzz ► 09:21, 17 November 2011 (UTC)
Template magic could do a lot of this, especially if people are using tools to block. Something like {{Blocked|2011-11-18 23:22|3 hours}}RichFarmbrough, 02:08, 19 November 2011 (UTC).
Comment I think it would be better if the image were different when the block had expired (e.g. a pink X, or a translucent X, or something), so that it would be immediately obvious what the situation was without having to read the template. Because new users might not even be aware that the template changes at all and so might just see the obvious warning image and assume it meant "blocked", or only read it once (when the block was active, say) and not bother re-reading. It Is Me Heret / c13:14, 23 November 2011 (UTC)
Absolutely! I expected someone else to take care of that - and the detailed wording! Let me spend a few minutes on it though. RichFarmbrough, 15:34, 25 November 2011 (UTC).
Possible issue I'm concerned that a magic word like {{USERBLOCKED}} would be difficult in quite a lot of cases:
Users may be blocked under more than one IPs, or IP ranges for example, or under a usual and alternate account (legit or socked). :# It would need thought whether a template based on "the IP/account who !owns this user page/user talk page is blocked" would cover IP users, dynamic IP users, users who edit as a username and as an IP.
It is meaningless in some namespaces, not a problem per se but needs considering in design.
It also needs thought whether it exposes Checkuser data and breaches privacy. If I want to check if user X is the same user as IP Y.Y.Y.Y, would I be able to post this template on User:XorUser:Y.Y.Y.Y a minute before the block on one of these expires, or when the user is blocked, and see if its status is in sync with the block on the other? What about autoblock collisions?
Actually it works only in userspace or talk, otherwise it return word unknown concerning the templates which works automaticaly with timestamp, it's good idea but they also have some issues, for instance if someone unblock the user before it expired, it wouldn't work, also it can't replace existing templates, and it's harder to submit such templates for sysops. I don't see any possible security or technical problems, it detects if user is blocked directly from User class in mediawiki, so there are no colissions or such issues. Actually I also heard idea to implement this to mediawiki core (from wmf dev) Petrb (talk) 09:12, 21 November 2011 (UTC)
Support: I like the ground idea. The system is to static and confuses simply too many unexperienced users and the whole system is hard to understand. Such small improvements do make it much more easier to understand! mabdul11:35, 30 November 2011 (UTC)
Support the underlying idea. Hopefully the code-heads can make it work, and hopefully the next software update won't break it again. Beeblebrox (talk) 16:10, 5 December 2011 (UTC)
Support. Great idea. This gives us the flexibility to retain a visible record on talk pages that users were blocked in the past, while avoiding the misleading impression that the user is currently blocked. As a small improvement, I'd like to see a template added automatically when a user is blocked, so that usage is consistent. Dcoetzee12:13, 8 December 2011 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Creation of new namespace for automatically substituted templates
Proposal to create a new namespace. Suggest TemplateS:
Any template created in this namespace would automatically substitute when saved.
Ifsubst:orsafesubst: 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. fredgandt20: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|talk21:17, 9 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:ExampleorExampleorWikipedia: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). fredgandt21:54, 9 December 2011 (UTC)
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.).
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.
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.
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. Monty84517:39, 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 | Talk17: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)
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.
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. fredgandt21: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)
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. fredgandt21:20, 11 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. fredgandt11: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)talk11: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)talk18: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. fredgandt18:11, 12 December 2011 (UTC)
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)
Insert-able edit points without creating a new section
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).
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.
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:
[Edit]
This section, with header "==== [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? -Wikid7718:18, 6 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. Dcoetzee09: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. fredgandt09: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)
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. Rd232talk13: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. Rd232talk19:39, 4 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. Falconusptc11: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. fredgandt20:36, 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. fredgandt19: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)
End of EDITPOINT thread
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. -Wikid7714:03, 6 December 2011 (UTC)
Grafting the external links numbering mechanic onto IP signatures
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 nth 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(1) (talk) 14:56, 12 December 2011 (UTC)
Comment 2. 9.01.234.56(2) (talk) 14:56, 12 December 2011 (UTC)
Comment 2a. 1.23.456.78(1) (talk) 14:56, 12 December 2011 (UTC)
Comment 3. 7.89.012.34(3) (talk) 14:56, 12 December 2011 (UTC)
Comment 3a. 9.01.234.56(2) (talk) 14:56, 12 December 2011 (UTC)
Comment 3b. 1.23.456.87(4) (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 Heret / c14: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)
The proposer is presumably thinking of citation links, which can be made to repeat numbers, but which involves quite a bit of overhead. --erachimatalk18:30, 12 December 2011 (UTC)
A discussion is opened about the proposed deletion of an article (or template etc). This will be listed in the deletion log of the day it is raised. The deletion log for this day can be found by clicking on today in the Deletion discussions box (example right).
The discussion is then open for a week, during which time it cannot be accessed through the Deletion discussions box (although links to the deletion log can be found under Wikipedia:Articles for deletion#Current discussions).
Seven days after the discussion was started, the deletion log can be accessed by clicking on closing in the Deletion discussions box. Usually, at some stage during this day, an admin will close the discussion.
However, if there have been no real contributions to the discussion, the admin will relist it and it will be moved to the current day's deletion log and the process starts again. This can happen twice (possibly more) before the AfD is retired.
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 todayorclosing, 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. --PhilosopherLet 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. UltraExactZZSaid~ Did20: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)
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)
Making Special:Protectedtitles a restricted special page
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 Heret / c10: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 Mishehu16: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 Heret / c17: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 Mishehu20:04, 13 December 2011 (UTC)
It was worth a shot, but this proposal obviously won't succeed. Rather than engendering further controversy, let's focus our attention on formulating a plan to enact at a later point in time (should the situation call for it). —David Levy02:04, 15 December 2011 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm not sure what the state of play with the proposed shutdown of WP is. It looks like we will probably do nothing. But this is a last-ditch attempt at a concrete proposal. Please note that there is not much time left for fine detail, so please oppose this if you oppose the idea of a protest. If you support the idea of a protest but have quibbles about exactly how to do it, quibbling may well mean no clear consensus so nothing happens. Apologies but I will not be around for much of the discussion. Amend and tweak in good faith as you will.
I also have no knowledge about whether this will be technically do-able at short notice, so apologies if the RfC succeeds but still nothing happens.
English Wikipedia articles will be made inaccessible to everyone geolocate-able to the United States from one minute past midnight EST on Thursday to midnight PST on Thursday.
The Wikipedia homepage will either stay as it is or consist of something appropriate to the action being taken, as decided by community consensus. Attempts to reach a particular page on en.wp will result in a redirect back to the homepage.
The lockout will apply to all readers and editors in the US except those who are absolutely needed for technical purposes.
Users outside the United States are encouraged to support the "strike" by not editing during it, except to undo vandalism.
Comment I would point out that RFCs customarily run a month. In a matter of such moment, how would it be fair to decide this based on whoever votes in the next four hours? I would say that would be very ill advised.--Wehwalt (talk) 00:44, 15 December 2011 (UTC)
Its a good point; but, this is the best effort at process that can be made given the limits of the community's neglect of processes for snap actions and/or the threat of this law to it. It is an attempt more in line with process than private consensus building attempts that appear to have no actionable component. Fifelfoo (talk) 00:50, 15 December 2011 (UTC)
It's past midnight in the UK. Generally, in societies where people's rights are valued, sneaking things through in the middle of the night is disfavored. While their access, of course, would not be blocked, for certain they might have something to say about the politicization of this website. As might those Americans and Canadians who only edit during the day.--Wehwalt (talk) 01:05, 15 December 2011 (UTC)
This is an excellent reason to argue that this RfC not be abnormally closed, or abnormally closed early. I notified WP:AN/I of this RfC, and suggest that you restate this point there as well. Despite supporting this RfC, I support your argument that it not be abnormally closed, and will make this point at AN/I myself right now. Fifelfoo (talk) 01:14, 15 December 2011 (UTC)
Support. I support the en.wikipedia taking action where another body poses a serious threat to the encyclopaedic process; but, where our action does not compromise our responsibility as encyclopaedists by altering content. Given the timeframe, this "snap action" combines a symbolic representation of outrage, with a real economic threat presented by locking out US geolocated users and by forming a moral picket against use of the encyclopaedia amongst non-US users. It is far more strategic than either an indefinite withdrawal of service, or a purely symbolic advertisement. This balance represents the broad balance of a consensus building straw poll on a well trafficed user page. This gives us "currency" and would allow us time to make a more considered action or inaction decision after the highly time critical element of the US state's process has occurred. Fifelfoo (talk) 00:50, 15 December 2011 (UTC)
Comment. If the proposal goes through it has my moral support. However I am uneasy about the precedent. Until now, as far as I'm aware, English Wikipedia has never taken an explicit political stand on anything. If we do it once, will the next one seem like something all right-thinking people should agree with, but it's less directly connected with our mission? And then the one after that maybe I don't agree with? If this is adopted I think it needs to be with the clear understanding that it does not open the floodgates to political action on WP's part on just any issue where say 80% of editors happen to be on the same side; it's an exceptional action that should be taken only when the legislation is a direct threat to the encyclopedia as such. --Trovatore (talk) 01:03, 15 December 2011 (UTC)
Support, but the only realistic way this is going to happen in the required timeframe is bold action by Jimbo Wales, not through an RfC. He had his informal poll, for what it's worth; not ideal, but certainly an indication of where the community stands. CharlieEchoTango (contact) 01:07, 15 December 2011 (UTC)
Support. Replace the main page with an explanatory message and point all pages to it (or something comparable). And just as the French Wikipedia's strike wasn't restricted to France, I don't believe that this one should be restricted to the United States (given the fact that the proposed legislation stands to affect readers around the world). If that's a sticking point, however, a U.S.-only protest is better than nothing. —David Levy01:09, 15 December 2011 (UTC)
Oppose until we get a wider and more authoritateve consensus than can come from the relatively few who watch VP and respond to a day's notice. For example, a week's worth of replies to a banner replacing the money-begging ones.Jim.henderson (talk) 01:12, 15 December 2011 (UTC)
A strong body, much influenced from the web, to discuss the matter further. A shutdown now was never proposed, discussed or supported. --Errant(chat!)01:17, 15 December 2011 (UTC)
Oppose. Time to take a deep breath. Let Jimbo and the WMF decide how they want to communicate with the US government. No one in the government is going to shut us down in the next few days, so we don't need to over-react. Jimbo said very clearly on his talk that any actual shutdown would require thorough evaluation and consensus by the community. That's going to take some time. --Tryptofish (talk) 01:14, 15 December 2011 (UTC)
I guess I should support as OP. And add a request for the closer to consider in conjunction with the discussion on Jimbo's talkpage. --FormerIP (talk) 01:16, 15 December 2011 (UTC)
Oppose; if consensus is to lockdown we need to a) write a proper notice to explain the action to our users (otherwise the event is pointless) b) estalish proper media coverage (or the event is useless - simply reporting us being down is useless if there is no organised media response) c) confusing. Rushing it through in a few hours with probably minimal input is also problematic. (FWIW I don't think it is technically possible to implement a US geolocated lockdown with any tools available to admins - unless we find a way to hack geonotices). If the community is in favour of a shutdown, fine. But we need to do it properly, with (as Jimbo said), careful discusion as to options. This can only hurt our cause. --Errant(chat!)01:17, 15 December 2011 (UTC)
Oppose - With respect, this RfC is pointless. Jimbo has had plenty of response on his talk page, and if he intends to play god with the site, he will do so regardless of this RfC. (I would also note that we do have a process for things that require "snap action": WP:BOLD.) If this RfC is felt to be required because the discussion at Jimbo's has not yielded a firm consensus, then we already have the answer. Giving 3-4 hours for the few people who are on right now, and read this page to determine the ability of everyone to edit and read would be a complete farce. I might be in favour of blanking the main page only, but at this point, it is too late for the community to achieve a legitimate consensus on shutting the entire site down at midnight EST. Resolute01:18, 15 December 2011 (UTC)
The discussion on Jimbo's talk page has yielded a firm consensus, but it explicitly wasn't intended to determine a specific implementation. —David Levy01:23, 15 December 2011 (UTC)
And there is absolutely no possible way that such an implementation could be determined in three hours. More over, the community does not have the power to shut the site down for just American users. Even if it did, to allow a couple dozen dictate something this big to the thousands who will not have even the opportunity to give input would be ridiculous. Let Jimbo and/or the foundation decide what to do, or pick another date that allows time for the entire community to weigh in. Resolute01:29, 15 December 2011 (UTC)
Those are valid points, and I agree that this proposal is unlikely to succeed. I'm merely addressing your comment regarding "the discussion at Jimbo's [possibly having] not yielded a firm consensus." —David Levy01:39, 15 December 2011 (UTC)
What kind of drafts? If you mean for the mainpage, my proposal is that anyone can draft anything, but, as a default, we just freeze it. That could actually be a more powerful message, I think. --FormerIP (talk) 01:26, 15 December 2011 (UTC)
Support. I very strongly agree with the proposal. Time and again issues like this in the US have been decided solely by legislative agenda because those of us who care - the members of a certain community, or even the whole Internet community - have raised awareness among ourselves but not enough with the general public. I feel that something on the scale of "turning off" English Wikipedia is absolutely necessary to raise the public awareness this cause needs. And make no mistake, this is an issue which can shake the Internet as we know it today to its foundation. I would furthermore suggest that, during the time English Wikipedia is disabled, site-wide headers be added to all other Wikipedia sites explaining the situation. Jantman (talk) 01:20, 15 December 2011 (UTC)
Oppose Even if all the dots were crossed and the ts dotted, this would still be an ill-advised proposal. As it is, it will set the community at each other when people realize what happened who do not edit Wikipedia incessantly.--Wehwalt (talk) 01:22, 15 December 2011 (UTC)
Strong support - (edit conflict)x2 We have never had something so directly threaten Wikipedia and basically the vast majority of the internet in the past and I feel that due to the unprecedented threat an equally unprecedented response is fully justified. Barts1a | Talk to me | Yell at me01:23, 15 December 2011 (UTC)
Oppose – The deadline for this proposal (less than four hours from when this comment is posted) is outrageous. This doesn't leave much time for the community to be involved in planning stages of this proposal. We haven't even constructed "Learn why SOPA will be bad for Wikipedia and the Internet" message that the readers will see. This proposal is being rushed through. We should at least be on the same page as Jimbo and the WMF. --Michaeldsuarez (talk) 01:25, 15 December 2011 (UTC)
As one of 47,701,320 who actually knows what this rushed mess is all about, I have to say; for a web site that prides itself on neutrality and protection of copyrights, to throw a hissy-fit and shut itself down out of fear of something that might not even happen, that might actually do some good, that might not be as bad as pundits predict even if not good, or that at worst could be undone if found to have been a bad idea, is plain bloody stupid.
Send him to the stocks You're trying to shut the site down with a six hour poll? I recognize that people aren't sanctioned for idiodic proposals, but this is ridiculous. Buddy431 (talk) 01:30, 15 December 2011 (UTC)
Moral support for the proposal, but I'm with Buddy— send him to the stocks. The previous RfC was crystal clear, and if Jimbo wants to turn off Wikipedia based on that, then he should do so by all means. But starting a "concrete proposal RfC" to supposedly determine this in only a few hours is absurd. The vast majority of users who supported this in the previous RfC may well not get to comment on this at all. SwarmX01:37, 15 December 2011 (UTC)
Strongly Oppose Isn't fair to shut down a website without a fair and reasonable proposal and at least some time to debate over it. People rely on Wikipedia on a daily basis, and doing this would be too risky. --Radiokid1010 (talk) 01:46, 15 December 2011 (UTC)
Moral support, practical oppose. If people who've looked at the current SOPA proposals think it would have a serious, deleterious effect on Wikipedia editing then a protest like this is appropriate. But it should be done with wide consensus and careful consideration to getting the most benefit. I would support a similar proposal for a temporary shutdown next week or next month. Will Bebacktalk01:47, 15 December 2011 (UTC)
Oppose. I've opposed it on Jimbo's talk page, and I'll oppose it again. Going on strike will damage Wikipedia's reputation as a neutral encyclopedia in the eyes of the global community, and it will be a betrayal of every editor who contributed with the expectation that Wikipedia would remain neutral and not become a political tool. I will not !vote for the destruction of Wikipedia's reputation, and I will not !vote for the splintering of our community and the breaching of our contributors' trust.--Slon02 (talk) 01:50, 15 December 2011 (UTC)
Oppose procedurally and substantively. Procedurally, this is completely unfair to users who live time zones where the few hours this would be open are inconvenient for editing, or who are traveling for the holidays, or who don't edit on Wednesday/Thursday. Way to go countering systemic bias. Substantively, it is inappropriate for the community to compel any user to edit or not edit to make a political point. It would also set a truly awful precedent, with unknowable consequences. If some threshold of consensus is all it takes to turn Wikipedia into an instrument of politics, then Bill O'Reilly can take over the encyclopedia if 1% of his three million nightly viewers respond to a call to register accounts. Even if nothing like that happened, Wikipedia would be permanently politicized. Every time a controversial piece of media legislation got introduced, it would be "How will Wikipedia respond?" all over the news. Lagrange61301:52, 15 December 2011 (UTC)
Meaningless RFC that should be closed and ignored. I've had meals that lasted longer than the proposed duration of this RFC. Townlake (talk) 01:56, 15 December 2011 (UTC)
Oppose on procedural grounds for reasons stated by Errant. This was never proposed to be implemented immediately and the decision to do so should not be rushed. Also opposed on substantive grounds for the reasons I stated on Jimbo's talk page. I think there is a better than 50/50 chance that if Wikipedia does this, we are going to regret it later. Many of the "votes" on Jimbo's talk page simply expressed opposition to the legislation, and I oppose it too, but that doesn't mean that this is the correct strategy to fight against it. Neutron (talk) 01:57, 15 December 2011 (UTC)
Oppose as not a meaningful process. I happen to have woken up in the middle of the night in the UK and spotted this odd discussion. It may be a hoax or perhaps just an exercise in pointiness, but I have no intention of spending time investigating as I need to get back to sleep. Please close this non-RFC as malformed. --Fæ (talk) 01:58, 15 December 2011 (UTC)
Support - If we aren't willing to stand up to a threat to our operations, then why are we contributing in the first place? I'd also point out what Jimbo, the WMF and many others have said; that Wikipedia is political by it own nature. Sharing knowledge freely and openly has always been inherently subversive and a political act throughout recorded history, including modern times. - Hydroxonium (T•C•V) 02:06, 15 December 2011 (UTC)
(edit conflict × 5)*Support - as I said at the original RfC, this is not about politics, but what is good for the encyclopedia. This bill gives control of the internet to whoever wants to spend the most money censoring it, which is the pretty much the opposite of the egalitarian and free access to knowledge this site provides. We've already had an RfC about this (and those who opposed should not ignore that they got outside votes as well), so this should really be a discussion of whether we're going to do a banner or a complete blank. Ian.thomson (talk) 02:13, 15 December 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm all for IPs being able to edit. However, with ClueBot being down there is a growing amount of vandalism and it is gettiing hard to control. I would like to sugest a tempoary suspesion of IP editing rights until ClueBot is fixed. I sugest this because the majoraty of vandalism I see is by IPs. Oddbodz (talk) 19:54, 6 December 2011 (UTC)
Support Unfortunate but true. Can't say much else due to unclean feelings of IPism and guilt. I'd prefer to feel bad than watch WP get trashed. fredgandt20:07, 6 December 2011 (UTC)
Strong Oppose - ClueBot did not rule Wikipedia and its absence should not affect the spirit of openness that we should have. Sure, vandalism is a problem, but it is not insurmountable. We must not let the vandals spoil Wikipedia for the vast numbers of well meaning IPs. See WP:HUMAN. Bazonka (talk) 20:20, 6 December 2011 (UTC)
There's nothing to debate here. It's not even a consensus issue -- the foundation wants IP editors to be allowed to edit. I normally hate killing discussions with archive boxes, but in this case it's probably a good idea. ♫ Melodia Chaconne ♫ (talk) 21:05, 6 December 2011 (UTC)
Strong oppose How is that going to stop vandalism? Vandals will simply take the extra minute to get an account. On the down side, Wikipedia will loose good content contributers. Over 60% of IP edits are good edits. Alpha_Quadrant(talk)21:10, 6 December 2011 (UTC)
Strong Oppose for the above reasons and for the fact if we go this far whats to stop peopel requesting ip ranges being blocked in the future, requesting isps be block or countries???. i have edited under ip before just because it was easier to makea quick edit that log in just fora something minor i wouldnt liek to think i need to worry about logging in evr time--Andrewcrawford (talk - contrib) 21:23, 6 December 2011 (UTC)
My personal feeling is that most vandalism is opportunism or accident. I think very few acts are thought through. Obviously some are, but that's not really what ClueBot ever dealt with. The tens of thousands of little '''boldtext''' that get dumped and left because the editor was not really sure what they were doing or were just bored are where ClueBot ruled. I am fully on the side of free editing, but 60% isn't a massive majority. Another way to view that figure is that 40% are vandals (or at least not helpful). As a temporary measure to at least calm the flow of rampant destruction (if people realise the opportunity exists for their work to be shown off for longer) by the deliberate IP vandals, it would not be truly a bad idea. Once ClueBot is back, then so could be the IP editors. I know we are all supposed to strongly oppose because the IPs are wonderful, but if you've ever watched WP:AIV, you'll know damn well that IPs far out-way logged users in the vandalism league and it takes a constant and concerted effort by many people to just keep up. fredgandt21:29, 6 December 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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 ManguardWha?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)
Bot to maintain and auto update a list
I would like to get consensus for the following bot task:
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. RichFarmbrough, 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)
"Liking " others' edits
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Oftentimes I come across edits where I think, "that's a really useful bit of editing". Little things like adding sources, tweaking grammar, tidying up section headers - gnomish things which all contribute to improving the encyclopedia, but aren't especially showy. Whilst we do have barnstars (and kittens, cookies and all sorts of other crap) to show approval for this sort of thing, sometimes that level of Wikilove seems excessive for individual edits. What would be nice would be a "Like" (or "Approve", or "Commend" or something else that doesn't make us look like Facebook) button, perhaps next to the button for "Undo", that appeared when an edit was viewed. Users could then show their approval for one another's more minor edits without having to slap a barnstar on their talkpage ("Thanks for deleting that one extraneous apostrophe! I hereby award you this award! Keep up the good work!").
It would also be motivating for new users to see that their edits were approved of - it can take a while to get positive feedback when you first start out (far easier to receive a warning template), and this would show newer users that their efforts were appreciated.
On the other hand, editors would assume that their 'liked' contentious edits (whether by other similar editors or not) have support from all those editors and would wrongly assume consensus or quote such in a talkpage discussion. --lTopGunl (talk) 17:15, 12 December 2011 (UTC)
Absolutely irreversible oppose Adds useless clutter to the database / edit history and would enable a new level of WP:MEAT that is practically impossible to prove or disprove. If you think an edit is fine, just drop the editor a note on his or her talkpage. This also could lead to newbies having their absolutely worst crap liked by their friends and would make it even harder to communicate Wikipedias principles to them. (Sorry for the strong language). Toshio Yamaguchi (talk) 20:56, 12 December 2011 (UTC)
Intensely oppose - whatever gloss you put on it, this would add to the further degenerative Facebookification of Wikipedia, even worse than the contemptible Wikilove. If you wish to communicate with a fellow editor, take the four extra seconds to click on the link to her/his talk page and actually communicate with them like human beings. Templated "goodies" are cheap and sleazy substitutes for actual human interaction. --Orange Mike | Talk22:08, 12 December 2011 (UTC)
Oppose upon every grounds possible and with the right to oppose on any ground as yet undiscovered I remain bemused and somehow impressed by the inventive ways editors invent to turn Wiki into a social media platform doktorbwordsdeeds22:15, 12 December 2011 (UTC)
Strongly Oppose per previous objections, WP is an encyclopedia - not Facebook or a social media site. Let's please keep it that way. Per Orangemike, we can "like" other editor's contributions by dropping them a note of appreciation on their talk page.--JayJasper (talk) 05:42, 13 December 2011 (UTC)
Taking bets that WMF will implement this before long Think about it and you'll realize it's only a small step from the "WikiLove" business to something like this. Those of us who lament the Facebookization of Wikipedia need to get used to the fact that we're fighting a losing battle. Short Brigade Harvester Boris (talk) 05:50, 13 December 2011 (UTC)
The WMF should seriously think about what they actually want. Do they want to alienate their established editor community in favor of a bunch of "Ey yo don't undo ma ediz where I addez that image I finded in Google and it looks more cool naw cuz I tell my homies to dislike all you edits!!!"?Toshio Yamaguchi (talk) 12:32, 13 December 2011 (UTC)
Comment – More or less in response to Toshio Yamaguchi's and my orange colleague's comment, isn't this already being done with the Article Feedback Tool, in which absolute pieces of crap and obvious speedy deletable articles get up-voted 5's across the board for being "Trustworthy", "Objective", "Complete", and "Well-written", when they are in reality not? (I think somebody on WikiEN-l a while back said that the Feedback Tool would be "griefed like with YouTube comments".) Those are not true assessments (at least there is virtually no validity behind it), but rather a measure of how people like an article. –MuZemike06:03, 13 December 2011 (UTC)
Sorry, but no. I see too many potential issues with this, apart from the whole "Wikipedia is not facebook" issue. Imagine the history of an article, with each edit having a like button next to it. Imainge an edit war with one edit saying something like "3 people like this" and another saying "5 people like this". It could create some sort of voting system, where people "like" the version they prefer. If someone sees an edit they find is good, post a friendly, handwritten talk page message. Makes one feel a lot better than an automated "like". Wikipedia is becoming too impersonal nowadays... StevenZhangJoin the DR army!06:10, 13 December 2011 (UTC)
Neutral. A lot of people here are just knee-jerk reacting to "anything similar to Facebook is bad" without considering its merits. Some kind of system for fine-grained feedback for individual edits could benefit editor motivation on a continual basis, increase community engagement with low investment, and just as importantly, help people reviewing changes to focus on those changes that someone else hasn't already carefully reviewed. Despite all this, I share Steven Zhang's concerns about the number of likes being used as some sort of edit-comparison metric. I think a superior and less controversial proposal would be an "edit review" system would you can mark an edit as "reviewed" to indicate you've checked it out and it looks okay. A bit like pending changes but purely voluntary. Then at least we'd know people are looking at what we're doing. Dcoetzee17:04, 13 December 2011 (UTC)
"Some kind of system for fine-grained feedback for individual edits"
GIANT, Strong Oppose per Toshio Yamaguchi and Steven Zhang. As a rollbacker, I already have an extraneous link on the end of the descriptions in the edit history, and I sometimes feel even that link is too much. Adding a "like" button would add useless clutter, especially since it is not a function I would use often here, if at all. If a user's contribution(s) have moved me enough to want to hit a "like" button, I consider that grounds for showing them a bit of Wikilove. - Purplewowies (talk) 17:42, 13 December 2011 (UTC)
Oppose. I'm not a fan of this whole WikiLove thing in the first place, and I just see this as a useless addition that doesn't add any value or quality to Wikipedia, but rather adds a distraction for editors away from doing productive work. New additions to Wikipedia should be focused on improving quality.--Slon02 (talk) 01:53, 15 December 2011 (UTC)
Oppose. A good-faith proposal, but it would clutter us too much and make it too Facebooky. In disputes, good arguments might get overwhelmed by a big "like count" even if the likes lack any context. I'm open to other, less disruptive proposals to promote WikiLove. Lagrange61302:04, 15 December 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Create a new userright
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 - TP03:58, 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. — AlexSm04: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)
Making editing easier
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)
Reply link/button at the end of talk page sections
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)
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)
Remove fundraising banners once a person has contributed
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)
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)
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)
To be able to own Wikipedia.
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.
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)
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. RichFarmbrough, 21:29, 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. Dcoetzee10: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)
Interwiki and domain redirects via URL
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.tofr., 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.toen., 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.orgto.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)
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). fredgandt13:57, 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)
request explicit user consent before moving a file to commons
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. Dcoetzee07: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. --erachimatalk08: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. fredgandt08:43, 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. Gnangarra09: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. Gnangarra09:51, 20 December 2011 (UTC)
RfC on eliminating the comment from the Persondata template
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 following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Currently, when a filemover moves a file, a redirect is always left behind. However, after all instances of the file have been replaced with the new file name, the redirect becomes obsolete and the redirect is deleted. I would like to propose that -suppressredirect be added to the file mover user group. It would allow a file mover to move a file without leaving a redirect behind, and save an admin from having to come by and delete the obsolete redirect. Alpha_Quadrant(talk)04:26, 18 December 2011 (UTC)
There may be exceptions where the current title serves as attribution, something like Template:Copied. There wouldn't be any problem with keeping the redirect unless the image is non-free. If a redirect is used instead of the actual filename, the use will not display in the "File usage" section on the file description page. This poses a potential challenge for non-free content enforcement, as every use of an un-free file should have a specific fair use rationale. While the use would still be listed in WhatLinksHere, it would not be listed in the "File usage" section, making it a bit more difficult in tracking the usage. Alpha_Quadrant(talk)04:58, 18 December 2011 (UTC)
Very bad idea. The creation of a redirect should only be suppressed when the redirect qualifies for speedy deletion, and in the vast majority of cases, that's not the case with the image. In particular, redirects never qualify for R3 (newly created and unlikely) unless the original title is new; if File:IMG 2222.jpg was uploaded in 2005 and you move it to File:Descriptive Title.jpg in 2011, it does not qualify for R3, because despite what the history of File:IMG 2222.jpg says, the title has existed since 2005. Nyttend (talk) 13:01, 18 December 2011 (UTC)
Good point; unless we have a modification to MediaWiki, this proposal would likely result in suppress-redirect being added for all namespaces. Nyttend (talk) 13:45, 18 December 2011 (UTC)
This proposal is for the generic -suppressredirect. It would require additional unnecessary work to implement the tool for just the file namespace. File redirects do qualify for G6, G7 (if nominated by the mover), and R3. If the file has just been moved, the redirect was just created. It doesn't matter how long there was an image there, the redirect is still new. The deletion of these redirect are non-controversial providing all incoming links are corrected. The previous name was incorrect for some reason. And if the redirect is tagged by the file mover, then it is a valid author requested tagging. I have seen some file movers take redirects to RfD, but I am yet to see one of these redirect nominations challenged and kept. It would be excessively bureaucratic to have to send all of these obsolete redirects to RfD, where they are always deleted after 7 days.
If an image is renamed under file move criterion #1, the original uploader has requested a move for some reason. Usually these requests are made because of an error they made. Redirects can safely be deleted, as the reasons for the move are often based on one of the other below reasons.
If a file is renamed under file move criterion #2-5, the original file name was completely incorrect. The redirect left behind is completely implausible and can be deleted after all file usages are corrected.
If a file is renamed under file move criterion #6-7, the file was moved to harmonize with the rest of a group of images or disambiguate images with very similar names. These redirects are obsolete after all instances are corrects, and the redirect can safely be deleted.
If a file is renamed under file move criterion #8, the redirect must be deleted, as the original file name was pejorative, offensive or crude. If this file redirects to a file depicting a living person, the redirect would potentially violate the biography of a living person policy.
All of the above reasons are non-controversial. There may be the occasional exception, but overall, these redirects are obsolete once the file instances are corrected. Alpha_Quadrant(talk)17:10, 18 December 2011 (UTC)
I support this: people with the permission can choose if the redirect is left or not, so in case it's needed to keep it, they would just not check it. Petrb (talk) 13:57, 18 December 2011 (UTC)
Oppose: Deleting image redirects should only happen in exceptional circumstances, and the need for this ability is therefore substantially decreased. I worry that if this right is given to all file movers, it will be misused unintentionally. This right is handed out fairly liberally (and rightly so), but in the rare circumstances where redirect deletions are needed, they should be tagged and reviewed by administrators. PeterSymonds (talk)18:25, 18 December 2011 (UTC)
Deletion of delinked file redirects are a commons occurrence though. For example Wikipedia:Redirects for discussion/Log/2011 October 26. Once the redirects have been delinked, the deletion is non-controversial. Suppressredirect does not allow users to delete anything. The flag just allows the user to skip auto-creating a redirect. Failing to create a redirect after a file move has no more potential damage than moving files themselves. As far as finding the renamed files, the move log will be visible, directing to the new file name. Alpha_Quadrant(talk)19:43, 18 December 2011 (UTC)
What about proposing a trial for limited time (1 month) to check if this feature would be misused or constructive update of configuration? Maybe it would be better than permanent change, Peter's point makes a lot of sense, however it's hard to know if it would be really misused or not, file moving does happen rarely on english wikipedia and people who do that are probably familiar with the rules enough. Petrb (talk) 20:50, 18 December 2011 (UTC)
Oppose - A recurrent complaint from uploaders is that files are moved (either on this project or to Commons) without appropriate linkages or notification, and subsequently cannot be relocated. At least with the redirects, people have a chance to find their now-moved uploads. Risker (talk) 18:29, 18 December 2011 (UTC)
Even after a file redirect has been deleted, it still leaves behind text pointing to the new page.
So even if the redirect is deleted, the author can still find the upload quite easily. The problem is when the image is transfered to commons under a new name, and the administrator does not make a note in the deletion log as to what the new commons name is. Alpha_Quadrant(talk)19:20, 18 December 2011 (UTC)
Oppose. Even if we assume that eliminating these redirects is desirable (which is disputed), how does it make sense to do so before transclusions have been updated (thereby breaking them in the interim)? —David Levy20:10, 18 December 2011 (UTC)
The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move. In the off chance there are a large number of file tranclusion replacements needed, AWB or a script could be used to quickly make the replacements. Over at commons, User:CommonsDelinker goes through and makes the translusion corrections after the file rename. How is keeping the file redirects desirable? As I have linked above, they are deleted after they are delinked. There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial. Alpha_Quadrant(talk)20:20, 18 December 2011 (UTC)
The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move.
No, the two scenarios aren't comparable.
Firstly, a double redirect merely adds an additional step (a link that must be followed). This is inconvenient, but it doesn't sever access to the desired content. Conversely, if an image were to be moved without leaving behind a redirect, all transclusions would simply be broken (resulting in red links instead of media).
Secondly, the need to repair double redirects is unavoidable (unless settings are changed to enable them to function as normal redirects, which I believe proved too resource-intensive). Conversely, the current setup already prevents broken transclusions from arising as a result of file moves.
How is keeping the file redirects desirable?
It's been noted that this assists users seeking files under their original names (who might otherwise have difficulty finding them) and prevents transclusion breakage in historical page revisions.
As I have linked above, they are deleted after they are delinked.
And if we assume that the redirects should be eliminated, that's the proper means of accomplishing the task (deleting them after they're delinked).
There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial.
Some users are expressing opposition now. Has a relevant community discussion ever occurred? RfD isn't a high-traffic forum, so it's possible that the practice has gone largely unnoticed. —David Levy21:21, 18 December 2011 (UTC)
A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location. This move notice provides an easy way for the user to find the file. If a uploader is looking for an old file they uploaded, it is more plausible that the uploader would look at their contribution page, rather than searching for it manually. This is especially true considering that most of the file moves are done because the images have random strings of numbers. If a user checks an old page revision with a moved image, they will find the image after clicking the red link. File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all. There are a fair number of users involved in RfD. Hundreds, if not thousands, of badly named files have been renamed in that time period. That is not something that can go unnoticed. If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up. Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale. Alpha_Quadrant(talk)21:41, 18 December 2011 (UTC)
A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location.
The latter statement is true for administrator/confirmed/autoconfirmed accounts. Please log out and click on File:PICT3902.JPG.
Regardless, would you honestly expect most readers to follow such a link? And are you suggesting that this would result in an experience comparable to the media's transclusion in the article ("merely [adding] a second step" to its access)?
If a user checks an old page revision with a moved image, they will find the image after clicking the red link.
See above.
Regardless, that isn't the same as viewing the image in its intended context.
File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all.
Again, there appears to be opposition now. I'm expressing neither agreement nor disagreement. I'm merely acknowledging its existence.
There are a fair number of users involved in RfD.
You linked to a page on which numerous nominations simply went unchallenged. That establishes an absence of expressed opposition, but it provides no indication of wide awareness or consensus within the Wikipedia community.
If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up.
Setting aside your description of the redirects as "useless", such opposition has been raised in this thread. Are you suggesting that it's too late for these opinions to be considered?
Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale.
Support there is no reason to keep behind redirects to titles like File:IMG_156987. If the mover does what he is supposed to, all uses of the file are switched over to the new better name. I do think that we need to patrol people's file moves more like they do at commons. I have seen people move files that do not need to be moved in any way --Guerillero | My Talk20:26, 18 December 2011 (UTC)
To the contrary, one reason that we keep these titles (like all other titles) is that their deletion causes problems in article histories. That's a major reason that we have RFD: it exists to get rid of titles that aren't useful, but a title that's been linked in an article is generally useful. The speedy deletion criterion only permits the deletion of new titles, and proposing a solution that will get around this is entirely unacceptable — the criterion may only be ignored in unusual circumstances, so making it easy for deletion policy to be ignored is a very bad idea. Nyttend (talk) 20:45, 18 December 2011 (UTC)
RfD is designed to determine whether or not a redirect meets the redirect guidelines. We do not keep redirects just because it is linked to in a previous page revision. Now if the redirect has useful page history, then in that exception, we would keep it. If we were to keep all pages just because it was linked once, there is very little that we could delete. When we have XfD discussions, no votes "Keep, it was linked to once, so we need to keep the page so that it doesn't show up as a red link if someone looks at an old revision of the page." It isn't a valid reason for keeping a page. For example, this diff from 2005. There are a large number of red links there, that, at the time the edit, were blue links. Wikipedia changes constantly. Red links in old revisions are inevitable. Alpha_Quadrant(talk)21:02, 18 December 2011 (UTC)
No one has asserted that historical usage automatically precludes a redirect's deletion. But there should be consensus that the harm caused by retaining a redirect (or type of redirect) outweighs the benefits. If a redirect (or type of redirect) causes no significant harm, even a minor benefit is a sufficient reason to retain it. (This is hypothetical. I'm not expressing an opinion regarding the harm:benefit ratio.) —David Levy21:21, 18 December 2011 (UTC)
Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect. The names are inappropriate for some reason. Given that we are transferring our free images to commons, that will just leave non-free images and a few free images that cannot yet be transfered there. As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page. Alpha_Quadrant(talk)22:04, 18 December 2011 (UTC)
Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect.
Benefits have been clearly noted. It's reasonable to argue that they're minor and outweighed by detriments, but it's unreasonable to claim that they don't exist.
As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page.
That's a valid argument as to why the detriments of retaining redirects to non-free files presently outweigh the benefits, not evidence that no benefits exist.
Comment I am really happy to see that most of opposing are sysops :) that implies that although it might look bothering to them to fix file moves after file movers, they probably don't have problem with that. It seems that proposal was started to spare them of that activity, but maybe it's not necessary. However I still believe that giving this bit to file movers would cause no harm. Petrb (talk) 20:54, 18 December 2011 (UTC)
Oppose - deleting redirects is often unnecessary and user hostile; adding 'suppressredirect' to filemover would extend deletion privileges to 235 users who have not been vetted for the same. –xenotalk16:09, 19 December 2011 (UTC)
Support- I support this fully. Also, if to compromise, would it be possible to ask the developers to create a new right 'suppressredirect-file' and only allow it to work in the file namespace? JoeGazz ♂ 01:51, 20 December 2011 (UTC)
It's hard to convince any of us to work on anything what doesn't have established consensus because it's usually waste of time, however if this passed, I would be happy to implement it, it's an easy change. Petrb (talk) 13:54, 20 December 2011 (UTC)
Oppose I used to be a fan of getting rid of old file redirects of the File:IMG1234567.jpg variety, but I came to the realization that the deletions really didn't do much good, and they had the potential to to a good bit of bad (per the reason Risker mentioned). The only way I'd support this is if users are only allowed to surpressredirect moves they make themselves (for if they make a typo in a move and have to do a remove). Even then though, not worth it. Sven ManguardWha?03:33, 21 December 2011 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Learn to be a Wikipedia Administrator - New class at MSU
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!
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. bibliomaniac1507: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.
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-C12: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:DYKWP: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 personsorediting 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:AIVWP: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-C13: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.---BalloonmanPoppa Balloon22:36, 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)
Namespace and watchlist
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. fredgandt09: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. Dcoetzee09: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 ManguardWha?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. Dcoetzee13:12, 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--SPhilbrickT15:58, 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. fredgandt18:07, 14 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)
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. Secretaccount06: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? fredgandt06: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)
—Tom Morris (talk) 12:20, 25 November 2011 (UTC)
fredgandt 14:07, 2 December 2011 (UTC)
