Wikipedia:Village pump (proposals)/Archive 95

An RFC was just opened on the

@ Ryan Vesey, perhaps my wording leaves something to be desired. The intent would be that the parties would agree, not that they could go there and smear you without your participation. You would have to agree to the "Breakroom" chat, and should you decide to withdraw from a BR chat in progress, then the remaining parties would be expected to refrain from commenting about you. Anyway, people smear others at User:talk all the time, with virtually no recourse except in the most extreme cases. A "Breakroom" could clear talk pages of this clutter, and newer, or even experienced editors more adverse to conflict would find them easier to avoid. As you said, you wouldn't go there, that's great, but if you ever did find yourself in a heated dispute you might be asked to "take it to the Breakroom", versus "shut-up and get back to work you pathetic child!" ~ GabeMc ^{(talk|contribs)} 23:54, 23 October 2012 (UTC)

@ Theopolisme, but is IRC really intended for dispute resolution? I thought IRC is the social networking area of Wikipedia. Also, IRC is in real-time, the BR would be as a talk page, so that editors could respond to comments made several days, if not weeks ago, so I don't see IRC as equivalent to a Breakroom. ~ GabeMc ^{(talk|contribs)} 00:17, 24 October 2012 (UTC)

(edit conflict) IRC is a ... well, let's call it a complete free-for-all that happens to attempt to get things done once in a while. :) And that really is what this breakroom seems like it would turn out to be -- a cursing, spitting, screaming free-for-all... I'm not criticizing you, Gabe -- rather, I don't think that Wikipedia -- at least the majority of folks who go to DR (low-level stuff) -- are capable of handing a free-for-all. They need the structure... which I don't think the breakroom would be able to provide. Theopolisme 00:40, 24 October 2012 (UTC)

Editors who want excess structure and the possibility of admin sanctions go to AN or DRN. Editors who just want to have a heated discussion without the imminent fear of admin reprisals could go to the Breakroom. The main point being, nowhere except formal mediation are editors free from admins deciding when and how to end conversations and/or block an editor for disruption/incivility. A Breakroom would/could reduce the amount of blocks given for disruption originating from editor disputes, or just blocks to complaining editors. No admin can swoop in and play Wikicop in the BR (with a few exceptions), demanding that you immediately cease and desist or face an arbitrary block. Nowhere on Wikipedia are editors safe from this possibility to my knowledge, at the Breakroom they would be, that's why this adds something "new". A case in point. ~ GabeMc ^{(talk|contribs)} 00:54, 24 October 2012 (UTC)

What is the benefit of endorsing rampant heated discussion? It's... Rampant. I just have yet to see how this would... work out. Theopolisme 01:35, 24 October 2012 (UTC)

Good question. As someone with extensive counseling experience, I can say that sometimes people just need to "vent", complain, "whine" or whatever, and there isn't always a finite solution to be found other than meeting that need, to vent frustration. IME, admins typically demand either an immediate solution (shut-up), a sanction (block), or a labourious process such as AN/I, RfCU, MedCom, or similar. At the BR, editors could call each other nasty names, complain about their behaviour, and generally air grievances until, hopefully, the animosity fades (I've seen this with my own eyes a thousand times), leading to an overall decrease in editor tention, theoretically improving editor retention. I've watched this process of "therapeutic complaining" turn violent people who once considered each other arch enemies into confidants. Sure, there are several bugs that would come up, but I don't see how a trial period should be considered too risky an endeavor when Wikipedia stands to gain so much, should the proposal prove therapeutic long-term. Of course, the BR could easily be closed if this didn't work as planned. Also, to clarify, the heated discussion at the BR would not always be Rampant, nor should it be. The point here is that it could be, without the fear of some admin blocking an editor before the dispute is resolved, it fizzels out, or reaches a stalemate. ~ GabeMc ^{(talk|contribs)} 01:46, 24 October 2012 (UTC)

So you think editors would be comfortable ranting/raving at a public on-wiki page? Rather than a private, off-wiki, off-record IRC chat? Theopolisme 02:18, 24 October 2012 (UTC)

You are using loaded language to prove your point, e.g. "ranting/raving". I would say that editors currently rant/rave at a public on-wiki page daily (see many talk pages, both user and article). Why would a centralised location for drama be any different in that regard? The BR would be a pre-AN place, and admins may even require that editors attempt to resolve issues themselves at the BR, before involving admin resources at AN. At any rate, it would be nice to have one safe place from admin sanctions, and that in and of itself seems worth a trial period. ~ GabeMc ^{(talk|contribs)} 20:51, 24 October 2012 (UTC)

Guilty as charged. However, as you just said: "I would say that editors currently rant/rave at a public on-wiki page daily"... then why should we encourage doing so even more if it already happens? I think I have to concur with other opposes/comments above and below... this just doesn't seem (to me) to be a net benefit to the project. Theopolisme 21:51, 24 October 2012 (UTC)

Who is encouraging negativity? At the BR users would be expected to attempt to work out their differences without the drama spreading around the project and sending a negative impression to new users while burning out experienced ones. Also, this would be a bit of an experiment to see if we could reduce the admin workload at AN. Wouldn't it be nice if editors could once in a while work out their problems without needing an admin? As I said above, there is already mucho drama at Wikipedia, a BR could help centralise it so as to minimise the collateral damage to the project. I've seen it a hundred times where a talk page thread extends to ludicrous lengths because two editors are having a heated discussion between them, pushing out other voices by dominating the discussion. To say that the BR would encourage negativity is an assumption. IME, issues don't magically disappear just because an admin demanded the discussion cease. The problem remains, festers even, until an AN/I report is filed, a user is blocked or quits. What harm could a trial period do? ~ GabeMc ^{(talk|contribs)} 22:25, 24 October 2012 (UTC)

@Resolute, Per: "Serves absolutely no constructive purpose whatsoever", an assumption that could not possibly be proven without first being tested. There are/were several heated debates I would like to have with editors that are invariably "shut-down" by annoyed admins wanting editors to "be productive" or to "get back to work and stop wasting time". Well, no one could be accused of time wasting at the BR. This likely seems unneeded to you, since you regularly "vent" at Jimbo's page, but not all of us are afforded that luxury, and some of us have been straight-up denied that privilege. ~ GabeMc ^{(talk|contribs)} 01:20, 24 October 2012 (UTC)

Gabe, nobody could be accused of anything but time wasting at such a forum. If you want to vent about something at Wikipeida, go print off an 8x10 copy of Jimbo's picture and yell at it. Resolute 14:09, 24 October 2012 (UTC)

• Comment: No decision one way or the other whether this is a good or bad thing or not, but for historical purposes, Wikipedia:Esperanza bears bringing up during these discussions. Toodles. --Jayron32 11:23, 24 October 2012 (UTC)

  I thought of Esperanza as well, but that was more of a cult than a fight club. Resolute 14:03, 24 October 2012 (UTC)

  Fight Club wasn't a cult? I'm pretty sure that is exactly what it was... --Jayron32 18:21, 24 October 2012 (UTC)

  Nah, Fight Club was an underground boxing ring. Project Mayhem, now that was a cult. —chaos5023 (talk) 21:48, 24 October 2012 (UTC)

• Comment. - It seems many are assuming this would create or drum-up drama, well, like it or not, the drama is already here. Its just spread evenly around talk pages where new users can see it, and old users can get sick of it. A BR would give drama a place where nothing is "off-topic" and a BR would be a focal-point for drama, but I fail to see how a safe place to go and have a heated discussion would cause drama. Anytime someone wants to call you out, or you want to call someone else out, but you would rather it not be on your talk page: this could be used. The trouble with AN/I is that all behaviours are under scrutiny, and both parties become subject to admin sanctions for just going there. This would not replace AN except for those cases where no admin action is required, which seems like about 1/3 of all AN cases, which are closed as "wrong forum" or "no admin action required". These would be issues that editors could discuss at the BR, without fear that an admin will come in and arbitrarlily stop the discussion because they have judged the situation either resolved, or too dispruptive to Wikipedia. Arguments/disputes/heated discussion would not disrupt Wikipedia if they occurred at a central location. This could also be a place where "interventions" could occur, perhaps preventing a few indeffs that happen at AN. ~ GabeMc ^{(talk|contribs)} 20:33, 24 October 2012 (UTC)

• Comment. - There is currently no place on Wikipedia where a non-admin can tell an admin to "fu---off" without fear of a block. Would it really be that bad to have one place where all Wikipedian's could speak freely without fear of reprisals, regardless of their user status? ~ GabeMc ^{(talk|contribs)} 20:44, 24 October 2012 (UTC)

• GabeMc, you indicate it's your IRL counseling experience that leads you to consider this a good idea. I think it's worth asking, though, whether that experience is portable to this medium. Have you seen the venting-reconciliation cycle work in a text-based, pseudonymous environment where participants have neither tone of voice nor body language available as components of their communication? —chaos5023 (talk) 21:18, 24 October 2012 (UTC)

My RL experience is only one part of why I think this may help here at Wikipedia. Three years on Wikipedia is the primary experience that makes me think this could work here. As far as your question about Wikipedia's "pseudonymous environment", well no, I havn't seen this work in that condition, but then, why would trying something new be worse than what we currently do, which is to attempt to resolve disputes in a "pseudonymous environment"? The difference here is that community members would attempt to resolve disagreements without running to an admin for help. Seems like admins would appreciate that. ~ GabeMc ^{(talk|contribs)} 21:28, 24 October 2012 (UTC)

Well, opportunity cost is why, basically. The question is whether we can reasonably anticipate whatever cost/benefit mix this course of action brought to be better than avoiding it. If one considers it most likely to generate extra drama that sucks up editor time and energy that might have otherwise gone to things like content creation, then one would naturally consider "just trying it" a bad idea. —chaos5023 (talk) 21:37, 24 October 2012 (UTC)

I think the attitude that pushing users to edit and improve articles at all times or face sanctions drives editor loss. Why is there not one place at Wiki where an editor is safe from a random admin demanding they immediately "shut-up and get back to work"? This is why real jobs have a breakroom, so workers (editors) can take a break, complain about the boss, BS about an off-topic TV show etcetera. There is no open forum that I am aware of on Wikipedia. If you are not improving an article you are assumed to be wasting time with off-topic discussion. Why do you think an open forum on Wikipedia is a bad idea per se? Your "opportunity cost" argument against lacks empirical evidence. How much time is wasted at AN daily? If the BR could save any time there, then it may balance out the perceived negativity, which again, is already here, its just not being dealt with in a way that doesn't involve admin sanctions, which typically only punish editors, and rarely prevent anything, except perhaps editors continuing to contribute to Wikipedia. ~ GabeMc ^{(talk|contribs)} 21:48, 24 October 2012 (UTC)

I'm really more just trying to communicate why people are probably not insane to not want to try your proposal. I'm not actually convinced it's a bad idea. Your argument is kinda scattershot, though. Wikipedia (

WP:NOTWIKI, by the way) isn't very analogous to a workplace because you're a volunteer and can walk away from it whenever you like and vent about it to whomever you like. And it's really hard to construct admins as bosses; I've had adverse interactions with administrators, but certainly never one where I felt like I was being told to get back to work. (If anything, I feel like that role is filled by trigger-happy AfD nominators using the threat of content destruction to extract labor from volunteers.) And you seem to be conflating the idea of the breakroom as a "time off" venue with the "two parties working out their differences" counseling / dispute resolution idea, which I'm not familiar with having anything to do with a workplace breakroom. —chaos5023 (talk

) 21:55, 24 October 2012 (UTC)

I've resolved, and been involved in the resolution of numerous workplace disputes in an employee breakroom, and I've been told multiple times by admins to get back to work. If admins aren't bosses, then what are they? Managers? If an admin can block you (fire/lay-off) then they are acting as a boss IMO. Don't you think Wikipedia could have one page where admins cannot decide when conversations need to end, and who needs to shut-up? A BR could reduce editor repression of frustration. You say just walk away, but how does that improve editor retention? Wikipedia's current attitude of "if you don't like it then leave", is costing us editors, and unless I am under a false assumption, I thought the recent editor die-off is an issue of serious concern for the project. ~ GabeMc ^{(talk|contribs)} 22:02, 24 October 2012 (UTC)

• Kaldari, per your comment: "You either have to join in (and be subject to more direct attacks) or try to ignore it while your name gets smeared." If you re-read the proposal (rules) I think you'll see that "slamming" editors not volutarily participating in a discussion would be prohibited at the BR. ~ GabeMc ^{(talk|contribs)} 21:34, 24 October 2012 (UTC)

• @Steven Zhang, are you of the school that laws that decriminalise marijuana also encourage its use? You seem to be our resident dispute resolution guru so I certainly respect your opinion. I suggest that not every dispute needs an admin censoring and dominating the parties. Why not give Wikipedian's an opportunity to demonstrate that they can resolve differences without admin intervention, and without a strict adherrence to mainspace guidelines intended to protect Wikipedia content, not reduce editor frustration. ~ GabeMc ^{(talk|contribs)} 00:08, 25 October 2012 (UTC)

  I understand what you're trying to say, but I disagree with your opinion. In my experience in dispute resolution, I've found that civilised, collaborative discussions are very effective, and I feel that the creation of a forum where slinging mud at each other is OK, is contrary to our standards and actually creates more ill-will. A survey of former contributors found 25% left Wikipedia due to unpleasant interactions with others. Now, I appreciate that the community is divided on the civility policy, but I disagree that creating one place where "anything goes" is a bad idea, and that encouraging people to work out their differences in a civilised way would make Wikipedia a better place. Regards,

  Help resolve disputes!

  00:34, 25 October 2012 (UTC)

Admittedly, this proposal leaves much to be desired (its my first ever on Wikipedia). There seems to be an assumption that the BR would always be a free-for-all with all hell breaking loose. That's not really the point. The point is that should all hell break loose, editors at the BR are safe from admin sanctions. Currently, the only way an editor can enjoy that luxury is at a formal mediation, where civility is strickly enforced. I support civility, but overcivility can at times lead to the suppression of anger. Forget "the catharsis hypothesis", do you think it might be helpful to have one safe place where editors can speak freely without any fear of admin sanction? If not, why not? ~ GabeMc ^{(talk|contribs)} 00:58, 25 October 2012 (UTC)

The privelige of formal mediation is exactly that, a privelige. It's there to allow open communication, not abuse. The policy explicitly states "..f a party engages in disruptive or bad-faith conduct during mediation, and that conduct later becomes the subject of disciplinary proceedings, the Mediation Committee will decline to protect the privileged nature of the party's communications.". It's not a right, if abused, it can be withdrawn. I don't feel there should be any location where we encourage people to go if they want to be uncivil to each other. It's just giving the wrong message. Tempers flare occasionally, and that's OK. But let's not create somewhere where anything goes.

Help resolve disputes!

02:39, 25 October 2012 (UTC)

Looking at the study you cited, it would appear that more than 1/2 (419) of the people who cited "bad terms" as a reason for leaving named "complexity" as an issue, while 372 cited an issue with another editor. Further, of the "community" critics, the report states that the issue had more to do with content reversions, deletions and the general stubborness of editors versus open hostility or rudeness. ~ GabeMc ^{(talk|contribs)} 01:09, 25 October 2012 (UTC)

Further, it would appear that of the 372 who cited issues with another editor, around 12% left because of admin warnings/threats of sanctions, 50% left due to their work being undone, and 44% due to difficult editors. Well, if 1 out of 10 people who leave Wikipedia due to conflicts with editors cite the warnings of admin sanctions, than it would appear that admins shutting down discussion and threatening sanctions contribute to about 5% of all editor loss. ~ GabeMc ^{(talk|contribs)} 01:23, 25 October 2012 (UTC)

The stats about admin warnings/threats of sanctions (or actual sanctions) would apply to editors that also left because they were blocked for things like vandalism or edit warring. The requirements for the survey was 20-99 lifetime edits, left within 3 months of the survey, and last editing being in 2009, so while we definitely need to take this into account, I feel that the 32% who left because editors were rude to themselves or their peers, is a more significant figure and we should work on making this place a more collegial one.

Help resolve disputes!

02:39, 25 October 2012 (UTC)

Right, so is it your assertion that Wikipedia's primary concern regarding editor retention should be that the fourth pillar is not being properly enforced/encouraged? ~ GabeMc ^{(talk|contribs)} 02:43, 25 October 2012 (UTC)

I didn't say that, please don't make assumptions on my opinions. I'm a strong believer in data. My personal feelings are of little relevance, it's the collective view of those surveyed that is important. Usability of Wikipedia seems to be one of the larger barriers for the retention of casual contributors. I'm just saying that I don't think we should encourage people to call each other names, anywhere on Wikipedia.

Help resolve disputes!

03:21, 25 October 2012 (UTC)

I agree. I should have incubated the idea first, and perhaps its just not right for Wikipedia, but FTR I do agree that namecalling should not be allowed anywhere on the project. ~ GabeMc ^{(talk|contribs)} 04:00, 25 October 2012 (UTC)

• WP:WikiProject Freedom of speech

I've recently gone ahead and created WP:WikiProject Freedom of speech. If you're interested, here are some easy things you can do:

1. List yourself as a participant in the WikiProject, by adding your username here: Wikipedia:WikiProject_Freedom_of_speech#Participants.
2. Add userbox {{User Freedom of speech}} to your userpage, which lists you as a member of the WikiProject.
3. Tag relevant talk pages of articles and other relevant pages using {{WikiProject Freedom of speech}}.
4. Join in discussion at Wikipedia talk:WikiProject Freedom of speech.
5. Notify others you think might be interested in Freedom of speech to join the WikiProject.

Thank you for your interest in Freedom of speech, — Cirt (talk) 22:38, 25 October 2012 (UTC)

Prompted by the "discussion" at

I see several problems. Vandals can disable the feature by keeping an edit window open. We would then need policies on how to deal with this, more rules for warnings, more rules for blocks and so on. Distinguishing between good-faith mistakes and intentional ones will be hard. Second, because of various time lags, conflicts will still happen. What if somebody else puts in an edit just after I receive the all clear but before I click the edit button? This can be handled (mutual exclusion and critical section handling), but is usually tricky because a software bug could end up locking out all editing. The issue seems to be mainly for talk pages and noticeboards such as

WP:AIV. For AIV, the edits are small but frequent. Usually most software supporting concurrent editing either provide better merge tools, or allow branching of versions. We don't want branching; we could have better merge tools, but Wikipedia cannot afford a battalion of developers, and our edit interface will reflect that reality. Churn and change (talk

) 16:00, 21 October 2012 (UTC)

And what about editors like me who click edit and come back to it a week later after I find a reference or decide on wording? I have noticed two things, first the merging is better, I often find someone else has added something else and oddly no ec was generated, and secondly if I make an identical edit as someone, the software says I made the edit but the history gives credit to someone else, who made it first. The only suggestion I would make is improving the merging - when someone clicks on a section to create a new section it kicks in an ec when there is no conflict. Apteva (talk) 22:15, 21 October 2012 (UTC)

You click edit, and come back a week later? -- :- ) Don 23:03, 21 October 2012 (UTC)

Sometimes - but then again maybe 26 browser windows/tabs is too many too. Apteva (talk) 21:16, 22 October 2012 (UTC)

• Comment. - I find {{in use|section}} tags helpful when it comes to avoiding ECs. ~ GabeMc ^{(talk|contribs)} 23:05, 21 October 2012 (UTC)
• Maybe I should have used minimising the chance of edit conflicts not avoidance. I did say that it should not lock out editings, just notify you that someone else may be editing it too. Thinking about it some more, it should also tell when there definitely will be an edit conflict, because someone has already saved an edit. Basically I would like to know how feasible it is to expand the edit conflict detection to be more predictive, dynamic and live in real time, not just on hitting save. The current EC system can remain for when you do hit save, but an improved detection system might help you decide whether to hit refresh first, wait a while or just carry on. Incorporating it into the new page curation tool might be the best first step, to assist in delaying non-vital edits that could otherwise annoy new editors who can't handle edit conflicts. The-Pope (talk) 04:48, 22 October 2012 (UTC)
  • I think it very likely that a feature like this could choke and die on caching servers. But i'm not technical, so I don't know.  :) Philippe Beaudette, Wikimedia Foundation (talk) 14:42, 27 October 2012 (UTC)

Sometimes I see requests on the Help Desk from people who are having problems in another language's Wikipedia, thinking that English Wikipedia is the place to appeal when all other attempts have failed. Is there a possible way to allow such appeals?— Vchimpanzee · talk · contributions · 20:44, 26 October 2012 (UTC)

No. Send'em to meta:. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:21, 26 October 2012 (UTC)

That's actually what I was looking for. Thanks.— Vchimpanzee · talk · contributions · 21:36, 26 October 2012 (UTC)

I started a topic here. We'll see if that goes anywhere.— Vchimpanzee · talk · contributions · 22:21, 30 October 2012 (UTC)

As an FYI, you can link to Meta by putting meta: in front of your link, so [[meta:Help Forum]] goes to meta:Help Forum. --Philosopher ^{Let us reason together.} 23:41, 30 October 2012 (UTC)

Thanks. I'm not optimistic because the second-to-last question had been asked in June and got no responses. The last question was asked early in October, and no responses there either.— Vchimpanzee · talk · contributions · 14:41, 31 October 2012 (UTC)

Yeah, certain areas of Meta are always active, but many can go dead for a while. You can always leave a note with a Meta admin if your request goes too long without being responded to, though. --Philosopher ^{Let us reason together.} 06:15, 1 November 2012 (UTC)

I would like to see the

They now take up less real-estate at the top of the articles then they use to. Not sure if that is a recent change, but I don't see how moving them off the top of the article help will help the articles. The reason those cleanup templates are at the top is so that they will be noticed more and hopefully encourage editors to "fix it". —Farix (t | c) 01:51, 28 October 2012 (UTC)

I oppose moving these to the reference section. They're not references for the article, and no other cleanup templates go in the reference section. Calliopejen1 (talk) 18:32, 31 October 2012 (UTC)

When I copy a url straight to put as a link, I paste it onto the link popup. The problem is that it will only convert my url into short format if I ask it to convert into external, and in the corresponding popup, i click on internal. Things would have been a lot simpler had it straightaway converted to short if i clicked internal.

What I am forced to do [cumbersome if I got to do it 20+ times]

• I paste http://en.wikipedia.org/wiki/Main_Page to popup and have 'Convert to external'.
• It asks if I want to convert to Internal
• I click yes
• It converts

What I want -

• I paste http://en.wikipedia.org/wiki/Main_Page to popup and have 'Convert to internal'.
• Link fails [Should not happen]

What I could do [Again hectic] -

• I paste Main_Page to popup and have 'Convert to internal'.
• Link works

I didn't know the feature you refer to but I see it's in the enhanced editing toolbar which has a chain icon above the edit box. I guess the feature is intended to "catch" people who try to use external link syntax instead of an internal wikilink. It's not a recommended way to make a wikilink. It has problems with conversions between encoded url's and page titles. The normal way to make a wikilink is to write or copy-paste the page title seen at top of a rendered page. Main Page hides the title so that's a poor example. Consider Help:Link instead. You can copy-paste "Help:Link" from the top of the page and make it a wikilink by placing double square brackets around it: [[Help:Link]]. Personally I nearly always type [[]] manually instead of going for the mouse. PrimeHunter (talk) 01:33, 31 October 2012 (UTC)

The thing is that I had to quickly copy many links, and for that, the most convenient way would have been to double click and copy the url. If you give an internal link in full (en.wikipedia.org/...), it asks you if you want to convert it to an internal link. If you click yes, it will then autoconvert my long url to internal wiki version. But if i paste a url, and select 'Internal link' from the two radio buttons, then it will not autoconvert it (as it previously did). Rather, it will just give the link as is, making it a dead link. I consider it to be a lot more convenient if the autoconversion [which was there in the previous case] was made implicit; so every time I click 'internal', it checks if the link i give is a full url; and autoconverts it to an internal version, if reqd.

talk

) 15:21, 31 October 2012 (UTC)

I don't know whether this is really the best way to go about this proposal or whether I should propose it on Meta instead. However I propose it as an editor of the English Wikipedia, so let's start here. I have been pointing out for a long time that linkrot is a serious problem for Wikipedia (at least I believe it is). In many cases I used WebCite to archive references in order to ensure a sources availability in the long term. However, WebCite currently seems to be down and I was unable to retrieve previously archived references or archive new ones.

I thought about a closer collaboration between the Wikimedia Foundation and WebCite. Now why should the WMF collaborate with a project which isn't even functioning properly right now? I guess WebCite already has a large collection of cached sources. I used it myself many times and I think some of the sources I archived have already vanished, so (re)gaining access to those sources would definitely be in the interest of Wikipedia. If WebCite could be better integrated into existing Wikimedia projects, a part of WMF funds could perhaps be used to improve WebCite. Of course WebCite should perhaps in return ensure that the service will be available for Wikipedia purposes and can be used by its contributors (an interface for using WebCite here at Wikipedia would be nice). -- Toshio Yamaguchi (tlk−ctb) 08:12, 30 October 2012 (UTC)

Myself and

bounty up for it). Legoktm (talk

) 18:38, 30 October 2012 (UTC)

What do you think ?

Can be useful for editors ? For coordination ? --CortexA9 (talk) 04:52, 1 November 2012 (UTC)

Can you please be a little more specific? We generally use

not be a social network.--Jasper Deng (talk)

04:59, 1 November 2012 (UTC)

Example: I want to improve an article with other editors. I think is useful to listen other editors. --CortexA9 (talk) 05:03, 1 November 2012 (UTC)

The foundation probably cannot commit the resources, so if you want to do this you will have to organize it yourself and get the necessary equipment. I don't see the need.--Jasper Deng (talk) 05:05, 1 November 2012 (UTC)

Or just inform of other changes about Wikipedia. --CortexA9 (talk) 05:08, 1 November 2012 (UTC)

That isn't really streaming is it? I don't think there is even a podcast, or enough material to run new spoken words regularly. --LauraHale (talk) 05:12, 1 November 2012 (UTC)

Yes but a podcast is a different thing than a streaming. --CortexA9 (talk) 05:17, 1 November 2012 (UTC)

I don't understand how it would be particularly useful to have a radio stream in this context, one DJ/Anchor/Whatever talking about improving an article to multiple editors who cannot respond back and only listen just seems weird. Are you thinking of a collaborative voice chat over something like mumble or skype rather then a radio stream? Monty₈₄₅ 05:28, 1 November 2012 (UTC)

I make a wrong example. Sorry, but if we can use the stream for inform downtime, or status of wikipedia ? --CortexA9 (talk) 05:32, 1 November 2012 (UTC)

We have [1] for stats.--Jasper Deng (talk) 05:34, 1 November 2012 (UTC)

Cool. --CortexA9 (talk) 05:38, 1 November 2012 (UTC)

FWIW, there is/was

WP:MUMBLE. Don't know how active it is, or if it's even still up. Legoktm (talk

) 11:42, 1 November 2012 (UTC)

The online program firetalk originated as a way of allowing multiplayer game players to talk to each other. The speech algorithm used was incredibly good and quickly became firetalk, a stand alone speech platform, but was so good that it became most popular as a way of singing, either acapella or as kareoke over the Internet. They never developed a revenue model and went out of business and users gravitated to other talk over the Internet platforms, such as Paltalk, which eventually bought Firetalk, but long after no one was left there. The excellence of the algorithms used in firetalk, as far as I have seen, has not been replicated, and certainly does not exist in Paltalk. Is that the sort of mechanism that was being suggested? Live audio chat? So that heated arguments can be both audio and visual? Apteva (talk) 15:17, 1 November 2012 (UTC)

Hello, i have a proposal regarding the blocklist. Every time I read the blocklist, the whole page is filled with ProcseeBot's blocks and autoblocks, making it next to impossible to find actual users that were blocked. I suggest that there should be a tickbox at the top of the page that, when checked, excludes all the aforementioned types of blocks. Passengerpigeon (talk) 08:43, 1 November 2012 (UTC)

See bugzilla:19322. Legoktm (talk) 11:40, 1 November 2012 (UTC)

Ok, thanks. Passengerpigeon (talk) 22:36, 1 November 2012 (UTC)

The above heading is the one given whenever my talk page is edited. But since its mainly edited only by the RFCBot, thats kind of misleading; as I only wish to check the RFCBot messages at some of the times. I suggest - 1) Have two templates, one for bots, and the other for users, so it clears it up, as well as gives me a way to view them separately. 2) Or removing the ambiguous words 'from another user' from there.

The way bots work is that if they mark the edit as minor, you aren't notified of their edit. However with newsletterbots, and other notification bots (like DPL bot, RFCBot), the intention is to notify the user. If you get too many notifications by RFCBot, you should probably change your frequency or find a different way to be alerted of RfCs. Legoktm (talk) 11:38, 1 November 2012 (UTC)

Over on Commons, there's a script (gadget? can't remember now) which looks at a user's language preferences (from browser details if not logged in, I think), and recommends changing interface language. Based on two feedback comments I've just seen (one here), maybe this tech could be used to make language versions for some cases more prominent. Examples:

1. Spanish version for Latin American people
2. German version for German topics
3. that sort of thing.

Basically, where there's a clear native language for a topic other than English, and the user appears to want that language, make a link to that language version of the article more prominent if such an article exists. (How to display and how to specify the "native version"(s) is less important at this stage than the principle.) Oh, and of course for logged-in users, allow the behaviour to be turned off... (though it shouldn't really be made so obtrusive that many would want to). Rd232 ^talk 21:35, 23 October 2012 (UTC)

Oh come on, not one single comment, question, or request for clarification? Rd232 ^talk 22:52, 27 October 2012 (UTC)

I'm just indulging you a bit. Your comment made me laugh. It's much like a teacher posing a question to a classroom full of students yet noone neither responds nor expresses that they don't understand the question.

While I'm not sure how your proposal would work I see it as too trivial. Whenever you view an article the available article in other languages is already easily accessible. What I think could be proposed is a script which informs the user that the article is available in their native language. Thus, once a user clicks on an article in English the script is generated and shown on-screen for a few seconds. The user would then have the option of scrolling down to the article in his/her preferred language. Even this alternative I don't think is worth the effort. The language preferences are already easily located so this seems like an unnecessary encumbrance.EagerToddler39 (talk) 06:31, 28 October 2012 (UTC)

Thank you for engaging! The languages versions are indeed readily accessible if you know where they are (there's nothing obvious about the sidebar location and there's a current discussion about renaming its heading to make it clearer what they are); language preferences relate to user interface and are anyway only available to logged-in users (most readers are not logged in). The two feedback comments which prompted this idea (on the same article!) demonstrate that there is a real problem here, not just me thinking out loud. So the script you describe is the sort of thing I have in mind, and because the tech should be readily adaptable from existing ones I think it's worth the effort. Rd232 ^talk 06:41, 28 October 2012 (UTC)

Technically, I suppose this is possible; you can ascertain someone's nationality based on their IP address (and it can be done anonymously, so it's not really a privacy violation). You could probably cross-reference the location with a language map (like you said, if the IP resolves to a German location, then place the emphasis on the de: interwiki). However, it's way beyond my skills to come up with something like this. What did you have in mind as the emphasis? EVula // talk // ☯ // 07:34, 28 October 2012 (UTC)

The technical problem doesn't need solving, I think, because AFAIK the Commons tech which automatically recommends changing user interface language can be repurposed with probably not much effort. The harder problem might be deciding when to recommend the user's probably-preferred language version; the easiest solution is to simply always recommend it, rather than try some kind of per-article thing that takes into account when the other language version is likely to be superior to the English one. NB I can't find the Commons code that does it now, but someone like User:Rillke would know. PS Not sure how to do the highlighting, but to be effective it needs to make the language link appear much more prominent - near the top of the page, maybe the way Commons does the user interface language recommending. Otherwise it's not going to make much difference - the idea is aimed at users who don't know/notice the sidebar language links. Rd232 ^talk 22:14, 29 October 2012 (UTC)

In MacOSX, there is a system settings where you can pick your preferred languages, and I think Windows has the same thing. Could Wikipedia read this information and suggest a person's preferred language on the top of the screen? Ego White Tray (talk) 02:06, 3 November 2012 (UTC)

The proposal is to add noticeboards for the 9 article categories listed on Request for Comments (

Do you know how many threads can be expected to be active at any given time on one of the boards? That is a real question, not a rhetorical one. Churn and change (talk) 02:48, 31 October 2012 (UTC)

Well, first I'd say that a dispute is encouraged to be worked out on the Talk page first. This wouldn't be to replace them. But this would be an alternative for RFCs, especially for pages that don't get a lot of traffic, like pages such as the Presidential election do. So there might be similar numbers to what's on the RFC page now. Some disputes might also be taken to these boards rather than Dispute Resolution too. Psalm84 (talk) 02:55, 31 October 2012 (UTC)

Okay, so that seems ten or so for the more disputed categories. Looks manageable. I take it your suggestion is to have the actual discussion on the noticeboard, and transclude it on the article's talk page? One issue I see is that some pages such as the MOS talk page are better quarantined from any common noticeboard. This recent RFC on Wikipedia_talk:Manual_of_Style/Archive_131#RfC:_Internal_consistency_versus_consistency_across_articles generated 31,000 words, not including further debates on the RFC procedure itself. I would say editors should be given leeway to kick a discussion back to the article's talk page if it is dominating the page; the purpose should be to give more visibility to the disputes in the more obscure corners. Churn and change (talk) 03:28, 31 October 2012 (UTC)

Yes, that would be the purpose, to give more visibility, and the discussion would be on the noticeboard. Length would be a concern probably in some cases but options for those cases could be discussed, including the one you mention to move the discussion back to the talk page. Psalm84 (talk) 03:56, 31 October 2012 (UTC)

Okay, and thanks for rephrasing the "kicking out" as "moving discussion back." One other issue is cross-posting to multiple boards. I think we should allow RFCs to be posted on one particular board to be cross-linked from others (that is, with wikilinks to the discussion posted at other boards). Also, looks like transclusion to the article talk page won't work; only an entire page can be transcluded, not a part of it, but posting a link to the discussion on the article's talk page should be sufficient. Churn and change (talk) 15:56, 31 October 2012 (UTC)

No, I don't think transclusion would work, but as you say, a link on the talk page should be sufficient. I'm not quite sure if I followed what you said on the cross-linking, though. What other boards should have wikilinks? Do you mean for the different types of article boards, like History (etc.) and Math (etc.), or just for discussions within a topic, like within History? Psalm84 (talk) 05:40, 1 November 2012 (UTC)

Tranclusion would require that each discussion occur in a sub-page, the problem with a transclusion based solution is that it makes watchlisting a pain, as you wont see comments in your watchlist just because you have the talk page or noticeboard watchlisted, you would only see the one time transclusion of the subpage. This could result in concerned editors being blindsided when a consensus is reached on a topic they are interested in, and they missed the one watchlist change that signified it starting. More generally, the mechanics pose a couple problems, first it would make it harder to start an RFC, you will no longer be able to just throw on an RFC tag, but will need to set up multiple transclusions and the sub page.

Yet a non-transclusion approach has even bigger problems. Say I want to hold an discussion about something in the article Ben Bernanke, who falls into at least bio, econ and politics. Which noticeboard gets the discussion? I can imagine there being disputes over venue, turf wars, or gaming to try and get the discussion to the noticeboard deemed most favorable. The whole thing seems like a giant can of worms, and I'm not convinced the goal, getting more discussion for obscure topics, would have any more luck at a notice board then via the current RFC system. Monty₈₄₅ 05:54, 1 November 2012 (UTC)

I agree about the transclusion approach. I don't suggest that. On gaming and turf wars happening, no offense, but don't they happen already? To some extent that just seems impossible to avoid with anything. On what board to put a topic like Ben Bernanke, with only 10 boards, there could be a way to put a notice of something that might be of interest on the other boards besides the one chosen, for example, or to cross-post them. What the dispute is about, too, might help, like if it's more about economic policy, or more something about Bernanke's personal life. But cross-listing or cross-posting probably wouldn't involve too many categories, and in some cases if it brought editors from a few categories that actually seemed involved in the matter, that could be beneficial. There also aren't really that many RFCs, too, and this isn't to replace the talk page, as I said, so that would seem to keep it simpler than if there would be hundreds or even thousands of discussions going on these boards. That would be very confusing. Psalm84 (talk) 06:19, 1 November 2012 (UTC)

I too withdrew the transclusion suggestion, so that is off the table. I don't think cross-listing, which was what I was referring to earlier, is much of a problem. Editors can just pick a "host" board, and cross-link from other boards they think should be involved. That is no worse than the current situation where the "host" board is the article talk page and all RFC boards have just links. If editors can't agree on a "host" board, they could default to existing behavior: host on a neutral (say article's talk) page and cross-link from everywhere else. Based on my experience of editing far more in article space than in project or talk space, I would say scenarios where article editors can't even agree which the primary board for an RFC should be are rare. Churn and change (talk) 15:27, 1 November 2012 (UTC)

What I'm wondering about is what to do next about this proposal. Is it best to just keep taking more comments about this here, or should this be posted elsewhere? Psalm84 (talk) 04:17, 2 November 2012 (UTC)

I think you should leave it here for a while and then take it to

WP:RFC and so that article's talk page seems the best bet. Churn and change (talk

) 04:31, 2 November 2012 (UTC)

Okay, I'll do that. Thanks. Psalm84 (talk) 04:32, 3 November 2012 (UTC)

LEAVE AS IS

Community in favor of number 1, our current design.—

^Chat

_Online 18:14, 3 November 2012 (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 entirely satisfied with the outcome of this previous discussion, and would like to seek wider input. So all of you kindly pick one of the following. Thanks. -— Isarra ༆ 01:38, 23 October 2012 (UTC)

To clarify, the issue with the current was that it forces the box itself onto a new line, taking up space and moving all the buttons even further down than they were already. Shortening that by moving the explanation into the tooltip would put it all on one line, making the interface easier on anyone using a smaller screen. -— Isarra ༆ 06:33, 23 October 2012 (UTC)

Label variants
1. Edit summary (Briefly describe the changes you have made) 2. Summary of changes: 3. Edit summary 4. Edit summary 5. Edit summary 6. Edit summary:

• Number 1, which is the current state. This offers the most lucid description, as it tells the reader immediately in plain words what is requested. Those who need more guidance can click the wikilink that leads to an elaborate help page. I don't see any need to fix this, as it is not particularly broken. --Mareklug ^talk 01:44, 23 October 2012 (UTC)
• I agree with Mareklug. The blurb explains what an edit summary is, which is plenty for most people. Forcing people to jump away from the edit page to learn about an edit summary breaks the workflow of saving the page.
  1217 ^{What I've done}
  04:05, 23 October 2012 (UTC)
• Number 1 is my preferred label. There's no reason to hide a pretty straight-forward blurb away from the viewer. Total agreement with Mareklug that this is a "if it ain't broke, don't fix it" type of situation. EVula // talk // ☯ // 05:02, 23 October 2012 (UTC)
• Number 1, same as I said on IRC -- I think that clearly explaining what on earth an edit summary is is quite important... not just leaving a link which would theoretically take readers away from actually being able to save their edits (not that it doesn't already do that... but at least the explanation keeps some people from clicking, whereas now every new editor would be clicking.) Alright, that was a ramble. Theopolisme 10:56, 23 October 2012 (UTC)
• Number 1, but increase the font of "(Briefly describe the changes you have made)" There is a lot of space wasted above the entry box and there seems to be room for both
  Edit summary and the description of what to do to be of the same size as the label inside the edit box. I see the insertion help is back, not sure where or why it had disappeared to for a while, but I simply went back to typing in <ref by hand in the meantime. Apteva (talk
  ) 12:51, 23 October 2012 (UTC)
• Number 1, as it's the most clear and direct. I do not think that having the full statement there adds clutter or is particularly cumbersome in terms of the interface.
  bot
  !) 13:26, 23 October 2012 (UTC)
• Number 1. Tooltips are notorious for not popping up - especially on slower connections.Kudpung กุดผึ้ง (talk) 22:29, 24 October 2012 (UTC)

  This is not implemented in js as some tooltips are, but merely uses the html title attribute. It would not be affected by connection speed unless the entire section of the page has neglected to load, at which point it would be rather moot anyway. -— Isarra ༆ 23:41, 24 October 2012 (UTC)

  And the editors using textual browsers such as

  elinks? What tooltip-equivalent do they get? As, I believe, and please correct me if I am mistaken, they get no tooltips. --Mareklug ^talk 23:48, 24 October 2012 (UTC) P.s "Tooltips don't appear on mobile operating system, since there is no cursor." says our article Tooltip. --Mareklug ^talk

  23:59, 24 October 2012 (UTC)

  Textual browsers get the tooltip instead of the image, and mobile ones are neglected and get a link. -— Isarra ༆ 20:31, 27 October 2012 (UTC)

• Number 1, it's the most friendly to all types of users (newcomers, users on slow computers, mobile users, users using textual browsers, blind users using screen readers, etc) I can't imagine any user getting the edit screen and not seeing the explanation. עוד מישהו Od Mishehu 09:22, 30 October 2012 (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.

Add a voice button option to the editing of peoples and places articles just for having a voice saying correctly the name of the person or place in the in the relevant accent of specific country this name came. This simple feature will help Wikipedia's users recognize and link more easily when a topic on which they had read in Wikipedia comes out in a talk, a lecture, TV and so on.

Good luck, Adam. — Preceding unsigned comment added by 89.139.148.255 (talk) 10:01, 3 November 2012 (UTC)

Yes, this is done in the first sentence of Paris and many other articles. Perhaps someone should vigorously promote the practice. Jim.henderson (talk) 10:17, 3 November 2012 (UTC)

See this relevant blog post by Andy Mabbett. Graham87 12:05, 3 November 2012 (UTC)

I suspect that we all know that edit conflicts suck. I've lost hours of work due to edit conflicts, and that's despite me being fairly adept at copying and pasting to resolve them. I think that the system could handle edit conflicts much better, and that this site would be a nicer more productive place if we had better ways to minimise edit conflicts and recover from them afterwards. If anyone could measure the proportion of newbies who'd had an edit conflict in their first ten edits I bet A it would be high and B it would be a good predictor of people who go away because Wikipedia bit them. I've raised a bugzilla request including several possible minor improvements, such as defaulting all new pages created in mainspace to include

==references==

and

{{reflist}}

OK you'd be deleting those lines each time you created a redirect or dab page, but deleting them is quicker than typing them, it might prompt some newbies to actually add references, and it will prevent edit conflicts between people categorising new articles and others adding sentences.

Another easy fix would be to disable the edit button for very busy articles. Experienced editors already know that if a page is going to be busy you edit a section and you don't try to edit the whole article. So to reduce edit conflicts on "trending articles" and very busy pages such as Jimbo's talkpage, the system needs to automatically notice which articles are busy and when anyone clicks the big edit button at the top of a busy page render: "Sorry, but this page is currently very busy, so to reduce edit conflicts you can only edit one section at a time. Please pick the section you want to edit", then give them a choice of sections.

In an ideal world we'd can things like the article feedback clutter thing and focus some serious development on this. I'd like to see a whizzy system where when I had an edit conflict it showed me the result of my edit and the intervening one and gave me an option to save the consequent combined edit. However I don't know the capabilities of the system well enough to spec that. But there are several small and hopefully uncontentious changes could be easily coded and which in combination would greatly reduce edit conflicts. ϢereSpielChequers 16:54, 25 October 2012 (UTC)

Note that disabling the edit button for very busy articles would do exactly nothing: when you submit an edit to a section, MediaWiki takes the revision that you started editing, replaces the one section, and then proceeds as if you had edited the entire page and just happened to make changes only to the one section.

Similarly, there is not really any way for MediaWiki to show you what the consequent combined edit would look like. If MediaWiki is able to combine the edits, it already automatically does so and saves the combined edit without ever bothering to tell you. An edit conflict happens when MediaWiki cannot figure out the combined edit because your edit and the other person's edit changed the same area of the page, so it would have to basically throw away one or the other. Now it's possible that the merging could be made smarter somehow (I haven't looked too closely, but at a glance it looks like it just uses diff3); that's probably your best bet for improvement. Anomie⚔ 18:42, 25 October 2012 (UTC)

I should clarify one thing: there are a few other situations that might cause an "emergency edit conflict", e.g. if two edits come in at almost the exact same time such that one gets saved in between the other doing the check for edit conflicts and it actually writing to the database. But that won't be helped by anything besides shortening the time between the first check and the final save. Anomie⚔ 18:49, 25 October 2012 (UTC)

If you try to edit three sections of a busy page as three separate edits you are much less likely to get an edit conflict than if you edit the whole page and try to save an edit that involves changes in multiple sections. So yes directing people to individual sections will make a difference, maybe not for the people who just want to change one or two words, but then they don't lose so much when they get an edit conflict. If there is already a bit of smart merging taking place then that's great, but we need more of that and smarter. For example the software should be able to recognise that one person adding a template and a link in a see also section and another adding a category are not incompatible merges, we just need to improve Mediawiki to handle more edit conflicts without losing edits. This is important, when did you last get an edit conflict in Facebook? ϢereSpielChequers 21:19, 25 October 2012 (UTC)

Facebook doesn't have anything that could conflict. I would suggest Google Docs though.—

^{Trick or Treat}

23:08, 25 October 2012 (UTC)

I believe the team with

Apart from a vague commitment to improving the workflow, their main approach is still to tell people that an article is being edited. This is better than the thankfully abandoned proposal they made during newpage patrol to allow anyone to stop others editing an article simply by opening it in an edit window. But I don't believe that there would be much benefit, and there could be various disbenefits including greater complexity to the editing interface, an easy opportunity for trolls to cause edit conflicts by doing quick minor edits to articles they knew to be being edited, or alternatively if they went back to their previous idea of "reserving" articles, the spammers would quickly learn to create and immediately reopen it for editing so as to keep their spam up longer, even goodfaith editors would be tempted by the idea that you no longer need to edit just one section if you can reserve the whole article to yourself, and consequently some of our most heavily edited articles would suddenly become much harder to edit. As for my proposals, feedback I've had so far on Bugzilla includes that simply having the software recognise each thread starting with a hash as a separate paragraph would be easily done and would greatly reduce edit conflicts on talkpages. I'd like to get much more change than that, ϢereSpielChequers 22:51, 26 October 2012 (UTC)

• Support first part: Adding "References" and reflist in all new articles is a good idea! Most probably I saw a post somewhere else where it was suggested to appoint a bot to do the task! Nut, new users (some users) may not understand that they need to delete those if they are creating a dabpage and redirect! So, a note too? Or it'll be too complex? --Tito Dutta (talk) 05:04, 5 November 2012 (UTC) typo correction not → note signed --Tito Dutta (talk) 05:10, 5 November 2012 (UTC)

To avoid edit-conflict, re-edit+merge+save

See essay: "wp:Avoiding edit-conflicts" (wp:AEC)

After years of few improvements, I finally deduced the solution, for an experienced editor: proofread changes separately (2nd window), then re-edit, merge and save. It is just that simple, as if an editor could edit, write, and save all within 15 seconds. Now, the recent exception has been a bug that causes a "ghost edit-conflict" when no other editors are actually there. However, remember this simple 4-step fix:

• STEP 1: Edit a section to prepare/proofread the updated text for merge.
• STEP 2: Re-edit the section (if gone, review the whole page).
• STEP 3: Merge the proofread text into the re-edit window (quickly).
• STEP 4: Save as rapidly as safe, for your level of confidence.

It might be difficult to believe that years, of endless edit-conflicts, can be solved simply by re-edit & merge, but the reality is that a 15-second re-edit timeframe is often enough to avoid the conflict. I wish you Happy editing in the future. -Wikid77 (talk) 00:53/02:00, 27 October 2012 (UTC)

Good idea. -Fjozk (talk) 16:29, 31 October 2012 (UTC)

I would like to suggest that "Spoiler" Alerts be posted at the heading of articles which summarize the plot of newly released films. I am a producer of "Skyfall" a film that was recently released in Europe but will not be released in the USA and other places until November9th. The entire plot of the film is set out in the Wikipedia article on the film. Even though the film has been seen and reviewed by hundreds of journalists none have disclosed certain elements of the story so as not to spoil the audience's enjoyment of the file.

My suggestion is that an notice be posted at the head of the article on Skyfall alerting the reader that the text includes spoilers. Michael Wilson — Preceding unsigned comment added by Mike90290 (talk • contribs) 08:21, 2 November 2012 (UTC)

• Duplicate posting removed. --Philosopher ^{Let us reason together.} 08:24, 2 November 2012 (UTC)

Thank you for your comment. You might be interested in Wikipedia:Spoiler, which details why we don't have spoiler warnings on Wikipedia. If you would still like to propose that Wikipedia include spoiler warnings, it would be best to address the issues discussed there. --Philosopher ^{Let us reason together.} 08:30, 2 November 2012 (UTC) revised post

Looking at http://en.wikipedia.org/w/index.php?title=Template:Spoiler&action=history it shows the talk page was kept at Wikipedia_talk:Spoiler/old_template_talk. Looking at the header of that page becomes clear that there was an RfC leading to the deletion, a subsequent DRV sustained the decision.LeadSongDog come howl! 13:33, 2 November 2012 (UTC)

Right, there's been (correctly, imo) a fairly solid consensus since the end of 2007 that spoiler warnings should not be used on Wikipedia. Which is why I pointed him to the Spoiler essay: If he wants to try to change that consensus, he's going to directly address those points. --Philosopher ^{Let us reason together.} 14:42, 2 November 2012 (UTC)

If someone doesn't want to be spoiled by the plot of a movie...then they shouldn't read the section called "plot". ♫ Melodia Chaconne ♫ (talk) 13:33, 2 November 2012 (UTC)

That is the thing. People who read the plot summaries are LOOKING for spoilers. A "spoiler warning" isn't going to do anything to stop them from reading the plod details and it is just a feel good CYA measure on the part of those GIVING the warnings. And let's not get started on the problem that labeling plot details as spoilers has with Wikipedia's core policies. —Farix (t | c) 14:21, 2 November 2012 (UTC)

Well, if someone doesn't want the plot of a movie spoiled, they can't read any part of the article. Spoilers are not found only in "Plot" sections.

talk

) 00:19, 3 November 2012 (UTC)

Maybe we can do the spoilers on a pay per view base. Send a dollar via PayPal to the WMF and you get the full text. Mindy Dirt (talk) 00:21, 3 November 2012 (UTC)

Is this sarcasm? If you're going to be sarcastic on the internet, you need to make it clear. Ryan Vesey 00:30, 3 November 2012 (UTC)

• No one likes it when a 19-year old tells them what to do. Mindy Dirt (talk) 14:12, 3 November 2012 (UTC)

It seemed like a great fundraising suggestion. I was recently amused to see at the end of an old black and white movie the request to all patrons to not reveal the details of the plot to anyone - this is a movie that came out what over 50 years ago now? There are some movies, that not knowing a plot twist severely changes the viewing experience, but those are very few. Apteva (talk) 00:38, 3 November 2012 (UTC)

Apteva, what film was that? Does it have a Wikipedia article?

csdnew

11:03, 3 November 2012 (UTC)

We do have an article for the movie - Witness for the Prosecution (1957 film). It ends with the voice over during the credits at the end - "The management of this theater suggests that for the greater entertainment of your friends who have not yet seen the picture, you will not divulge to anyone the secret of the ending of Witness for the Prosecution." Apteva (talk) 14:38, 3 November 2012 (UTC)

Absolutely not. We should

not be censoring Wikipedia as a scheme to raise funds. —Farix (t | c

) 09:54, 3 November 2012 (UTC)

Might have been The Mousetrap. There was coverage in the news over how Wikipedia gave away the answer. Legoktm (talk) 10:55, 3 November 2012 (UTC)

I doubt that it's

csdnew

11:03, 3 November 2012 (UTC)

Sounds like Witness for the Prosecution (also based on an Agatha Christie story).Nigel Ish (talk) 11:56, 3 November 2012 (UTC)

Good call. Apteva (talk) 17:18, 3 November 2012 (UTC)

So basically, no. We won't bring back spoiler warnings, and that's for the best. Apart from the fact that

csdnew

10:28, 3 November 2012 (UTC)

Will you be having spoiler warnings added to Ian Fleming's books? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 3 November 2012 (UTC)

• This is all very interesting, but if no journalist has published the details of the plot, how can Wikipedia do so without using
  WP:OR? --R'n'B (call me
  Russ) 02:05, 4 November 2012 (UTC)

When a film is released to the public, it is affectively published. —Farix (t | c) 02:11, 4 November 2012 (UTC)

RnB has a good point. The movie is a primary source, but not verifiable other than by paying to see the film. I would guess that most of our plot spoilers could be deleted as lacking a reliable source. Witness for the Prosecution offers not a single reference for the plot section, or for the voice over in the disclaimer section. Once a film is released, it is published, but normally our articles should be based on published reviews, and not on the personal experiences of editors who have watched the film. For books, the plot summary of Gone with the Wind (rated C class) is annotated with the page numbers where each appears, using the book as the reference. To Kill a Mockingbird, an FA, offers no page references for the plot section. I would actually think that page numbers could change from one printing to another, though. All of the Ian Fleming books I checked are GA, and none use references in the plot or synopsis section. Some older books are available online, either from Wikisource or from project Gutenberg, and are easier to verify. Apteva (talk) 21:03, 4 November 2012 (UTC)

• IMO if the owner of the book, movie etc [The writer or the producer, in this case] chooses not to reveal the plot of the entire movie, he or she has a right to preserve the plot in any way they deem satisfactory [or by someone else in accordance with their wishes]. Although Wikipedia no longer allows spoilers, this can also been done in a number of other ways, like page blanking [or simply removing the plot portion] (for a specified period of time, in this case) or to say the entire plot but let the twist not be given, and be worded as 'The story ends in a twist of plot' along with any other necessary phrases. It should also be protected or semi-protected, as necessary, to preserve the sanctity of the article as is.
  talk
  ) 15:56, 4 November 2012 (UTC)

"he or she has a right to preserve the plot in any way they deem satisfactory"... up until the movie is publicly released at which point that "right" is gone; the cat's out of the bag. --MASEM (t) 16:08, 4 November 2012 (UTC)

I agree, when the piece of media (book,play,film) becomes publicly released I believe that any privacy or secrecy rights to the ending are long since lost. I also don't agree with the OR claim since basic analysis of a work of fiction is permitted and unless complex or subjective analysis is necessary we don't need a source to say how the film ends. Regarding subjective analysis, we would not be able to say that the ending of a film is a representation of the battle between good and evil in the human soul without either a secondary source making that analysis or someone involved in the film (directer, producer, etc) stating that was their intention with the ending. We can, however, describe the noninterpretative events (who said what, who did what etc) and would not need a secondary source to cover that. For a more concrete example, using the Mousetrap's twist ending mentioned earlier, at the end of the play the murderer directly identifies themselves as such so it would not be OR to state that they are the murderer since it was directly confirmed by the character and not a subjective opinion of a person watching the play.--174.93.171.10 (talk) 21:02, 4 November 2012 (UTC)

I don't buy this (although this is getting off-topic, which is my own fault). You can't write a plot summary without making judgments as to which elements of the plot are the most significant and which are incidental. Should the plot summary mention what color shirt Bond was wearing in the pivotal scene? You might say that's not important, but that is a judgment call that seems to me to be pure

WP:SYNTH. --R'n'B (call me

Russ) 21:23, 4 November 2012 (UTC)

I don't agree with that. WP:OR specifically says A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the source but without further, specialized knowledge. For example, an article about a novel may cite passages to describe the plot, but any interpretation needs a secondary source. Using the mousetrap for example, stating that the person was the murderer when they specifically said that they were would be something obvious to anyone with basic English comprehension and knowledge of what the term murderer meant. That would not even be remotely close to specialized knowledge.

WP:OR will likely be strongly rejected.--174.93.171.10 (talk

) 21:55, 4 November 2012 (UTC)

I prefer citations to third-party sources for plot summaries myself, but I have been shot down time after time. A good example of this problem is a hypothetical plot summary of

The Wizard of Oz:"Young Kansas girl is transported to a land where, after killing the first person she encounters, she teams up with three misfits to stalk and kill again". Absolutely accurate, but completely misses the point. That said, general consensus is that the plot of a work can be sourced to the work itself, so long as the description is straightforward and lacking in value judgements.—Kww(talk

) 22:00, 4 November 2012 (UTC)

Hey folks. Many of you here participated in this discussion, so I thought I might give you an update. Given the wide consensus for the implementation of some syntax highlighting by default (per the

• Closed as "WONTFIX" - says that this can be done by any local admin - Wikipedia:Gadget#Default_gadgets Apteva (talk) 21:09, 4 November 2012 (UTC)

Greetings, it must have been suggested already since I don't think I am the only one looking for this option! Is it possible to add a Dismiss/Close/Hide link in "You've new messages" banner? I personally get talk page new message notification through Google Talk (email notification → new email pop up). I don't need the banner very often. The worst part is it does not go until you see the message and thus it forces you to see the new message! --Tito Dutta (talk) 05:20, 5 November 2012 (UTC)

I propose that we add microformat-style HTML class names to citation templates, to improve their machine readability; please see Proposal: citation microformat and discuss there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 5 November 2012 (UTC)

Hi. I've started an

Many articles (especially the most important ones) are terribly, overwhelmingly long, and you can't separate the wheat from the chaff without wasting several hours to read all details you are not interested in. Why can't we add a scroll bar, which will allow to adjust the size of the article to the user's needs? Let say, it has 5 positions, with 1 corresponding to a brief overview of ~300 words, 2 to ~1000 words, 3 to ~3000 words, 4 to ~10000, and 5 corresponding to a dedicated article of ~30000 words (for small articles only the first one or two positions are available.) All these 5 articles can be stored separately under different names (let say, Article_name, Article_name_2, ..., Article_name_5), can be edited separately, can be separately nominated for good and featured articles etc, though probably in most cases article of the kind n will be written as an abridged version of article n+1. Of course, it'll be a big effort to write such shortened versions, but if we succeed to do it for at least 10000 most important articles, it'll substantially improve the efficiency of Wikipedia for most users. This doesn't even need any new features to be programmed (the scroll bar is a fairly plain template), only the political will to allow and standardize creation of such articles. Oleksiy.golubov (talk) 20:27, 1 November 2012 (UTC)

Are you volunteering to write the 40,000 additional articles that "succeeding to do it for at least 10000" would entail, not to mention coordinating the four additional rewrites that would be required every time any of the five versions was changed? People seem much keener to think of solutions than to volunteer to put them into practice.

If you want "edited highlights" versions of Wikipedia articles, Qwiki is probably what you're looking for. Mogism (talk) 20:32, 1 November 2012 (UTC)

The point is that if we don't have this feature for most articles, it's not a problem at all, the users will just read the full versions. But if we have the feature for some articles, it's already useful. So I'm just suggesting to allow this feature. Of course, I'm volunteering to write 20 or 50 shortened articles on the topics I'm working on, as I think many other specialists will volunteer to do for their topics if we give them such an opportunity. I mostly write articles in Russian Wikipedia, but I decided first to discuss this idea here, as English Wikipedia is usually the first to implement innovations. I know English Wikipedia rather as a reader, than as an author. But sometimes when reading English Wikipedia (especially on USA-related topics) I have to switch to other languages, where the articles are shorter. Oleksiy.golubov (talk) 20:59, 1 November 2012 (UTC)

Scroll-bars are variable, implying a continuous range, not just four or five or even fifty pre-set sizes. The only practical way of implementing that is some process that dynamically scales articles. Which likely requires kinds of linguistic processing not yet attained. Alternately, if for some number of articles you wanted a shorter version, well, perhaps there could be some sort of name-space suffix (like "~1"?) that could be used to distinguish alternate versions of otherwise identical names. Then there could be a "Shorter version" info box that connects to the next version. And then all that is needed is ten- or twenty-thousand rewrites. ~ J. Johnson (JJ) (talk) 21:29, 1 November 2012 (UTC)

No, it's too complex. Maybe, you were mislead by the term "scroll-bar". I should better have said "a Wikipedia template slightly resembling a scroll-bar and having 5 positions". I think 5 sizes with the step factor of 3 are enough, but this must be discussed further. Oleksiy.golubov (talk) 21:41, 1 November 2012 (UTC)

Have you looked at the simple English wiki for corresponding articles? Not belittling your clearly good command of English, but my impression is that those articles tend also to be shorter. That is only one alternative but might either be enough or serve as an introduction to the :en: article. --Mirokado (talk) 21:58, 1 November 2012 (UTC)

Well, it's possible to go to simple English or Russian, or if I want an even shorter introduction to go to Ukrainian. But I'm proposing to do it more systematic and flexible. Am I really the only one who reads Wikipedia several hours per week, but has never finished reading any featured article because they are too detailed? And who, when supplementing articles, thinks: "Well, what I'm adding is very interesting for a real geek, but it'll only distract a non-specialist. So what should I do?" Oleksiy.golubov (talk) 22:15, 1 November 2012 (UTC)

If you're dealing with articles at Featured Article level - which seems to be your suggestion - the

lead section is a summary of the article, so if you only want an overview just stop when you reach the Table of Contents. Aside from a very, very few highly technical topics where a "layman's version" makes sense, your proposal would literally make Wikipedia five times more difficult to maintain, since what you appear to suggest is manually writing five separate versions for every one of our 6,814,095 articles. Mogism (talk

) 22:24, 1 November 2012 (UTC)

Yes, a level 1 article roughly corresponds to the Introduction section of a level 5 article, but there's a huge uncovered space in between. The experience of "layman's versions" is really very valuable, and I'm just proposing to use it more extensively. I think that using simple English or patching the worst gaps with "layman's versions" is just a partial solution of the problem, and it's time to do the next step. Most articles are short, so I don't expect that my suggestion could touch more than 3% of all articles, and such shortening is indispensable for much less than 1% of all articles. Of course, even they will require much effort to be re-written. And I think these are editors who must decide whether an article should be abridged or not, and thus vote with their work for or against my proposal. I'm just proposing to give them a possibility to decide. Oleksiy.golubov (talk) 23:04, 1 November 2012 (UTC)

If a version suffix is used: the main version should be the unsuffixed form of the name ("<name>"). I would expect this to be the fullest, most complete treatment of the topic. Alternate versions, whether only one, or five, start at "suffix 1" (e.g.: <name>-1), the first version being the least different from the main version. If direction of the numbering (increasing) seem wrong, just consider it as proportional not to size, but to increasing shrinkage. ~ J. Johnson (JJ) (talk) 00:40, 2 November 2012 (UTC)

We can develop some naming standards, with the suffix number depending on the article size but independent of the total number of versions. E.g. there can be "<name>-1" and "<name>-3", without "<name>-2" which may or may not be created later. The "scroll-bar template" in the top of each version will show what other versions are available. The article "<name>" can be replaced by a redirect to one of the versions (additional recommendations are needed to specify which one). But the majority of articles will probably stay forever as a unique version called "<name>", without any counterparts or redirects. Oleksiy.golubov (talk) 01:27, 2 November 2012 (UTC)

Featured articles often also have a summary article that is used either on a portal or on the main page. It is possible that some sort of link to that summary (or to those summaries, but there really only needs to be one) could be created. Compare Portal:History/Featured article/13 with Wikipedia:Today's featured article/October 8, 2009 and Plymouth Colony. Apteva (talk) 23:29, 1 November 2012 (UTC)

Ha, I've never thought about that. But even more important are longer versions (intermediate between the abstract of a featured article and the whole article), and a simple interface to show to the reader that these versions are there. Oleksiy.golubov (talk) 23:47, 1 November 2012 (UTC)

Isn't this what the

Yes, the lead is for this, but for many purposes it's not enough. Sometimes you want a brief definition two phrases long, "a lead of the lead", but instead you are made to read a big overdetailed lead 3 paragraphs long. Sometimes you want some more details than are given by the lead, and would like to read something 5 times longer than the lead but 5 times shorter than the whole article, and you don't have this possibility either. Oleksiy.golubov (talk) 14:01, 3 November 2012 (UTC)

I support this idea. I often go to Simple English when I want a quick idea of something, since the introduction sections frequently don't give me what I want -- yet sometimes SE does. So, yes, for some articles this is a good start, but Oleksiy is correct that for some of our monster articles there is a mid-level (or levels) that are missing. Many's the time I have looked for general information beyond the absolute basics that amount to little more than a definition, and have simply given up on Wik/en and gone to Spanish or German or simply left Wik altogether and found my answer through Google or Britannica. I had never heard of Layman's versions. I went to the link but then when I went to the relevant regular article (I chose the first one, on algorithms), there was no readily visible indication of a layman's version existing. Of course, how to bell the cat is an issue, but I don't think we should throw out the baby just because it will be a big project: there are a lot of "who"s out there. Maybe we could add a tick-box to the set present on some Wik articles about the quality of the article. The tick-box could ask if the reader felt the need for an intermediate version (or versions). The articles so ticked (either at all or a certain number or percentage of times) could go to a lisst that we could look at just like the lists for speedy deletion and recent new articles.Kdammers (talk) 05:56, 5 November 2012 (UTC)

I'd propose a more straightforward program. 1) If the idea finds some support here, it can be put to request for comment. 2) If the idea is approved and elaborated there, we can start a project, which will aim at re-writing several hundreds articles, where this re-writing is the most necessary (~300 countries and states, ~300 cities, ~300 persons, ~100 historic events, ~20 planets and satellites). 3) As these are simultaneously the most visited articles, soon (after just a few such articles are re-written) everyone in Wikipedia will know about the feature; and if the society likes the idea, we can expect that many authors would like to invest some amount of their work in re-writing their favourite articles, both the ones mentioned in the project and the ones which are not as long and not as frequently visited. There are many "if"s, but even if the project has only a partial success, it'll still be useful. Oleksiy.golubov (talk) 14:19, 6 November 2012 (UTC)

This is a bad idea. This has the potential for serious contradictions and conflicts between the versions. It would require far too much extra work and coordination between them. I see no problem with long articles, in fact, most topics have far too little info. If you have a problem finding info you are looking for, it may be better to organize the info within an article better and add more subheadings. -- P 1 9 9  ✉ 15:03, 9 November 2012 (UTC)

I concur. ~ J. Johnson (JJ) (talk) 20:59, 9 November 2012 (UTC)

If the differences between the versions are non-essential, but the articles are organized differently, have different illustrations etc., then it's not a problem at all. If instead the differences are more fundamental, then it's better to have two contradicting versions and to know beforehand that we must doubt them both, than to have only one version and to rely on it, without knowing that all possible biases are still there. So creation of shorter versions of articles can't make any new problems beyond the problems of objectiveness and truthfulness, which are still there in Wikipedia anyway. Contradictions between the abstract and the body of an article are also possible, as well as contradictions between different chapters of an article, but it's not an argument to avoid chaptering articles at all. Oleksiy.golubov (talk) 21:23, 10 November 2012 (UTC)

I moved this discussion to "Idea lab". Please go there if you want to continue the discussion.Basemetal (talk) 18:15, 10 November 2012 (UTC)

Okay, but could we have link? ~ J. Johnson (JJ) (talk) 00:17, 11 November 2012 (UTC)

• Wikipedia:Village pump (idea lab)#Average size of article by Wikipedia? (was Wikipedia:Village pump (idea lab)#Average size of article by Wikipedia? (Moved from Proposals) Apteva (talk) 05:45, 11 November 2012 (UTC)