Wikipedia talk:Requests for comment/Reforming dispute resolution

No to javascript

Some editors do not use javascript (for various reasons).

The DR process should NEVER rely on JS. - jc37 18:27, 24 September 2012 (UTC)

Agree, but it should not rely on gerrit either. ~~Ebe123~~ → report 20:00, 24 September 2012 (UTC)

The new wizards will actually be coded in HTML5 - I'm not exactly sure how that works, but a volunteer developer is coding it and it looks good so far. Steven Zhang ^{Help resolve disputes!} 20:06, 24 September 2012 (UTC)

Hope it's open-source that we can edit. ~~Ebe123~~ → report 20:10, 24 September 2012 (UTC)

Normal users will have JavaScript enabled in their browsers. Every single browser in common use, mobile or desktop has good support for JavaScript.

The only users who might not have JavaScript enabled on their browser are geeks who are perfectly capable of enabling it for Wikipedia if the dispute resolution process requires it - and they make up a tiny fraction of the community. -- Eraserhead1 <talk> 20:56, 24 September 2012 (UTC)

Steven Zhang - HTML5 is heavily Javascript-based. HTML 5 does not have programmatic functionality by itself. It only facilitates JS by providing a document object model.--v/r - TP 21:07, 24 September 2012 (UTC)

Yeah, that sounds about right, its not realistically going to be possible to do a good job without JavaScript. -- Eraserhead1 <talk> 21:09, 24 September 2012 (UTC)

Eh, HTML is something I know how to write far better than js. :) Szhang (WMF) (talk) 21:59, 24 September 2012 (UTC)

While I strongly agree with the notion that JS should not become required, I think there is a way to avoid it – the wizard may be constructed so that with no JS it is simply a set of links to preloaded edit links (with "case" templates substituted to the target). Such layout would help people like me (I use lynx as a primary browser). — Dmitrij D. Czarkoff (talk•track) 23:41, 24 September 2012 (UTC)

It's silly to say that HTML5 is good and JS is bad, when both are standards, and JS probably has a much higher adoption percentage than HTML5. Gigs (talk) 21:21, 24 September 2012 (UTC)

@Eraserhead - you are absolutely wrong about that (sorry). For example, I know for fact that some businesses by default turn off javascript for (additional) security reasons and/or because it is presumed "unneeded" for employee internet use by the "powers-that-be" in some businesses. And that not taking into account people at home or on the move who turn JS off because it may affect their browsing speed, or system "hangs", or even to reduce bandwidth drain, etc. Besides that, "normal" is such a weasely word that, I don't think I need to comment on it further.

Regardless, on Wikipedia, JS things are optional, and never necessary. - jc37 23:20, 24 September 2012 (UTC)

I'm sorry, JavaScript is essentially required to use the internet in 2012. Everyone has been going on about iOS 6 maps recently, but seriously you can't use Google Maps at all without JavaScript. You can't use Facebook either. I can't even view my messages without JavaScript, or 'like' something.

I also don't really think security or any of the other reasons are really particularly strong arguments - especially given how much of the internet doesn't work properly without JavaScript. In fact using AJAX will use less bandwidth - and that is JavaScript only.

Wikipedia has gotten away without requiring JavaScript so far but that means it has delivered a significantly subpar experience with a 1990's design as doing anything more sophisticated requires JavaScript. -- Eraserhead1 <talk> 07:25, 25 September 2012 (UTC)

First, we're not google earth etc. second, you can complain about a business's choice, but regardless, their practice affects those Wikipedians who read/edit from work. So your opinion on that is a moot point.

Besides that, the internet actually does work just fine without JS.

And by the way, there are LOTS of ways to do things on the internet. (And I'm guessing you're not blind, nor have such accessibility issues.) The point above concerning the lynx browser is well taken.

To me, you're sounding like those who complain about how Steve Jobs refused to add flash to the iphone. "But we need it..." As it turns out, we really don't.

And I suppose you're welcome to consider Wikipedia a "subpar" experience due to the lack of javascript (though when I look at the long list of gadgets etc under preferences, I may disagree with that assertion), but honestly, all I hear in your comments is "IWANTIT".

Just because you want it, and you feel it's necessary doesn't make it actually necessary. (See: Mind projection fallacy.)

And by the way, as we're a volunteer project, it might just possibly be a good idea to make sure we're inclusive, rather than de-inclusive. - jc37 16:45, 25 September 2012 (UTC)

The problem with your Flash analogy is that it was primarily only used for video and games, and Youtube had an app on the iPhone on day 1. Additionally it took Adobe 3.5 years from the announcement of the iPhone to actually release a version for smartphones at all. If Adobe had actually released a version of Flash to mobile sooner they'd have made it very difficult for Apple.

With regards to accessibility, that is important, but I really don't think it is incompatible with JavaScript. Additionally with regards to Lynx, well it only has a 0.02% share on WikiMedia, I really don't see why we should go out of our way to support it.

With regards to why we need it, well it seems like Steven's volunteer is using HTML 5, which basically guarantees that the design will be using JavaScript. -- Eraserhead1 <talk> 20:28, 25 September 2012 (UTC)

None of your comments refutes that the internet does not "need" JS, and neither does wikipedia.

And remember that we are not a "for profit" business. Seemingly "popular" toys like JS are not necessary for us to continue the project at all.

And remember: This is DR we're talking about. So we should not have any reason that it should require anything more than any editor needs to edit. To do so would potentially be disruptive of the DR process. - jc37 22:12, 25 September 2012 (UTC)

Whether Wikipedia is a "for profit" business or not is irrelevant. We still have to deliver a good user experience to keep and gain more editors. Currently a large part of the Wikipedia experience sucks. Why on talk pages do we still use giant text areas - they suck on mobile and probably on tablets too - and mobile makes up 14% of the userbase and tablet makes up another 4% of users. And we also still use manual indenting and manual signing - which I'm sure confuse non-technical users - why can't these be hidden away behind a shiny and easy to use UI?

And back to accessibility, how is a giant text area accessible in any way at all? How wouldn't a shiny "forum style" UI be a significant improvement in accessibility terms? -- Eraserhead1 <talk> 07:44, 26 September 2012 (UTC)

The reason you are seeing so many people defend the present system is a well-studied phenomena. See baby duck syndrome and this paper from IBM explaining why imprinting on Wikipedia's current system makes change difficult. --Guy Macon (talk) 12:41, 26 September 2012 (UTC)

FWIW I browse the internet with JS off. My primary browser doesn't even support JS. That isn't related to baby duck syndrome: JS is mostly used for building custom UIs and other stuff that only makes the internet less user-friendly. — Dmitrij D. Czarkoff (talk•track) 13:17, 26 September 2012 (UTC)

But you use a default browser that only 1/5000th of our users actually use. So your opinion about which browser you use isn't actually interesting. This also means your opinion on what JavaScript is actually useful for isn't going to be interesting either - as you are one of a very tiny minority who use a browser which doesn't support it. Its not as if I have picked an uncommon scripting language (e.g. VB script) as my example here.-- Eraserhead1 <talk> 18:10, 26 September 2012 (UTC)

So you mean that Wikipedia should spare 0.2% of editors to save a bit of processing time? Specifically when the there is obvious template-base approach with JS wizard simply translating user input to the filled-out template? Or am I missing something? — Dmitrij D. Czarkoff (talk•track) 19:06, 26 September 2012 (UTC)

Actually its 0.02%. And its a 0.02% of the population that has to have another browser installed as no sane business would ever support their browser of choice. And you are penalising the other 99.98% of the community by insisting on supporting a browser than only supports 1990's technology.

Additionally it isn't "just" a bit of server time, it is also delivering a better user experience.

Finally the whole idea of editing in a browser that is only used by 0.02% of the community is fundamentally dubious as you can't check the content you create in a normal browser to check it actually looks acceptable to the vast, vast majority of our user-base.

PS I'm sure Steven doesn't have the authority to throw out the giant text area approach we use at the moment, so if you don't want to use JavaScript you'll still be able to use them. -- Eraserhead1 <talk> 19:55, 26 September 2012 (UTC)

Where does the assertion that JS-reliant interface improvement user experience come from? Most sites on internet use it for fancy staff that is additional, and non-JS UI is provided. Why should Wikipedia be different in this? And again, what is a problem with template-based approach with a JS wizard simply filling this template out for those who want it?

That said, I actually share your sentiments about talk pages and what you call the "giant text area approach", I just see no reason why an alternative approach should require using JS as a bare minimum. Why do you want to throw people away when both your will to have heavy JS interface and my will to avoid using it may be combined with no loss? — Dmitrij D. Czarkoff (talk•track) 23:01, 26 September 2012 (UTC)

The user experience improvement comes because if you can avoid making a server side call, or make a much smaller server side call you deliver a significantly faster response and therefore basically by definition you deliver a greater user experience.

Additionally by making no Javascript a requirement you double the testing budget. So instead of just testing once in each browser you support - and that is a significant burden.

If you are doing it properly you need to test in IE 6 (maybe - depending on whether you support it), IE 7, IE 8, IE 9, IE 10, Firefox.latest, Firefox.latest-1, Firefox Extended Support Release (so 10 at the moment - but maybe you can skip this one as it is only used by 0.5% of users), Chrome, Safari on Mac, Safari on iPhone, Safari on iPad, Chrome on Android, classic Android browser, Opera for Android and Opera desktop (maybe). Then you have any automated UI tests (i.e. Selenium) on top of that - which may or may not require JavaScript.

Now obviously even if you make the flow JavaScript only you still have to handle the no-JavaScript case, but given you will just entirely hide this new UI or just put up a notice saying JavaScript is required the burden is smaller.

With regards to the code itself, well if you only want a linear form with no branching then displaying it without JavaScript should be possible. However in this case it seems highly likely that branching will either be required now, or at a later point. With JavaScript this is trivial as you can just hide the parts of the form which are irrelevant. If you branch with a serverside solution then you are going to have to make a slow serverside call each time you want to branch, and you are going to need to store the content somewhere and to handle the case where the user wanders off half way through without compromising your data. This is hard - I guess you could store it in the session, but I'm not sure how the session works without JavaScript enabled - you can't store the data in cookies as they are too small. And it is also a problem if the user wanders away for more than 15 minutes or whatever your timeout is. With JavaScript you can just store the data in the form elements on the page (but hidden) so the user can come back whenever they like and continue. I guess you have to store the data in the session while the user logs back in - but Wikipedia has to handle this anyway for normal edits.

Finally when submitting the content if you use JavaScript you can do this with AJAX, which means that even if the user spends 3 hours filling out the form then they don't get an edit conflict when they submit as you can just get the content of the page at submission time. This minimises the possibility of edit conflicts (though of course you still have to test for them).

Additionally rather than just adding a single JavaScript file (or two if you use a jQuery plugin) you have to add a lot more server-side code to handle all the cases.

And lets be damn clear I'm suggesting allowing the developer to choose to use JavaScript not because I'm obsessed - but because I want to give them the option. If they choose not to use it that is up to them and Steven. Additionally I'm really not trying to advocate JavaScript as the one true way. -- Eraserhead1 <talk> 19:23, 27 September 2012 (UTC)

• Mixing a discussion of what you want to do with what technology you want to use to do it never ends well. See Premature optimization. --Guy Macon (talk) 23:25, 24 September 2012 (UTC)
  • I agree that it may tend to bog the issue down, but I don't think it's inappropriate. People's support for the idea is going to hinge on the usability of it, and it's hard to talk about usability without at least touching on how it might be technically implemented. Gigs (talk) 13:17, 25 September 2012 (UTC)
    • And designs without JavaScript are going to struggle with usability as what you can do with it is far more restrictive. -- Eraserhead1 <talk> 20:28, 25 September 2012 (UTC)
• No reason there can't be a server-side wizard as a backup. Rich Farmbrough, 20:48, 25 September 2012 (UTC).
  
  • That would be ideal, however as we are trying to get something for free that is simple and maintainable we need to avoid making it more complex than necessary. -- Eraserhead1 <talk> 21:17, 25 September 2012 (UTC)

I'm the dev who volunteered to do the wizards (and am making pretty good progress). They'll be JS based, but they aren't really exclusive - it doesn't stop you from going to the appropriate page, hitting edit, and typing in the template yourself. As Guy Macon said, Premature optimization

To see the (currently incomplete) wizard in action, copy the lines from my common.js into yours and go visit User:Yuvipanda/Wizard/sandbox. Hitting edit on the sandbox page should show you the way data is provided to the wizard - it is wikitext augmented with some HTML5. Editors can change most of the wizard at any time without having to know Javascript. YuviPanda (talk) 12:53, 29 September 2012 (UTC)

Or type

importScript('User:Yuvipanda/Wizard/wizard.js');

It will do the same thing. ~~Ebe123~~ → report 14:26, 29 September 2012 (UTC)

Speaking of Flash, why don't we just use that? It's a streamlined and universal platform that everybody loves! Some guy (talk) 19:54, 5 October 2012 (UTC) joking

Progressive_enhancement ... Jdlrobson (talk) 21:29, 18 December 2012 (UTC)

Defining the problem and your goals

I was invited here to discuss DR with all. I see that this discussion mirrors the problems with disputes. The overall problem gets bogged down in details, agendas and distractions rather than focusing on the true problem, defining the problem well then moving to goals. I'm sorry if this offends some or many.

I have stopped even trying to help resolve disputes. The system is fatally flawed as it exists. Those that are genuinely trying to help have no teeth to actually do anything when the parties have no real interest in compromising which is often the case. There is only going to be so many disputes where polarized parties can be coaxed into agreement no matter how influential a negotiator is.

Until you can get some volunteers who are impartial, fair and working on the goal of improvement (which I believe most are) AND can actually arbitrate the dispute then you will not succeed in resolving the majority of disputes. You need judges.

I would vastly streamline the present system into a few divisions for primary dispute mediation. If that cannot be resolved over a short period of time then any party can move the dispute to a primary arbitrator who has the power to enact a resolution. I would then have a method of appeal to a panel of three volunteers who can decide to accept the dispute or not. If accepted they can quickly review the decision.

There will have to be a measured time of protection for a dispute's resolution. There will need to be a system in place to keep from flooding the system.

Keep in mind the encyclopedia will likely endure beyond our lifetimes. It will need to be able to evolve to succeed. Jobberone (talk) 12:24, 28 September 2012 (UTC)

Nice comment. -- Eraserhead1 <talk> 16:13, 28 September 2012 (UTC)

I agree. I think that the volunteers can arbitrate, but wikipedia policies make it so only GovCom can effectivly. If it were handled by AN, it would not work as well and they do not have authorization to make useful desisions. Only bans. I support having other noticeboards to be able to arbitrate. ~~Ebe123~~ → report 19:22, 28 September 2012 (UTC)

I think one volunteer as a "primary arbitrator" is going to struggle to do any better than our closing admins (i.e. not very well). I think a committee of 3 is needed as the first "arbitration" step. -- Eraserhead1 <talk> 20:22, 28 September 2012 (UTC)

Before this goes off into a huge amount of detail about how a content arbitration system ought to work, you ought to know that there have been any number of proposals floated, in varying degrees of detail, for just such a system (including one by me), but none ever seem to gain much attention, much less support. Content arbitration seems like one of those perennial proposals that never go anywhere. I don't think that lack of interest should be much of a surprise, by the way. The folks who regularly work here — the ones who work here enough to care about policy changes — are virtually all folks who have bought into the Wiki-model or else they wouldn't be here (or would not have stayed once they got here). There couldn't be anything which flies in the face of that model more than a system in which some editors have the right to make binding decisions about content over the objection of other editors. The best of the arbitration proposals attempt to soften that concern by making the arbitration process include input from the entire community, rather than just the decision of a fixed board of arbitrators, but we all also know that community decisions — for example, requests for comment and articles for deletion which are the closest thing we now have to binding content decisions — are usually only the decision of a few editors who care to weigh in on that particular matter on that particular day. My proposal tried to do both, allow for a community decision but then default to the decision of a board of arbitrators if the community did not participate, but still did not gain any traction. C'est la vie, c'est la guerre. Best regards, TransporterMan (TALK) 20:49, 28 September 2012 (UTC)

Concur, in re: fatal flaws of current process (esp. given its ridiculous only-insiders-understand complexity), and esp, on the absolute need for individuals to adjudicate. Bonne chance, with this proposal, as its elitism (says this fellow elitist) will be seen by many as contrary to (and so perhaps hinting at flaws in) fundamental principles of wikipedia. Leprof 7272 (talk) 00:36, 8 October 2012 (UTC)

I don't care how Wikipedia solves the problem nor 'whose' proposal is used. One of the problems is to take all the egos out of disputes and the resolution of disputes. I strongly believe the current system is fatally flawed. When too many people get involved with solving problems then little progress is often made. I personally don't need to be involved. I merely wish to see disputes resolved. It is damning that I was asked recently to help resolve a dispute that was ongoing for years. And the fact that this kind of proposal keeps cropping up is because many people clearly see the problem and the solution. JMO. Jobberone (talk) 11:13, 29 September 2012 (UTC)

The problem with the current system is that the only way to resolve such disputes is to take them to the Arbitration committee, and then basically the only tool they have is to ask for something to be closed as a vote. That has several flaws

• It is basically by definition slow, Arbcom have to spend a lot of time looking over behavioural issues so for disputes which are largely about content that becomes tricky.
• Editors may get blocked in "content" disputes by Arbcom who don't really deserve blocking, but who have to be blocked for the sake of progress as the processes are weak.
• The only tool Arbcom has to resolve content is to ask for things to be resolved as a vote - this is fine if the matter is truly a toss up, but otherwise it is likely to be against WP:POLICY. You can of course WP:IAR it as it is clear at that point that normal processes have failed, but that isn't ideal.

With regards to why editors aren't keen on dispute resolution, well most editors seem to go out of their way to avoid disputes. There are probably half a dozen editors who get involved in different title related disputes, and even less in other areas outside the noticeboards. If you get a dozen people to support your proposal you definitely have consensus and probably significantly lower would be acceptable. -- Eraserhead1 <talk> 09:21, 29 September 2012 (UTC)

You still have mediation before going to arbitration. The time period for mediation of a dispute can be extended to several days to allow consensus to be reached. If you can't get mediation to work then you aren't going to resolve disputes without someone deciding to get past the roadblock. Most of these disputes aren't necessary and one simple decision (usually the right one can easily be made) will resolve the dispute at least for a time. And while I would suggest the decision be protected for a time the protection should expire after a reasonable period allowing further debate. This is necessary for disputes which are genuinely difficult. Jobberone (talk) 11:04, 29 September 2012 (UTC)

I think you are probably right that the decision is often simple, I disagree partially with your point about more participants - if and only if they know about the policy and don't have a strong view on the topic under discussion. -- Eraserhead1 <talk> 18:26, 29 September 2012 (UTC)

Dispute resolution is to resolve disputes, not solve problems...

..editors work together to solve the problems of content, either during the dispute or at the talkpage. Volunteer mediators are there as structure to the discussion in a specific manner. They facilitate the discussion - aiming at a middle ground where participants make decisions on content themselves while volunteers help where needed. Understanding policy and guideline is important but just as important is understanding the spirit of collaborative editing at Wikipedia. Knowing where to ignore a guideline if it improves the encyclopedia is important for DR. Wikipedia depends on those that really do understand Wikipedia. Users are as much 'contributers' as they are 'editors' and help creat new content not just copy edit it. Some wish to contribute in moving things forward so that the project can grow. This is something that is a part of all major human resource departments in all types of different organizations. There are many ways to deal with issues, but they depend on the type of issue. Content, and conduct are many times connected, but are seperate issues. Wikipedia has to deal with conflict of interest, advocacy and promotional issues, account missuse and harrasment etc. These are all things that we as editors have to handle because it is the very core of collaboration no matter what a large group of people are doing. Making it easier would help keep things moving forward. I am for whatever option keeps things going, with the least chance of backing up or stalling the process. Wikipedia will be here a long time but it does not have to be the same as it is now or was ten years ago. Change isn't easy and sometimes its not best choice in all situations, but conflict resolution on Wikipedia has to evolve and needs to improve. I think we all know that much. --Amadscientist (talk) 02:13, 29 September 2012 (UTC)

We're talking about the problem of resolving disputes. That's the problem and Wikipedia needs to solve the problem of not being able to resolve disputes well. I'm not certain what you're arguing or why. Jobberone (talk) 10:28, 29 September 2012 (UTC)

No...we are not. You are...the rest of us are trying to discuss reforming the process, not how to solve disputes themselves.--Amadscientist (talk) 21:03, 2 October 2012 (UTC)

Ok again, "We're talking about the problem of resolving disputes. That's the problem and Wikipedia needs to solve the problem of not being able to resolve disputes well." You want to reform the current process and I think that's, while admirable, unlikely to bear much fruit. I want to throw it out and start over. I think you're wasting time but I hope I'm wrong and it helps Wikipedia significantly. I see no reason for you to be that upset with my stance. I've stayed out of the current process so I'm not causing any problems. You can have the final word if that pleases you. Jobberone (talk) 02:14, 3 October 2012 (UTC)

I'm new here. I recently joined Wikipedia to help improve it, work for it, if I could. Reading what lies above, I want to delete myself from your company. If these are the wisest minds in Wikipedia, then I would prefer to remain an outsider who continues to mistrust Wikipedia for it's incompetence and in-fighting. Reporting "truth" or "facts" is always a simple operation. If it is a disputed fact, then have the common sense to 'flag' it as such but retain it in the text - keep it in. To alternatively discuss "ignorance" and "bias" is a job for life, without end. No truth is ever found. I ask you all to look closely at what you have written above and then reconsider your stance. This thread should never have come about. We are not here to create perfect wars, we are here to find imperfect peace. Truth is ever changing, never certain. Debate should serve to free a new truth, not lock an old truth into personal or patriotic cells. Sort yourselves out or you will find me gone. Others follow me. They too, will ultimately leave you to bicker among yourselves. The future of Wikipedia lies with those named above - and the thousand others who built it up to where it is now. Not me, nor those who chance to follow me, will ever be a part of your impressive creation yet neither will we waste our time while debate replaces action and factions are formed instead of fact.--Loop Withers (talk) 02:20, 1 October 2012 (UTC)

OK, revised position: let us all step back and wait for all disputes magically resolve themselves. If one writes in the article about human anatomy that the distinguishing factor of human is having no less then five heads, we'll just mark this with {{citation needed}} and pass by. I envision the flourishing Knowledge after enforcing of such approach.

Or may be we just should set a 4000+ edits bar on WP:FRS subscripts? — Dmitrij D. Czarkoff (talk•track) 22:42, 2 October 2012 (UTC)

Rearranging the deck chairs

I have watched several disputes over the last few years- usually caused by character differences between Wikishiites (who wish to impose the sharia of policies and words of the prophet- to the exclusion of innovative writing and the task of producing an Encyclopedia) and the content producers who do the productive work. Producing mandatory forms is pandering to these shiites, adding fuel to the fire- asking us about what colour the forms should be, is endorsing their stance. I was asked for comment- which I have given- now I will walk away (the best form of dispute resolution) and get back to my editing backlog.--ClemRutter (talk) 09:57, 2 October 2012 (UTC)

(Start Sarcasm) Thanks so much for your fair and unbiased description of the differences between the two groups. Some folks use prejudicial language to push a particular POV that what they happen to be interested in is the Most Important Thing In The World and what they are not interested in is Useless If Not Evil. You are to be commended for treating those who are process-oriented with respect and dignity.(End Sarcasm).

Given the many, many places on the net where "content producers who do the productive work" can post whatever they want without being inconvenienced by "the sharia of policies", I can't help but wonder why you chose Wikipedia. --Guy Macon (talk) 13:36, 2 October 2012 (UTC)

You probably could have said this better without invoking Islamism, but you've hit the nail on the head. Why not just encourage people to walk the hell away instead of get their knickers into such an infernal twist over content wars? This kind of thing destroyed the project for me ages ago, and I'm always astonished to see the warring that continues years later. ... aa:talk 17:30, 2 October 2012 (UTC)

Collaboration and consensus. Don't like working together? Either learn or don't expect a "Please don't go" from anyone.--Amadscientist (talk) 21:01, 2 October 2012 (UTC)

Editing policy, like communism, can never fail. It can only be failed. ;-) 67.117.130.72 (talk) 06:27, 3 October 2012 (UTC)

Five problems and solutions

The five biggest issues I see with the Dispute Resolution Process, are:

1. Tends to consist of only allegations. Solution: Should be structured for threaded discussion
2. Unsubstantiated allegations. Solution: supporting diffs should be compulsory
3. Cliques of editors leading to bias. Solution: Allow just one complainant/defendant.
4. Too many Arbitrators/Admins. Solution: Let the complainant/"accused" choose one person to assess the issue
5. Process takes too long. Solution: The involved agree on a set hour, and "thrash it out", before the Arbitrator/admin decides

--Iantresman (talk) 11:31, 2 October 2012 (UTC)

I do not understand why too many sysops is bad. The only limit would be more sysops than disputants. ~~Ebe123~~ → report 20:02, 2 October 2012 (UTC)

It's good if they are widely deployed. But why tie-up all their expertise with just one issue? --Iantresman (talk) 14:03, 4 October 2012 (UTC)

These issues are well-stated. Maybe they are not separate, but are more like a progression. Someone makes an unsubstantiated allegation -> counter-allegations take over the discussion -> some participants start to take sides -> others jump in to try and arbitrate -> a lot of time gets wasted.

It is a common problem in web communications, not just in Wikipedia. It is tempting to curb the original unsubstantiated allegation - but that looks like censorship without a clear agreement on "substantiated". Perhaps allow only a single (editable) contribution per user per discussion? That may "dampen down" the yelling matches. Trevithj (talk) 01:42, 5 October 2012 (UTC)

The problem with that suggestion is that the last to speak gets to offer their refutation for anyone else's. Making the contributions editable means that you just have an unthreaded discussion - as happens at Arbcom.

And the big problem with unsubstantiated "allegations" ( I don't like that word, though that is often what we get), is that there need not be a presumption that the claim is disputed. The response may not be "No I didn't do X.", but "Yes I did do X, and a good thing too, because..." Or even "Yes I made a mistake." Rich Farmbrough, 20:00, 5 October 2012 (UTC).

Civility enforcement RFC

User:Hasteur has begun an RFC on the future of the civility policy and has made the proposal to deprecate Civility to a guideline Wikipedia talk:Civility#Civility Enforcement RFC.--Amadscientist (talk) 10:16, 3 October 2012 (UTC)

There's another Civility RFC at Wikipedia:Requests for comment/Civility enforcement seeking input (and new statements) on a variety of aspects, from definitions to goals. —Quiddity (talk) 18:48, 4 October 2012 (UTC)

The Elephant in the room

Short version: What is the cause of most conflicts? Content disputes. What are we missing? A content Arbcom.

Long version: As long as editors stay civil and continue the discussion, a content dispute can be drawn out indefinitely. What happens is that eventually one of the parties caves and violate one of the behavior rules and gets hammered. Keep discussing and adding more and more sources is the only way things can get resolved. In many cases, the same dispute can be resolved rather fast if independent editors could rule on these things. -- Kim van der Linde ^{at venus} 20:00, 8 October 2012 (UTC)