Wikipedia talk:Consensus/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

→

Archive 10

Update flowchart

Per the discussion above, the text may not be consistent with the flowchart, so I updated the flowchart to reflect an illustration of a broader process. The old chart began with the assumption that an edit was the appropriate starting point. However, in come cases discussion should precede an edit, specifically major changes which warrant discussion and consensus in advance of editing. --Kevin Murray (talk) 17:51, 15 March 2008 (UTC)

I have looked at both the new and old flowcharts. It seems the new one is perhaps more applicable in the case of "policy pages, which require a greater degree of agreement before making changes". The old flowchart was OK too, though perhaps a bit over-optimistic. Optimism versus "reality"? I am interested in the outcome, I do think the policy page is in reasonable shape, it could be shorter, but I dont know how that would be achieved. I think that the current changes, and the discussion between KB and KM are reasonable, no-one here seems to want to implement major changes, work is going in the right direction, and both KM and KB are to be thanked for their efforts. Thanks --Newbyguesses - Talk 20:52, 15 March 2008 (UTC)

Eh? Kevin Murray is currently making major changes to an entire section, and afaict there is full consensus that he be allowed to do so, so far. ;-) --Kim Bruning (talk) 22:08, 15 March 2008 (UTC)

Sorry Kim, I do not have many original thoughts, so I will steal yours again "How do you know that something is minor or major?" I dont regard the current changes as major. For me a major change would be one that veers off in a direction opposite to that which has been accepted to date, and I dont see the changes to the flowchart as um "charting new territory". I will leave it to the more experienced programmers to make the running here, I am simply trying to evaluate if we are moving together on things here, and staying within the bounds of what is appropriate at this page at this time, and i think we are. I were not involved in any edit-war, back in January or whenever, I have a gaurdian angel. --Newbyguesses - Talk 23:26, 15 March 2008 (UTC)

debugging the chart

Without going into deeper issues or underlying philosophies, or ideals or other policies, there are four purely technical issues with the flowchart proposed by Kevin Murray. That's the nice thing about flowcharts. You can approach them in a logical way. :-)

1.The first issue is the box that contains among other things "seek broader community participation". This is a process or subroutine that needs to be expanded in full (see earlier discussion for more detail on why all processes described here must be expanded in full). A similar issue exists with "propose a compromise"

2. The second issue is that there is a potential infinite loop at the center of the chart. In this method it is possible to generate indefinite amounts of content on the talk page, and never ever reach the point where the page itself is edited. It's a short circuit. One way to seek broader community input is to make an edit to the page itself, as this will show up on the watchlists of interested parties. Perhaps you can kill two birds with one stone here? Also what method should be used to propose a compromise?

3. The third issue is that "status quo" is a new term, which must be defined.

4. Finally, "minor change" is an existing term of the art. (namely, the "minor edit" checkbox that all logged-in editors have). So a different term needs to be used here, and a definition must be provided. How do you know that something is minor or major? You may need to add an extra decision box. Possibly this over complicates things. Is it possible to refactor out this set of decisions entirely?

There might be more issues, but these are some issues I spotted fairly quickly.

--Kim Bruning (talk) 21:53, 15 March 2008 (UTC)

Kim, I've made a few changes to reflect Newbie's and your concerns. Status quo should be fairly well understood by our editors, but I am happy to substitute another word. To me consensus is a process not a state of being, and in some cases the status quo does not truly reflect a consensus. I think that consensus has become a euphemism at WP.

Although there is a potential for looping, that is a fact of life at WP. The logic is at some point either a compromise will be struck or the editor will decide that the change is not needed. As to explaining the further processes (subroutines), I think that would make the chart too complex, and the concept of "seek broader community participation", is explained in the text. --Kevin Murray (talk) 22:20, 15 March 2008 (UTC)

(~e/c) Ok, remaining issues now:

1.The first issue is the box that contains among other things "seek broader community participation". This is a process or subroutine that needs to be expanded in full (see earlier discussion for more detail on why all processes described here must be expanded in full). A similar issue exists with "propose a compromise" The box is still overloaded, at least split it out! :-)

2. Still an inifinite loop, which means the process will theoretically never terminate. Can it be eliminated, to ensure that the process can at least terminate in theory?

3. The third issue is that "status quo" is a new term, which must be defined. Let me think about this one.

4. The decision "is this change accepted": This needs a (sub)process describing how to get the change accepted. (this is a new issue?)

5. You implement several checks starting at status quo. However, they are not repeated after the "propose a new compromise/seek wider community participation" box. This means that even minor changes cannot be made while in the central indefinite loop. That seems odd. (this is a new issue)

--Kim Bruning (talk) 21:53, 15 March 2008 (UTC)

Kim, I would agree with you if we were preparing a chart to be followed in precise detail by a program coder; however, this is a human process and this is merely a visual aid to assist in the understanding of potentially cumbersome text. It also looks like you merely repeated some objections without acknowledging my previous answers. If the chart is not fatally flawed, why don't we let some others respond and I'll be happy to make changes to the graphic. Please consider this a rough draft. --Kevin Murray (talk) 22:45, 15 March 2008 (UTC)

(e/c) That's what (e/c) (edit conflict) means: you made changes to the page, and answered while I was still editing. This text has been updated to meet the current chart, but may also contain elements of the old text. Apologies for the confusion. --Kim Bruning (talk) 22:53, 15 March 2008 (UTC)

(post e/c answer) I am indeed acting like a coder, because well, that's one of my many hats. :-) I think that if you do make a flow chart, it should at least work in theory, if not in practice, right? If it can't even work in the antiseptic white room of the theoretical world where all conditions are held to be ideal and all people are perfect angels, how can it ever work in the rough and tumble of the real world when real people are involved? :-) --Kim Bruning (talk) 22:57, 15 March 2008 (UTC) ps. There is a philosophy that says that all content on wikipedia should be considered a rough draft, which is not a bad idea really. So no worries on that count.

• Let's inject a little bit of real world reasoning about point 2:

In the infinite loop, it seems reasonable to assume that there is a risk that large numbers of potential changes will heap up and finally appear on the page as a single major change (with all the risks that ensue when a 3rd party comes along: see WP:SILENCE, WP:BRD, and what is implicit in what you are saying yourself). If we can "blow off steam" in that cycle by allowing many less large changes to show up over time, this risk is mitigated. --Kim Bruning (talk) 22:49, 15 March 2008 (UTC) Those with keen 6th senses might guess where this is headed. Even keener minds might notice that there is now an ongoing demonstration at hand.

Is "should process continue?" intended as an attempt to address this open issue? :-) --Kim Bruning (talk)

Yes, I tjopught my other wording wasn't conveying the concept that the way out of the loop is to continue to find a solution or concede the point. --Kevin Murray (talk) 00:11, 16 March 2008 (UTC)

(Open Issue 1): Hmm, You've replaced the text in the box, rather than exploding the box (aka splitting it into sub-processes). (In that case, I actually liked the previous text better, for certain reasons which may become apparent over time, if still relevant.). --Kim Bruning (talk) 23:37, 15 March 2008 (UTC)

I am reluctant to add another step which will make the chart larger. Already some people might object to the more complicated visual. Why don't we see what others think? --Kevin Murray (talk) 00:11, 16 March 2008 (UTC)

Perhaps this could be labeled as a summary chart, and we could develop a more precise version to be displayed on a addendum page etc. --Kevin Murray (talk) 00:13, 16 March 2008 (UTC)

There is a technique called refactoring which we can apply to simplify the chart later. However, it is only wise to refactor once there are no errors left open. --Kim Bruning (talk)

Either flowchart works for me, maybe some tweaks, as is normal, this seems best, I think. sorry, maybe this is in the wrong section? --Newbyguesses - Talk 06:35, 16 March 2008 (UTC)

BRD is not Consensus

Someone accidentally mistook the consensus flowchart for the BRD flowchart. This is not true, of course. Though... BRD does make use of the long cycle on the left hand side of the consensus flowchart, that's how the two are related.

Consensus can be formed in several ways. (though ideally, you try to use the shorter cycle on the right-hand side. AKA the wiki-editing process)

--Kim Bruning (talk) 22:01, 12 March 2008 (UTC)

Yes, I see. Thanks for the correction. Silly rabbit (talk) 22:03, 12 March 2008 (UTC)

I've seen people say that "BRD is not consensus", but I've never seen an explanation of what makes them different. BRD is the normal recommended editing process, and I don't see why it's considered "dispute resolution" or "controversial". I've made such comments on Wikipedia talk:BOLD, revert, discuss cycle, but never really found an explanation. Can someone explain concisely the difference? — Omegatron 07:15, 16 March 2008 (UTC)

As follows:

• Consensus flowchart (the one you last updated) has 2 cycles or loops:
  • right hand loop: Normal wiki-editing.
  • left hand loop: An edit was made and was contested. (strictly speaking, it contains the steps bold revert and discuss too, but I made the page "BRD" before making the chart. :-P)

• Page currently at BRD: (strictly speaking:"How to find people who are objecting to your changes")
  • makes use of a side effect of the left hand loop of the consensus flowchart... intermediate objective is to find people who you need to talk with to obtain consensus in tricky situations. Ultimate objective is to return to normal wiki-editing per right hand loop ("normal wiki-editing") of the consensus flowchart.

--Kim Bruning (talk) 19:07, 16 March 2008 (UTC)

I don't see any distinction. BRD is just part of normal editing, no? — Omegatron 21:21, 16 March 2008 (UTC)

Read the BRD page carefully. What's described on that page now is not the normal editing procedure. It just makes use of a side effect of part of the procedure (for contentious edits). The fact that the page also describes that procedure better than most other project pages is... err... not my fault. ^^;;;; (it still sucks at it though)

I prefer the wiki-editing process (right hand loop on the chart) over BRD, and I prefer it over the left hand loop on the consensus chart.

Yes, we need to reorganize some pages to make things a lot clearer. ^^;; --Kim Bruning (talk) 23:14, 16 March 2008 (UTC)

Considering the following admonition from the BRD page (is, and is not section), the updated flowchart seems to be consistent with this process:

"BRD is best used by experienced wiki-editors. It requires more diplomacy and skill to use successfully than other methods, and has more potential for failure. You can try using it in less volatile situations..." --Kevin Murray (talk) 21:32, 16 March 2008 (UTC)

Should be: "also used in less volatile situations" (but doing so is overkill.). --Kim Bruning (talk) 23:10, 16 March 2008 (UTC)

Exceptions in light of accusations of impropriety

What purpose is served by giving policy status to declarations from Jimbo, the Board, and developers that would not be served by excluding those from Jimbo? CKCortez (talk) 22:15, 12 March 2008 (UTC)

None whatsoever, other than agility. Obuibo Mbstpo (talk) 00:24, 13 March 2008 (UTC)

Have we ever needed agility? It seems to me that under the only situations where we might, the Foundation attorney would be a more appropriate position from which to decree policy. Moreover, attorneys are bound by well-understood ethical codes, and can be disciplined under them by several means if the violate their clients' trust. There is no professional association serving as a check on Jimbo's behavior. Is that best for the project? CKCortez (talk) 01:51, 13 March 2008 (UTC)

(e/c) You can never have too much agility. --Kim Bruning (talk) 01:57, 13 March 2008 (UTC) OODA loop

(post-ec 1) Ah, that makes more sense, and is an interesting point. Bring this up at the talk page for meta:foundation issues, and/or on the foundation mailing list. It'll trickle back down to here. --Kim Bruning (talk) 01:59, 13 March 2008 (UTC)

(ec post ec1) Fuck no. I'm not letting $random_attorney decree policy. (on the other hand, our current attorney is a cool guy. But what happens when he moves on?) --Kim Bruning (talk) 02:01, 13 March 2008 (UTC)

(And therein lies the danger of writing *too much* ;-) --Kim Bruning (talk) 02:03, 13 March 2008 (UTC)

I think we can safely dispense with the agility, but we'll need to compensate by gaining some more strength and dexterity. Otherwise those orcs will make short work of us. Obuibo Mbstpo (talk) 02:27, 13 March 2008 (UTC)

Dexterity == agility, and under safe harbor and DCMA takedown requirements, it is no longer important. Intelligence is covered, constitution is good, and strength is okay because you don't really need it. What is sorely lacking is some wisdom in the leadership position instead of the slightly-above-average charisma you are stuck with now, Wikipedia. 171.64.133.18 (talk) 03:43, 13 March 2008 (UTC)

Please! The charisma is essential for seducing Canadian journalists. Obuibo Mbstpo (talk) 06:29, 13 March 2008 (UTC)

New flowchart

The proposed flowchart

1. Way too complicated. We're supposed to be writing guidelines and policies based on cooperation and discussion, not legalese procedures. We encourage editors to follow the spirit of the guidelines and not to get hung up on the "letter of the law". This is as it should be.
2. It appears that there are only two types of edits: minor edits and controversial edits. I'd suggest that the vast majority of edits are neither.
3. Who decides if an edit is "minor"?
4. What is "processes at WP" and how would an edit affect it?
5. Who decides if "process should continue?" Why would they decide either way?
6. etc.

The basic process we should ideally follow is this:

1. See a problem with the article
2. Try to fix it
3. If your change is not accepted, discuss it and come to agreement

If there's a problem with the current flowchart (besides the fact that it's not rendering correctly anymore), we can certainly change it, but please try to avoid instruction creep. — Omegatron 06:30, 16 March 2008 (UTC)

Omeg, I started with your chart and tried to bring it in line with the recently clarified text; however, when addressing the concerns of the other editors, it pretty soon fell apart into a new chart. I do agree that a simpler chart would be better, but the first drafts were not addressing all concerns.

There are 3 edits mentioned in the chart as exceptions to the general flow: (1) minor, (2) controversial, and (3) to processes, and these receive either preference or restriction. If you follow the chart the other types of edits are the mainstream by default. The term "processes" is a euphamism/buzzword for the combination of policies, guidelines, and other rule-sets (because we don't use the word rules at WP). Processes are more resticted in editing since we seek some stability -- not to perpetuate them, but to prevent the pervasive creep of new instructions. Please consider my work today as a draft for discussion. Thanks! --Kevin Murray (talk) 06:44, 16 March 2008 (UTC)

I'm trying not to think of it as "my" chart. Although I agree with it, my contribution is just some minimal changes from Kim Bruning's Image:Consensus plain.svg.

If this is a draft for discussion, it should be on the talk page, not placed right in the policy.

I'm not sure where you think the chart and the text are in disagreement. Can you explain? I haven't been following all this discussion.

You have a line going from minor edits directly to implementation, but all edits should default directly to implementation. If you make an edit and someone else disagrees with it, then it is by definition a controversial edit, and you need to go to the talk page to discuss it further instead of making the same edit again. This is already covered by the simpler chart. — Omegatron 07:07, 16 March 2008 (UTC)

"If this is a draft for discussion, it should be on the talk page, not placed right in the policy." ... I don't see that box on the original flowchart, but I do see such a box on the new one. :-P I think it's ok for Kevin to update the chart wherever, as per the normal consensus process. We were making progress at a decent clip. :-) See above for further discussion.

I think the chart has some bugs, but it is also descriptive of how at least one influential group of wikipedians edit. The bugs that currently still exist in the chart seem to explain User:Vassyana's observations about consensus becoming blocked . I think you can see why I am so very interested. :-) --Kim Bruning (talk) 19:14, 16 March 2008 (UTC)

Flowchart removed

I think that it is best to remove the flowchart since it is no longer in step with the text. Clearly the chart is a great tool, but we need to resolve the text issues before trying to attempt a visual aid. To have an ongoing debate on two fronts is confusing at best. Cheers! --Kevin Murray (talk) 06:58, 16 March 2008 (UTC)

I don't see a conflict between the chart and the text. — Omegatron 07:07, 16 March 2008 (UTC)

As the authors of the "competing" charts, I'd like to have us stand-down to get some third party discussion generated. The reason that I fussed with the chart in the first place was based on concerns of conflict between the text and chart. When I became involved with the chart it did clarify, that there is no allowance for retaining the status quo in the earlier chart, and it also seems to suggest a bias for making change. Regardless, I do agree that a simpler chart is a better presentation. Maybe you could read through the recent discussions above. Anyone who opposes CREEP is my ally! Cheers! --Kevin Murray (talk) 07:13, 16 March 2008 (UTC)

Again, I'm not the "author" of the other chart. I merely re-drew a chart made by Kim Bruning. I do happen to agree with it, though. A lot of people have said they find the chart helpful, and I hope it stays on the page. — Omegatron 07:18, 16 March 2008 (UTC)

Interesting. Kim is among the people cooperating in experimenting with a new chart, and had not reverted the draft. --Kevin Murray (talk) 10:51, 16 March 2008 (UTC)

(unindent) I like the new chart, since it illustrates a very important first part to the consensus process. A drawback, however, is that it seems to emphasize WP:BOLDness far less than the original flowchart. I am surprised that Kim, who has so far been a champion of WP:BOLD, has not yet commented. Personally, I would support either version of the chart. Either chart is preferable to none at all. silly rabbit (talk) 13:54, 16 March 2008 (UTC)

Scroll up for a continuous commentary over the last couple of days. --Kim Bruning (talk) 19:16, 16 March 2008 (UTC)

I object to the removal of the chart. I think it is very important to have it continue reflecting WP:BRD, including that bold first step. Lately, people have been stressing discussion as though it is a requisite first step, which it is not. They almost act as though failing to discuss first is a disruptive and potentially blockable offense, which it is not either. As long as the bold edit is made in good faith, it is permissible and, indeed, in fulfillment of the concept of a wiki: "Wikis are generally designed with the philosophy of making it easy to correct mistakes, rather than making it difficult to make them." Accordingly, I am reverting. Obuibo Mbstpo (talk) 16:20, 16 March 2008 (UTC)

Being a wiki is a blessing and a curse. I see a wiki as a format not a culture. Just because we can be unstable doesn't mean we should. The new chart allows for the possibility to maintain status quo, and acknowledges a difference between editing articles and policy pages. I like to see more interaction at the articles, but more stability at the policy (process) pages. --Kevin Murray (talk) 18:09, 16 March 2008 (UTC)

My preference is dynamic stability. Interestingly for this discussion , trying to force a dynamically stable system to come to rest will tend to cause it to collapse. --Kim Bruning (talk) 19:25, 16 March 2008 (UTC) Odd. We don't seem to have an article on that topic yet

Well said. The irony is that I'm trying to acknowledge that we are evolving toward a slower rate of change, but trying to effect the recognition through a controversial change to policy. I see instruction creep as stifling the creativity at the articles, but ironically we need some tighter policies to stem the creep. --Kevin Murray (talk) 19:52, 16 March 2008 (UTC)

You're saying what you want, and you're saying what you're doing. But I'm not sure that what you are doing will achieve what you want.

• Reducing rates of change means that text is less likely to be removed as well, with the net balance typically going towards a slow accumulation of more bureaucracy.
• You're not being controversial. Take a helicopter view! :-)
• Tightening policies tends to cause more complex behavior, thus requiring more policies to correct that, thus causing a spiral towards more and more complexity.

So possibly you are working against your own goals. --Kim Bruning (talk) 20:29, 16 March 2008 (UTC)

Yes, restricting the process for changing policy can make it harder to trim back the existing burden, but at least it might help stem the tide. It seems that a new notability subguideline proposal emerges each month. If accepted, each carries the power of deletion and creates a new set of rules to be misapplied at AfD, and with which our writers need to become familiar to protect their work. --Kevin Murray (talk) 20:49, 16 March 2008 (UTC)

Well, people shouldn't be permitted to do proposals anymore anyway, it's horrendously inefficient. But that said, reducing the rate at which all documentation is written is not entirely even. In general, marking historical is slowed down more than the making of new proposals. The long term effect is a continuing growth of bureaucracy. I'm not entirely sure why this is so, but this is something that I have observed over time. --Kim Bruning (talk) 23:25, 16 March 2008 (UTC)

Agreed with Obuibo on stressing boldness and not giving more fuel to the wikilawyers. I don't need to ask permission on the talk page before I edit, or worry about what the article's owners will think of my edit. Articles don't have owners, and everything is subject to discussion. Wikipedia should not be a bunch of biased groups fighting with each other for control of an article, with that fight spilling out onto policy pages like this one where they try to manipulate definitions to suit their argumentative goals. Ideally, it should be a bunch of unaffiliated people who discuss things and consider them with open minds and are swayed by each others' arguments. We should promote this harmonious utopia as much as possible in our policies, even if it doesn't always happen in practice.

This "maintaining status quo" business sounds like it directly conflicts with our stated goals, and I've seen people claiming "you didn't achieve consensus to make that change!" far too often when they know they won't get their way otherwise. The only way I would endorse something like this is if it's along the lines of "if the discussion has already been had on the talk page a million times, and always comes out the same way, then that status quo has some stickiness, just for the sake of not wasting everyone's time". — Omegatron 21:11, 16 March 2008 (UTC)

• Considering the following admonition from the BRD page (is, and is not section), the updated flowchart seems to be consistent with this process:

"BRD is best used by experienced wiki-editors. It requires more diplomacy and skill to use successfully than other methods, and has more potential for failure. You can try using it in less volatile situations..."

• Also consider this quote from the lead paragraph to the Consensus page:

"In the case of policy pages a higher standard of participation and consensus is expected."

--Kevin Murray (talk) 21:34, 16 March 2008 (UTC)

• Oops, that should be , you can also use it in less volatile situations. Fixed.

• I can only agree, which is why we're applying that now. :-)

--Kim Bruning (talk) 22:57, 16 March 2008 (UTC)

Hybrid chart

I've created a hybrid from the two charts (Chart 3) which addresses my basic concerns but preserves most of the old format. I'm hoping this might make the changes more visible and less shocking. Thoughts? --Kevin Murray (talk) 20:15, 16 March 2008 (UTC)

Sample of old new and hybrid CCC Consensus flowcharts

I !vote for flowchart #1. I make potentially controversial edits, including edits to policy, without necessarily discussing it first, and so does everyone else commenting here. The initial edit you make is simultaneously a proposal and a prototype. You don't need to get permission to propose something. If you blunder into a controversial situation without knowing what you're doing, that's a different problem.

The only times I "discuss first" is when I think something should be changed on a page but I don't know precisely what change would be best and I want to solicit others' opinions first. That's discussion for the sake of discussion and while it can produce a consensus for some action (or for no action), it's outside the "consensus loop", as far as I'm concerned.--Father Goose (talk) 21:39, 16 March 2008 (UTC)

With all due respect, your methods are among those which concern me. I think that you frequently have great ideas, but from time to time we can each be a destabilizing influence. We appear to have more time and energy than most wikipedians, thus have had a dramatic effect on our rules. Is that good or bad? --Kevin Murray (talk) 21:46, 16 March 2008 (UTC)

I am going to disagree with KM here, I do not think that individual editors, making good-faith edits at whatever rate, are going to be "disruptive". Disruption is a different problem. Whenever we talk "disruptive", can we be more positive in the policy documents, and say "co-operate" instead? The difficulty is, that, quite often not enough editors are available to reply or edit at critical times.

The failure to achieve a viable consensus is usually I reckon, the result of too few editors and contributors weighing in, never too many. We need more vioces, saying sensible things; when that happens, we can get on top of instruction creep.

That being said, the two short extracts that Kevin highlighted should remain prominently on their respective pages, they are worth emphasizing in my opinion, thanks --Newbyguesses - Talk 23:33, 16 March 2008 (UTC)

There is a big difference between being disruptive adn destabilizing. I don't see any of the excellent contributors here as being disruptive. But destabilizing can be an unforseen consequence of constantly striving for perfection. What we are doing here has potential for destabilizing, but does it have merit which exceeds the risk? --Kevin Murray (talk) 23:39, 16 March 2008 (UTC)

Well,yes, I think so. Also, the difference between BRD, and the discuss-first model doesnt matter in a lot of cases. Say that an experienced Wikipedian B then R - we are straight back to D. (I am presuming the experienced wikipedian self-regulates at 1RR.) Now, there are other more interesting cases where BRD leads in a different direction than the discuss-first model, but I think they are exceptions to the rule. And, currently, work on this page itself, is tending to the discuss-first model, even though the "changes" are in themselves fairly minor, staying on track, just tinkering with a flowchart which is an illustration, (though Bold editing has, and will occur). Thank you --Newbyguesses - Talk 23:55, 16 March 2008 (UTC)

(ec. somewhere) At first blush, you *would* think that there isn't such a large difference between the left hand cycle and the "discuss first" model.

Except now we've actually written both out in flowcharts, and we find some differences. The left hand cycle (chart #1) actually leads to a sequence of edits, at a slow but sure rate. This is basically what you want if your objective is to edit the wiki. When we actually plot the "discuss first" model preferred by some wikipedians (chart #3), we find that it is actually possible for the process to be stuck indefinitely, never producing any edits. This is already a fatal flaw (there are one or two more, but we can safely stop there then).

In the compromise situation, (chart #2 that Kevin made today), we actually do see people eventually making an edit. This might bear looking at.

(On a policy related note, Kevin's chart #2 effectively bans the wiki-editing process, so fails a requirement to support foundation-issue #3, but that requirement wasn't mentioned before, so it'd be unfair to discuss that 'till later, and seems accidental and fairly easy to fix anyway, I think)

--Kim Bruning (talk) 00:02, 17 March 2008 (UTC)

(resp. Kevin) Did I mention Dynamic stability before? The way I've seen it defined, is that dynamic stability is stability that occurs in a system with constant change.

A slightly morbid example is human posture (why it's morbid will be clear in a moment :-) )

We've all seen it in the movies:

When two cowboys are standing in the main street at high noon, both maintain their upright posture due to constant dynamic changes. If they lean slightly to the right, the brain instructs muscles in the opposite leg pull them back to the left, and vice versa. Same for forward and back, and for 100s of other tiny alterations.

Then, the clock actually strikes 12. Both Cowboys draw.

The cowboy with the black hat gets hit, precisely in the forehead, shutting off his brain.

At that point in time, the brain is no longer available to maintain dynamic stability, and (due to the laws of physics), the body seeks a new statically stable state (aka. he crumples to the ground.).

The Cowboy in the white hat is naturally totally unharmed. His brain is still maintaining his dynamic stability, and thus he is still standing upright.

--Kim Bruning (talk) 23:49, 16 March 2008 (UTC) This is what you get when a neurophysiologist-type-person watches The Quick and the Dead ... be afraid... ;-)

Also consider examples of modern jet fighters which are inherently unstable but kept in line by computers. The ability to unleash the instability gives them tremendous maneuverability. --Kevin Murray (talk) 03:50, 17 March 2008 (UTC)

I'm interested in chart #2. Could people mention what issues they have with that particular chart? I also find the 3rd chart interesting, because some people actually use that method, I believe. Remember "descriptive, not prescriptive"? (see also the next section) We should certainly mention the method somewhere, but also perhaps mention what issues have been found with that particular method. I certainly want to thank Kevin Murray for taking the time to do so much work. :-) --Kim Bruning (talk) 23:08, 16 March 2008 (UTC) I also like chart 1, but I'm slightly biased there. ;-)

Note that the flowchart is NOT for CCC. It is the flowchart for the entire consensus process as used on all wiki pages. I'm not sure how it ended up near the CCC heading, possibly that's purely coincidental. --Kim Bruning (talk)

I don't see how "destabilizing" is inherently undesirable, especially on a wiki. Disruption is bad, sure, but if something needs changin', it needs changin'. That includes policies or anything else. Perhaps it especially includes policies, due to the phenomenon of "policy rot" that Kim has described in the past -- a determined minority can hover over certain policy pages to maintain their views in contradiction of how things actually work on the wiki. Stability in cases like those is demonstrably bad. There's really nothing wrong with making a good-faith edit to any page. It keeps the wiki, including its rules, responsive. If you disagree with the edit, revert, then discuss. Or maybe even discuss then revert; the end result is the same but you can get there more smoothly by not putting people on the defensive.

I've been watching the back-and-forth going on at Wikipedia:Notability (fiction) for a few months. There's all sorts of edits going on on that page. Some get rejected, some go back and forth a few times, some go totally uncontested. The amount of instability on that guideline would suggest that any edits to it will be controversial, and would require discussion, yet the opposite seems to work better: we're working through the disagreements by actively and boldly tinkering with the thing. That only works if people don't habitually mash the revert button. Thankfully the crowd on that page is open to compromise.--Father Goose (talk) 02:33, 17 March 2008 (UTC)

Early in 2007 WP:N became a major battleground. Nothing was really accomplished until people started discussing major changes in advance. Major versus minor is subjective and varies with the environment, context, and volatility. What would be a minor change to Fiction in the current environment might be intolerable at the more stable WP:N. --Kevin Murray (talk) 04:13, 17 March 2008 (UTC)

Is there an essay on the concept of "Policy rot"? --Kevin Murray (talk) 04:13, 17 March 2008 (UTC)

• I've modified chart two in which Kim seems to have an interest, but removed the "politics" of when to propose first at the talk page from the top of the chart (chart 4 in graphic above). I hope this makes it more palatable. The discussion of when to take it to the talk page might be better handled in the text of the policy page. Does this help? I substituted this at the page, hoping that I'm moving closer to the comments discussed above. Ideas? --Kevin Murray (talk) 04:56, 17 March 2008 (UTC)

• • Now has 2 infinite loops with no edits in there. --Kim Bruning (talk) 21:14, 17 March 2008 (UTC)

I still like chart 1. I don't see why anyone has a problem with it, and I'm distressed by all this emphasis on discussing things first. It has never ever been policy that you should discuss all edits on the talk pages before making them. You don't "establish consensus for an edit" by having long stupid conversations about an issue where no one ever changes their minds. That's incredibly inefficient and counter-productive. You achieve consensus by collaboratively editing the article directly.

You make an edit. Someone else doesn't like your edit, so they change it to something that they like (without completely reverting it, because that would violate civility and eventually the 3RR). Then you change it to something you like (without completely reverting it), and after one or two more edits, with both of you making little compromises, it converges to something that you both agree with. You both sit back feeling accomplished and then you move on to something else. This is the fundamental process behind Wikipedia, and the wikilawyers pushing for endless discussions before editing are ruining this process that has worked so well for years. — Omegatron 23:28, 17 March 2008 (UTC)

It shouldn't matter that much. It always begins with an edit! (to create a page!) So the next comment on the discussion page, even if it is proposing a new edit, is actually a comment "after" the previous edit. So, a talk-page comment goes like this- 'The edit on Friday left out such and such, so how about this edit today to improve it?' Comment before sometimes, comment after sometimes, we get to the same place. --Newbyguesses - Talk 23:54, 17 March 2008 (UTC)

Descriptive not prescriptive

"Remember that we try to document actual practice, not prescribe rule-sets."

People often say "policy is descriptive, not prescriptive", but what does this really mean? I've always interpreted it as "if we have the same dispute in a lot of different places, and the outcome is often the same, we write that outcome as a policy". Some people interpret it as "we are just documenting actual editor behavior while editing articles". Of course if this were the case, we wouldn't be able to have a rule against revert-warring, for instance, since people do it so regularly. I often see people using the "prescriptive, not descriptive" point to water down a policy they don't like, and we should be careful of the wording of this. — Omegatron 07:32, 16 March 2008 (UTC)

The policies are both descriptive and prescriptive, in that they describe what some of us see as best practice and recommend to others. Otherwise, as you say, we would have to include edit warring as though it were a good thing, just because it happens a lot. SlimVirgin ^{(talk)(contribs)} 07:53, 16 March 2008 (UTC)

In actual reality, we mention both edit warring and the fact that people get blocked for it, and also the reason why people get blocked for it. (because folks find it to be disruptive) :-) --Kim Bruning (talk) 19:17, 16 March 2008 (UTC)

Reordering and merging sections

I reordered the sections so that "Developing consensus through change" now appears just above "Consensus can change" (moved down one section) I think that these at minimum should function together and might be either merged into one section, or edited for brevity and harmony. Any thoughts? --Kevin Murray (talk) 05:38, 17 March 2008 (UTC)

• I support the further edits by NG. --Kevin Murray (talk) 05:50, 17 March 2008 (UTC)

• "Consensus is a partnership between interested parties working positively for a common goal." -- per -- Jimmy Wales. That is the motto at the top of this page. To expand on that, I would only add "a number of interested parties". There are those who edit, and those who dont. I think this guideline/policy works best emphasizing co-operation, rather than conflict. HTH --Newbyguesses - Talk 06:03, 17 March 2008 (UTC)

• I support Kim's further edits. --Kevin Murray (talk) 18:59, 17 March 2008 (UTC)

• I have reordered the paragraphs and combined the CCC section with the "Developing consensus through change" section since these seemed a bit redundant in title if not content. I shifted the lead sentence from the latter up to the prior paragraph, since it is more pertinent as a lead in to the general discussion than to the section (it was formerly in that position but under another section title). I thinkthat we could trim and consolidate more, but for now, I'd like to stand back and see if I have support thus far. --Kevin Murray (talk) 18:59, 17 March 2008 (UTC)

Be careful (or What Consensus Is NOT)

• The left hand cycle of original flowchart (used by BRD, but is not BRD) is not the recommended default course of action. The right hand cycle of the original flowchart (wiki-editing process; m:Foundation issues #3) is the recommended default course of action.
• The chart still does not refer to CCC. The location of the chart is arbitrary. I recommend moving it elsewhere, to prevent misunderstandings
• The objective of CCC is not to recommend any particular process. The objective of CCC is to stress that Consensus CAN Change. This was a compromise, to explicitly prevent people from forcing adherence to some arbitrary status quo (whether that was established by a poll or by some other method). Once again, see: original discussion for details.

--Kim Bruning (talk) 21:22, 17 March 2008 (UTC)

Boldly cut everything that didn't look like CCC out of the actual CCC section. "therefore, whatever remains, must be CCC". Feel free to re-add to other sections if/when/where appropriate. Feel free to yell at me if you disagree too. --Kim Bruning (talk) 21:36, 17 March 2008 (UTC)

I'm happy to see this being trimmed dow, and think that we shoul dcontinue to apply the shears to some of the other sections. Maybe we could do some more trimming and then advertise the result to see if we have a broad consensus. I think that we are on a good track. --Kevin Murray (talk) 22:19, 17 March 2008 (UTC)

I strongly recommend we advertise via watchlists only, as we've been doing so far. Other than that, no problem. :-) --Kim Bruning (talk) 22:25, 17 March 2008 (UTC)

Well, hmm, I'll ask some people who showed interest before, and then some policy experts. The idea is to have a slowly growing circle of people checking in, rather than opening the floodgates all at once (to mix metaphors). This allows us to edit the project page directly without causing too much drama. :-) --Kim Bruning (talk) 22:44, 17 March 2008 (UTC)

I re-ordered the sections again to put Exceptions at the bottom, it seems more final. Also boldly chopped a paragraph, bye-bye to Dunbar's number (sigh). Now, I didn't want to link to Wikipedia:Assume the assumption of good faith; it's nice, but only a stub and not policy either. Kevin and Kim's edits seem to be making the document clearer, if we can shorten and clarify that is good. No changes to the sense of the document. Good edits, I think, and if mine need 'updating', go for it, anyone. --Newbyguesses - Talk 23:02, 17 March 2008 (UTC)

The page was (15,149 bytes) at 04:45, 17 March 2008; now (12,836 bytes) at 23:14, 17 March 2008. Does it seem clearer after these changes? --Newbyguesses - Talk 23:34, 17 March 2008 (UTC)

Before and after

Actually, I find commenting after an edit works best for me, (in a lot of cases).--Newbyguesses - Talk 23:17, 17 March 2008 (UTC)

It's a guilty thing. Everyone does it, but it's still wiser to comment first, then make the edit. (because then you've already framed what you want to do for yourself) --Kim Bruning (talk) 23:49, 17 March 2008 (UTC)

Well, for me it's more like the Red Queen or something, I often do not know what I really think until I see what someone does about my edit, or what they say on the talk-page. There's been a lot of that lately. --Newbyguesses - Talk 23:59, 17 March 2008 (UTC)

I agree with NG that it is easier to mention it afterwards, but I am trying to comment at the talk pages, then wait a bit to edit, especially where there has been friction. It is also practical since you can put in a lot of hard work and then get reverted. There is no perfect world. I'd also like to say congratulations so far to the team who has been working together here. --Kevin Murray (talk) 01:56, 18 March 2008 (UTC)

It's called a wiki. We've got a real wiki team here now. :-) Not too many pats on the back though, this is merely the minimum expected behavior. We can still improve a lot. ;-)

It's fairly important to know why you did something. Even if you don't provide your reasoning upfront, people can still demand an explanation later. The reason your rationale is so important is because it's the first, last, and practically only basis for people to learn of your opinion and form a compromise and come to consensus.

Another reason is that it's very important to think through the consequences of your actions before you actually carry them out. It helps to verbalize them or write them down. (And if you're writing them down anyway, why not write them down on-wiki)

I can't stress enough how important this is. A frequent contributor to my talk page got banned yesterday, simply because he hadn't been thinking before editing, and the consequences of his edits were deemed too disruptive.

Finally, writing down the comments/edit summaries first is a technique taught to new programmers, because it makes you think more carefully about what you are doing.

--Kim Bruning (talk) 02:11, 18 March 2008 (UTC)

Chart creep

I prefer chart one. The new charts are too complicated to be comprehended from a simple examination. Too much creep. I suspect that only the authors will appreciate the details, and casual readers will be turned off. --SmokeyJoe (talk) 05:26, 18 March 2008 (UTC)

The new charts have some interesting flaws. They depict the process used by certain wikipedians. If nothing else, they can be useful to investigate what's going wrong at certain locations where that particular process is used. See some of the discussion here for details. --Kim Bruning (talk) 05:39, 18 March 2008 (UTC)

I see the discussion, and don't doubt that some will find the more complicated charts useful. But "can be useful" is not justification for over-complicating the summary picture on an important policy page that all users are recommended to read. I suggest moving over-excited versions of the chart into subpages (for "further reading") and putting Chart One back. --SmokeyJoe (talk) 06:23, 18 March 2008 (UTC)

I see that as one of the major potential directions we might be heading in, yes. :-) Some of the other editors have had less practice at this though, so it'd be good if we let them go through all the intermediate steps so they can figure it out for themselves. (else they might always be stuck with the thought that they've been cheated somehow). Would you help me watch the page? --Kim Bruning (talk) 06:28, 18 March 2008 (UTC)

I think that if the current chart is too complicated, we can simplify this format too an even more clear version than the old chart. Let's get some more feedback. --Kevin Murray (talk) 06:29, 18 March 2008 (UTC)

Maybe you'll get some feedback, or maybe you'll end up waiting indefinitely. You can wait forever for feedback. ;-)

In the mean time, Chart 4 still has 2 infinite loops where you could keep "doing process" forever, and never actually do an edit. Would it be possible to correct those? :-)

OTOH, I have a feeling you're digging a hole for yourself here. How about listing the requirements: what is your process supposed to do? (it should probably edit the page and get feedback and discussion, and tie that all together at the least)

on the other tentacle yet again... what are you thinking of re simplifying the chart? --Kim Bruning (talk) 06:43, 18 March 2008 (UTC)

I would give the chart a bit more time to "grow" on us, and attract further comment. The original chart probably seemed complicated when it was first introduced. On the other hand, a really simple (over-simplified) chart might work. You'll never get a perfectly de-bugged chart, it is only for illustrative purposes. My favourite step isn't shown for instance, whereby userA makes a suggestion on the talk-page, UserB thinks it good and implements it, and userC endorses the change back on the talk-page, where UserD then comes up with an even better wrinkle. (No, I am not suggesting that go in the chart!) --Newbyguesses - Talk 08:54, 18 March 2008 (UTC)

“I would give the chart a bit more time to "grow" on us.” The assumption you make is that this page exists for the regulars. I think more effort should me made to think of the reader who barely understands what “consensus” is. --SmokeyJoe (talk) 11:16, 18 March 2008 (UTC)

Sure, that's a good point. There have been four different versions of the chart in the last few days, (there's not that much difference really); it wouldn't surprise me if there were a 5th or 6th version tried soon. Doesn't mean that chart 1 wont be back by the next day. Is there too much change going on, or is it just that the simplest chart works best? --Newbyguesses - Talk 11:25, 18 March 2008 (UTC)

None of the above. Also, yes you can get a chart without bugs. Chart #1 has no logical errors as far as I can tell. Bugs were introduced by adding more boxes. --Kim Bruning (talk) 18:08, 18 March 2008 (UTC) This is illustrative of what happens when you introduce random new rules without considering the consequences. To prevent that, a good safety measure is to allow only descriptive rules documenting what actually already works. + If you really want to introduce a new de novo rule that works, you need to be really careful, and spend time testing and debugging.

Kim, there is an infinite loop only if people don't reach a consensus for making a change. It happens all the time at WP. There are three possible outcomes: (1) change occurs, (2) no change occurs and efforts cease, and (3) no change occurs but the discussion continues. It is very typical for #3 to continue for some time and then #2 perseveres. Take the recent discussion at PROF for an example of #3 fading into #2 as the proponents of change are worn down by the defenders of the status quo. --Kevin Murray (talk) 15:34, 18 March 2008 (UTC)

And you only get trapped in a pit if you don't watch where you're walking and fall in. How about not having a pit in there in the first place? ;-)

Or another example, if I were to tell customers "You'll only take down your server if you press this button, so don't do that" ... I'm not sure I'd be invited back... ;-) (Getting trapped in an infinite loop is one way that a server can go down).

I sincerely hope you are joking about what's going on at WP:PROF. Basically in social systems, an infinite loop is not really infinite. People get ground down and burn out. If that's what's really happening, then my prediction is spot on there. But such a situation would be really awful and borders on (mental) abuse. You shouldn't be treating fellow humans like that.

--Kim Bruning (talk) 18:08, 18 March 2008 (UTC)

Kim there is no joke at PROF. But this is from my perspective as an advocate for merging PROF back into the "improved" BIO. --Kevin Murray (talk) 22:37, 18 March 2008 (UTC)

:-/ Are you ok there? I'd ask if you need help at that location, but I was actually thinking of deprecating notability entirely. Would that work? (Perhaps contact me separately on that issue) --Kim Bruning (talk) 22:58, 18 March 2008 (UTC)

(ps. To stress something I said earlier: I'm only pointing out logical, predictable flaws in the structure, at the moment. Idealistic or philosophical points could be discussed later, but there may be little point discussing the finesses on something that doesn't work actually work ^^;;)

(pps. I do appreciate the charts though. The fact that you've discovered the existence of this infinite loop is very interesting! We should make flowcharts more often)

--Kim Bruning (talk) 18:22, 18 March 2008 (UTC)

So we get back to the prescriptive versus descriptive dilemma. The chart describes an actual loop in the process where a dedicated filibuster can impede progress or safeguard against folly. Notwithstanding the prohibition against canvassing, the only way to break a filibuster is to increase participation, hence expand the discussion. --Kevin Murray (talk) 22:34, 18 March 2008 (UTC)

We describe what people do, and how successful that approach is, yes. That's why I like those flowcharts you've made. :-)

Obviously, a process that allows filibuster (as you call it) is probably not exactly optimal. This is actually a large and growing problem.

Now I'm thinking about what to do about it.

At any rate, we've now (perhaps only temporarily) had some time in which we've seen how the filibuster-free process works. :) --Kim Bruning (talk) 22:58, 18 March 2008 (UTC)

I see the filibuster as a blessing and a curse. One curse is that special interest groups or coalitions (aka: cabals) can hijack an article and the average wikipedians aren't willing to fight the fight to do the right thing. As I've said before, the processes are flawed, but they have thus far developed the best product yet to be offered on the internet. --Kevin Murray (talk) 23:19, 18 March 2008 (UTC)

No, no. This filibuster thing is relatively new. Or if it's old, it's only started to become somewhat more popular recently. (Things like 3RR, CCC, IAR, WP:NOT a bureaucracy are all adamantly against it, or at least old versions of those pages certainly were.) It certainly wasn't used to build most of the wiki. --Kim Bruning (talk) 23:40, 18 March 2008 (UTC)

Filibusters are expressly disruptive to building a consensus, just like edit wars (in fact, they are a form of edit war, if all edits are reverted until "a change is approved through discussion"). It's funny you should mention that IAR is against it; IAR has been the target of a yearlong filibuster, with over 800 edits resulting in just about no change to the page, despite a large number of parties showing an interest in doing so.--Father Goose (talk) 03:55, 19 March 2008 (UTC)

Yes, we're learning to understand why that is so now :-) --Kim Bruning (talk) 04:26, 19 March 2008 (UTC)

I dont know why I bother using so many indents, i should just IAR! I will give my take on that other page, FWIW. IAR has been the subject of over 800 edits resulting in just about no change to the page, as a result of over 800 edits resulting in just about no change to the page. There's been a lot of edits. There's been no change. That's all. This "filibuster" talk is just metaphors. There were a lot of crummy edits in that 800 edits. --Newbyguesses - Talk 04:44, 19 March 2008 (UTC)

Plenty pretty ones too. --Kim Bruning (talk) 05:23, 19 March 2008 (UTC) I just cut and paste the leading ::: and add one : more... it's pretty quick. It helps that I have x-windows cut and paste though ;-) --Kim Bruning (talk) 05:23, 19 March 2008 (UTC)

As SmokeyJoe mentioned, it's probably a mistake to present a complex, all-details-included chart as the very first example a newcomer will see, read, struggle to comprehend, sigh, and depart the project over (faced with such a boggling chart as a newcomer, I can't imagine I'd have stuck around); by all means, work on some alternatives for consideration, but we need to keep things simple for first-time visitors, get them used to the general idea of working in groups, and used to our particular methods of doing so. Chart One above contains ten boxes with minimal branching, thus highlighting the core process and loop -- a detailed understanding is of no practical use if people cannot first understand the fundamental design. – Luna Santin (talk) 05:25, 19 March 2008 (UTC)

The chart also has the advantage of being logically correct.

The thing is, some people use chart 2 irl... What will we do with that?

--Kim Bruning (talk) 05:34, 19 March 2008 (UTC)

Put it here: Wikipedia:Consensus/Further study. What is irl? --SmokeyJoe (talk) 05:59, 19 March 2008 (UTC)

"In real life," I believe. And yeah, a subpage (or something) to keep other, more complex takes on the idea might be a good way to go. – Luna Santin (talk) 06:28, 19 March 2008 (UTC)

The best feature of chart 1 (the original, simpler chart) is that it begins with "Make an edit" immediately below "Previous consensus". However, there have been some calls on this discussion page and elsewhere to incorporate the idea of "discuss the edit first". In the section above, "Before and after", both Kim and Kevin go with that idea, up to a point, and give reasons why it is a good idea.

However, the idea of discussing edits does seem to get covered properly in the text, particularly the section "Notes on using the discussion page". So, going back to the original simpler chart seems best, there are no problems about that that I can see. --Newbyguesses - Talk 06:52, 19 March 2008 (UTC)

I have seen the "discuss the edit first" calls, but I disagree with them. There are already plenty of pointers telling people to discuss, and on average, I believe that there is a tendency to overdiscuss and to go off-topic. WP:BOLD has a good balance of sense, and WP:BRD is quite explicit about the need to discuss when you find your edit reverted. Chart 1 is already clear enough in sending problems to the talk page.

The new charts are experimental and are excellent and appropriate wikipedia-research. But it doesn’t need to be done on a policy page. --SmokeyJoe (talk) 07:05, 19 March 2008 (UTC)

The original chart was not describing the consensus process, but only a part of it; in essense the bold, revert, discuss cycle. I really don't see how Chart 4 can be described as complex; please give our contributors some credit. If people can't follow a simple flowchart, we might question their abilities to contribute to WP. What I want any chart to do is to offer the option of discussing first, and ackowledge the possibilty that change may not happen -- this is the real worls of WP. --Kevin Murray (talk) 11:20, 19 March 2008 (UTC)

Chart 4 can be described as complex in terms of the number of decision points, number of lines, number of loops. Wikipedia need to remain accessible to newcomers, readers and contributors. Subjecting newcomers to a logic comprehension test is at odds with that principle. You want to document in the chart the option of discussing first? I can agree with that. How about changing the “make an edit” box to “propose an edit, or be bold and make the edit”. If you want the chart to be an effective teaching tool, it’s important to keep it simple. I would simplify Chart 1 further by loosing the discrimination between a change and a revert. As for acknowledging the possibility that change may not happen, I think it is unnecessary. Nothing forces the process to continue cycling. --SmokeyJoe (talk) 12:12, 19 March 2008 (UTC)

First to clear up a misunderstanding. Chart 1 does not document CCC, nor does it document BRD. It documents the process of finding a consensus by wiki-editing, as per foundation issue #3, and also how people proceed when that immediate method fails and they need to resolve minor issues. Short: It documents CONSENSUS. ;-) --Kim Bruning (talk) 13:26, 19 March 2008 (UTC)

Summary so far: Let's not get into a repetition of moves. Here's what we've got covered so far and where we'd like to go from here:

• Discuss first sounds like a good idea to some. We're investigating.
• Chart 2 documents "discuss first"
• Chart 2 is broken. It has an infinite loop where no edits take place.
• It may be possible to find a process where discuss first is not a logical impossibility in the wiki-context. We haven't found it yet. (we haven't gotten to philosophical issues or anything yet. The logic needs to be debugged first)
• We have encountered problems with people following an undocumented process, whereby wiki-editing came to a halt. I suspect this might be the discuss first method, documented as chart 2. For this reason alone, I'd like to look at this issue
• charts 3 and 4 are attempts to fix the problem and still incorporate discuss first. No luck so far.
• Possibly Discuss first is a bad idea. Kevins charts are convincing me that this might be the case.
• We're taking our time to Get It Right. We're in no particular hurry, but I don't think we're going particularly slowly either.
• The objective of policy pages is to be descriptive, not prescriptive. We need to describe things.
• This page needs a good cleanup anyway. While messing with charts and discussions, we've also been cleaning up several sections. :-)
• Common problem with cleaning things up: It'll get messier before it gets tidier. ;-)
• I prefer to work on the page itself, else we end up with a nice squeaky clean fork, and a messy main policy. That'd be an oops! Also, I prefer to work on the actual page because this is a wiki. Which chart did you say you preferred? ;-)
• Can you help us?

--Kim Bruning (talk) 13:26, 19 March 2008 (UTC)

The old chart (Image:Consensus new and old.svg) was much better. I would object to the new one, but quite frankly, there's little point as Wikipedia's policies and guidelines are nonbinding anyway, in practice. As WP:POINT notes, Wikipedia "is inconsistent, and it tolerates things that it does not condone." What I have seen is that (1) you can get in trouble for stuff that's not against the rules; and (2) you can break the rules and not get in trouble. In either case, the deciding factor in whether you get in trouble is not how what you did relates to policy but whether the editors who participate in the ensuing discussion side with you or against you. Disruption, for instance, is often in the eye of the beholder. Often it's just a matter of how diplomatic you are. As Kim points out, your edit comment can make the difference of whether you get reverted or not, for instance. How interesting. If I had to compare it to a board game, I would say it is like Diplomacy. Note this line from the article on that subject: "During an attack, the greatest concentration of force is always victorious; if the forces are equal a standoff results and the units remain in their original positions." As WP:NOT notes, Wikipedia is not like nomic. In nomic, although the rules can change in mid-game, whatever they are at any given moment is binding; not so, here. SpiritWorldWiki (talk) 06:54, 20 March 2008 (UTC)

Chart creep, arbitrary break

I'm new to this and pardon me for jumping in without reading everything (after all, I think I know about Wikipedia consensus-making, I've used it every day for over three years, so forgive me my newbie arrogance). My newbie question is: where did this "discuss first" idea originate? Is it a new idea, an attempt to supplant Wikipedia:Be bold? Or is it an old form of dissent to the "bold" strategy, "Be timid" returned in another guise to challenge the champion? Forgive me if this has already been discussed. I'm so impatient. --Anticipation of a New Lover's Arrival, The 13:57, 19 March 2008 (UTC)

I first encountered it when certain articles would grow contentious and people started tripping over all the tempers being lost, stubbing their toes and generally growing uncivil. Being bold seemed to exacerbate the growing problem, so a call for discussion seemed a better way to arrive at agreement, so as to not further destabilize the article through edit-warring. WP:Bold is good when groupthink asserts itself or the article is running into WP:OWN or similar issues, but tossing a handgrenade into the middle of arguing folk isn't going to resolve the problem - its going to escalate matters. - Arcayne (^{cast a spell}) 20:13, 19 March 2008 (UTC)

To throw in another idea, I happen to think the "discuss first" idea assumes bad faith and is a mechanism for ownership. It's fine if someone wants to discuss their edits first, although usually that is totally unnecessary. If we do ever choose to include that step in the chart, we should stress that "discuss first" is purely up to the editor's discretion. Presenting it as mandatory under any circumstances is saying, "There's no chance you could make a good edit without consulting us first", and that is utterly unacceptable.--Father Goose (talk) 20:23, 19 March 2008 (UTC)

I think that Chart 4 addresses that concern. Although I persoanlly belive that there are circumstances where discussing first is warranted, I think that needs to remain a personal choice for now. I think Chart 2 was a reasonable suggestion, but doesn't acheive consensus here and now. --Kevin Murray (talk) 20:29, 19 March 2008 (UTC)

Chart 4 still has open bugs. Can you resolve them? You don't have to, but I'll reserve judgment 'till then (it would be foolish to do so earlier). Chart 2 also has bugs, but is perhaps descriptive of some people's practice. I'm not sure what to say about that then. --Kim Bruning (talk) 21:03, 19 March 2008 (UTC)

Hmm, Arcayne's post wasn't there when I first replied to this. In cases where some issue is known to be causing problems, I'd say the state of consensus is already in the propose/seek a solution box. If you're new to the article or issue, you might be unaware of that, but you'll find out as soon as you make an edit. Or maybe, just maybe, you'll make an edit that resolves the problem. I've found BRD works best when the person suggesting the alternative approach is outside of the original conflict, and is not regarded with suspicion by the original parties.

However, sometimes there are those who are unwilling to consider any alternatives, boldly suggested or otherwise. They'll argue an issue to death, seeking no actual consensus, and just prolong the conflict, using the insistence on discussion as a form of "soft protection". What we could really use is a mechanism for breaking that kind of anti-consensual behavior. At the present time, the sad reality is that you want such people to have to edit war to defend their POV; it makes it more obvious that what they're doing is disruptive. Letting a tendentious individual or group "discuss to death" is a consensus-sabotaging infinite loop within the diagram... but if it has to be done by stepping through the "make an edit" box each time, the behavior becomes costly, as blocks for edit-warring are now on the table.

While I'm at it, I think locking articles in the midst of a dispute is a counterproductive approach. It treats the symptom and preserves the disease. For the duration that the article is protected on the Wrong Version, those who consider it the right version have gotten what they want, and have no incentive to compromise. If the protection is long enough, or frequent enough, the other side may simply give up out of frustration. This rewards edit-warring: whoever more aggressively protects Their Version will also get the page protected on it. I've seen such warriors request protection for just this reason, and usually admins will oblige them: "Oh, look, that's an edit-war all right. Protect." I've also seen admins protect pages that were experiencing a flurry of edits eventually producing incremental compromises. Protection under those circumstances is obviously is even worse.

However, even though all that relates to consensus (or the disruption of it), I admittedly have strayed into a different topic.--Father Goose (talk) 21:32, 19 March 2008 (UTC)

(ec.) Arcayne:

Actually, you will find that tossing hand grenades into arguments is quite effective. "There's no problem that can't be solved with a suitable amount of high explosives" (not to mention shrapnel) O:-)

Oh hmm, on wikipedia you mean? But why do you compare bold edits to hand grenades? How about making bold edits with the express purpose of seeking consensus. In that case bold edits might better be compared to fluffy bunnies.:-)

Some example edit summaries might clarify:

• "This solves Alice and Bob's concerns I think. Carol, can you edit in your particular angle?"
• "Ok, This addreses Alice, Bob, and David's concerns on talk. I couldn't quite get my head around Eve yet, can you folks check my work?"
• "Per discussion on talk, at least this part can go."
• "Thinking outside the box, this might be a way to resolve this. Feel free to RV and discuss if you disagree" have you ever noticed the odd paradox that any edit summary that contains "feel free to rv" never gets reverted? Must be reverse psychology or something.

Or you can begin a discussion of some necessary issue by using WP:BRD as currently documented (make the most optimal edit, then wait to be reverted):

• "Due to X, we must now do Y. This is the ideal situation, IMHO. Here is why. See talk for more detail."
• "This text has been causing trouble with ja.wikipedia administrators on meta. I'm altering to allow ja.wikipedia admins to retain their usernames across all projects" (real life situation, compressed here for clarity. Actual edits and summaries were different)

(continuing BRD on from here, you'd discuss with people one at a time)

Even if people were fighting on the talk page, you'd quickly sort out the "ringleaders" this way

--Kim Bruning (talk) 21:35, 19 March 2008 (UTC)

I completely agree with the idea that we discuss stuff if tempers are getting frayed, but that presumes that some editing has already occurred and consensus through editing hasn't been achieved. That I would class as discussion after the discovery of contention. For similar reasons I wouldn't jump into The Troubles or Second Intifada; bold doesn't mean reckless. I don't think this means that we must discuss all, or even many, edits prior to making them. To make such a rule would really put off us impetuous, impatient editors whose work is essential in keeping the wiki from stagnating into a mass of talk pages punctuated by the occasional timid removal of a comma. --Anticipation of a New Lover's Arrival, The 21:35, 19 March 2008 (UTC)

Per Goose's post: I've seen how locking the article can work (300, Jack the Ripper, Ronald Reagan). Lots of polarizing edits and discussion page posts occurring, and locking the article allowed a stable version to be visible to the reader while forcing the parties in disagreement to find some consensus (however long it takes). Sometimes propose/seek a solution' takes a lot longer than the flow box would intimate, and perhaps it would serve to mention something about that. As someone who has been repeatedly labeled as a "tendentious contributor" as an attempt to marginalize my edits, I think that using that example as a reason to discount the idea of discussion in favor of Bold has less value.

Per Kim's edit: In light of ou recent conversation about shrubberies and related matters, a fluffy bunny can bite your head clean off. Bold edits in a conflict can often (though I will agree not in all cases) make a bad situation worse.

Its important to remember that, as an encyclopedia, we aren't in a rush. We do not have to be the first responders on the scene. We simply cite the people who are. Locking an article down forces the editors to work out their differences in a way that Bold does not. Bold is an Alexandrian solution to a problem that is almost always better resolved through discussion. I tend to think that discussion builds better articles and better editors. The article, from discussion, is better written and less disjointed, as the editors know where the parameters are. The editor, from discussion, knows how to better work with other editors, and that should be of paramount importance to both this article and all of Wikipedia.

Bold as a guideline works best when the predominant thinking in the article has become staid, static and lethargic. It rarely works in heated discussions. - Arcayne (^{cast a spell}) 22:20, 19 March 2008 (UTC)

Well, like I said. It depends on the form and application of your boldness. If you run in yelling and waving a sword, (or a rabid man-eating hopping-creature), then sure, people will either scatter or stand their ground. So Don't Do That. ;-)

On the other hand, if you boldly step in with a stethoscope and promise to listen, perhaps you can do some good.

So I figure it's not so much the boldness component that causes the problem ;-)

--Kim Bruning (talk) 22:33, 19 March 2008 (UTC)

Recently I rewrote a whole load of bloated plot summaries. Mostly I just jumped in and replaced them wholesale, sometimes reverting that section to a more suitable version, sometime removing the thing altogether (sometimes Something is worse than Nothing). In one or two places I removed oversized (6,000 words or so) plot summaries and renamed a similar section (usually called something like "Plot introduction" and sometimes itself over 1,000 words or more!) as the plot summary.

I engaged in discussion in all those where there was a revert, and made a point of calling a content RFC early wherever there was little progress. I seem to recall we quickly arrived at acceptable solutions in all cases. Perhaps the most tricky one was Goodfellas, which is one of those I had to rewrite rather than revert because there was no suitable earlier version. There was a slightly heated but amicable discussion and we ended up with my rewrite being refined to a very acceptable plot summary.

That's how it works, really. You make a change, sometimes a pretty drastic one, and if there's a problem you discuss it. This shouldn't be too difficult to document. --Anticipation of a New Lover's Arrival, The 12:24, 20 March 2008 (UTC)

Tinkering with the illustrative chart

I would also like to lose, now, the distinction from (Chart 1) between a change or a revert. My idea is to emphasise co-operation, and not to emphasise discussion only if you get reverted. Discussion should be about "refinements" not just Reverts. Making the Start box read "Propose an edit, or be bold and make an edit" has merit, I think, that makes both Chart 1 and its variants up to Chart 4 look pretty similar. --Newbyguesses - Talk 13:02, 19 March 2008 (UTC)

Comments on that:

• There's a shorter path if your change was not reverted. The objective of chart 1 is to get on the shorter path and to stay there, only using the talk page for eventual "long edit summaries" and assorted commentary if even that. You can get very fast editing rates when you do that. We've managed to stay mostly on the short path here last week. It was fun. :-)
• "propose an edit" fails unless you can fix the infinite loop bug

That said, whip out your flowchart software, or better yet Inkscape (or some other SVG editor), and have at it, let's see what you come up with? --Kim Bruning (talk) 13:38, 19 March 2008 (UTC)

Can you also do a nice shrubbery, a bit off to the left, but not all pretentious? - Arcayne (^{cast a spell}) 20:22, 19 March 2008 (UTC)

Ni? --Kim Bruning (talk) 20:58, 19 March 2008 (UTC)

Barebones chart

• Chart 5 should be about as simple as the concept can be presented, but acknowledges the realisitic alternatives. --Kevin Murray (talk) 22:53, 19 March 2008 (UTC)

It takes out the loop! :-)

*Largest issue left is that the chart now doesn't cover the normal wiki-editing process that works 99% of the time on wikis. (original wiki-editing doesn't use talk pages... they didn't exist when wikipedia was founded). If you add that back in, we might be going someplace viable. (Actually, that should be possible by just shifting the "no" path from the lower "do you accept the result" to point to "Should the edit be discussed first").

* Also: how do you know if an edit should be discussed? (with this new chart, I might know how to refactor that in ;-) ) (Look closely! The chart already details what tests to make to decide whether to discuss or not. ;-) )

* "do you accept the result" appears twice. Can we merge the two boxes, or do something clever with that?

* Finally a minor style thing: Charts are slightly clearer if you actually name a decision, rather than using yes or no. :-) --Kim Bruning (talk) 23:07, 19 March 2008 (UTC)

Kim, (1) it does cover "normal" processes at this wiki. Every editor has the choice of discussing first or editing -- we are dicussing now not then. (2) Since people objected to telling editors when to edit or when to talk (Chart 2), I've left it up to the editor based on advice in the policy text. (3) "do you accept the result" appears twice" because the outcomes are different whether one is accepting the outcome of a revert or a further-edit, since accepting the former leaves the original consensus in place. (4) Charts might be clearer or cloudier with your suggestion, but that's a nit for fine tuning (please). --Kevin Murray (talk) 23:21, 19 March 2008 (UTC)

I'm going somewhere with this, bear with me. :-)

(1) Nope. Arrow goes to wrong box.

(2) Actually, you have the answer on the chart.See the discuss box? There's arrows pointing to it... trace them back to find the procedure leading to that step. Substitute and refactor.(do you know how?). I can do it for you, but if possible I'd like you to see for yourself.

(3) Of course. But the wording is suggestive. There might be a outcome here that I hadn't thought of yet, and that's tantalizing! (Using maths or logic you can sometimes derive new outcomes you didn't know existed before.) Let's sleep on it!

(4) Sure, that's a nit.

As chart 5 appears to be basically bug free, we now have a powerful tool with which to explore this particular process. <grin>

--Kim Bruning (talk) 00:07, 20 March 2008 (UTC)

Let's focus on item #1 first and let's speak plainly, not in riddles leading me to the "correct" way of thinking. I say that in every case an editor makes a consious or subconsious choice to either discuss the change or make the change without discussion. Do you deny this? My second box does not give direction, it just asks the question. --Kevin Murray (talk) 00:29, 20 March 2008 (UTC)

Well, it *is* pure logic. I'll describe in words, and else draw a picture sometime when I have some time on my hands. It's seriously easier for me to just point you in the right direction (I'm lazy)... but fair enough.

(1.)

Your mainline along the left side is start:(previous consensus) ->should edit be discussed first->make an edit->was edit reverted->was edit modified->new consensus.

• Now, after the lower "do you accept the result" box, you go back to the mainline via discuss->make an edit->continue (or loop), never revisiting the "should the edit be discussed" decision box.
• This means that there is no way to get regular wiki-editing loop where people edit continuously. (this occurs when people are accustomed to each other and there is a great degree of trust).
• If you make the arrow point to the decision box, you basically cover both processes in one flowchart. That's elegant. :-)

(2.)

This one is trickier. You ask in the decision box "should edit be discussed first"

• searching the rest of the flowchart, can we find any other boxes that ask the same question? In fact we can. Any process that ultimately leads to Discuss asks the same question or at least part of it.
• We see two additional paths leading to discuss:

  (A)Make an edit->was the edit reverted->do you accept the result->discuss

  (B)Make an edit->was the edit modified->do you accept the result->discuss

  (we can simplify: if you did the suggestion at 1, there is just 1 additional path leading to discuss)

2.refactoring:

• We can now substitute path (A) in place of the "should the edit be discussed first".

  Note that this will not actually change the ultimate outcome of the process, in logic at least. Substituting is a refactoring operation.

• We now notice that the same pathway appears twice. Interestingly, the pathway we copied from is inside a loop, so it may repeat once, twice, or more times. Placing a second copy in front has basically the same effect, so this part is logically redundant.
• We have discovered a redundancy, we can now refactor further by removing the section we just substituted in.
• The new chart will be the logical equivalent of the old chart, but has lost the "should edit be discussed first" box. The process is provably the same.
• The box that has "vanished" was apparently already implicit across the rest of the process.

  This may be hard to grasp if you haven't done much refactoring before. (This is another reason I was hoping you'd be able to prove this for yourself first. :-) )

(3.)

I'm still going to sleep on this one. :-)

--Kim Bruning (talk) 01:02, 20 March 2008 (UTC)

Kim, I'm with you on step one; I considered this but thought that it is basically implied, thus left it out for brevity. My prior charts included that step; Ill see waht I can do, but the Joe will complain that someone will be confused. As to your refactoring, it sounds a bit like double talk or programming jargon to say that you don't like the first step (which you don't). --Kevin Murray (talk) 01:32, 20 March 2008 (UTC)

Yes, that's what I thought you'd think I'm saying. :-P But that's not what I'm saying. What I'm saying in summary is that the first box is already implied by the rest of the chart.

This has nothing to do with like or hate.The steps I provide constitute a logical proof that this is the case. (I could go and look up the squiggly symbols for same... but I figure that it's easier to understand if it's a picture).

If you grab some scrap paper and walk through the steps, with a bit of luck you'll grasp the logic. Else maybe I went too fast. <cross fingers>

Since flow-charts do represent logic, the proof is incontrovertible. I'm just holding back the gleeful "Q.E.D." until after you see it. :-)

--Kim Bruning (talk) 01:47, 20 March 2008 (UTC)

To wit: It works like a mathematical proof. Every step produces a flowchart that has an identical outcome to the previous one (if all is well).

You should be able to check my logic by comparing the flowchart at each step. --Kim Bruning (talk) 01:58, 20 March 2008 (UTC)

Kim, I understand the concepts, so you don't have to talk down to me, I'm not there. But, no matter how many times you say it, prove it mathmatically etc. the first box represents an implicit step in the WP process, but leaving it out of the chart implies that it is not there.

I have reworked Chart 5B (right) to try to address your other concerns. The loop only exists as long a parties can not either (1) agree or (2) perpetuate the disagreement. I've thought about including the decision box "Do you want to continue?".

I like chart 5/5b. I could simplify further. Remove “was the edit reverted?” and things downstream of “yes”. Reversion can be considered a special case of modified, and it is my observation that reverting doesn’t lead to consensus as readily as other modifications to the recent edit. I see no need to illustrate the (1. edit, 2. get reverted, 3. give up) route. The chart should not aim to be comprehensive. Removing “revert” from the chart also diminishes the impression that reverting is a respectable way to edit, and I note that nice people don’t revert anything but the worst of good faith edits. I know Kim doesn’t like to prescribe, but can we describe better practice? --SmokeyJoe (talk) 02:35, 20 March 2008 (UTC)

Yes, reversion is a type of editing, but it does put us back to status quo, where any other edit does not. It is also a very likely result of editing in a controversial or critical area, and these are where the most problems arise. Let's see waht others say; I won't make this a sticking point. --Kevin Murray (talk) 02:41, 20 March 2008 (UTC)

5b is broken again. Empty Infinite loop at discussion appropriate->discuss->is the edit accepted->is discussion appropriate. --Kim Bruning (talk) 02:57, 20 March 2008 (UTC)

No, not necessarily broken. If discussion becomes infinite, further discussion is not appropriate (see WP:BOLD). --SmokeyJoe (talk) 03:04, 20 March 2008 (UTC)

I don't quite grok your logic there, I think. Can you explain? --Kim Bruning (talk) 04:33, 20 March 2008 (UTC)

Smokeyjoe's comments are interesting... --Kim Bruning (talk) 02:58, 20 March 2008 (UTC)

On the discuss decision in 5 (which is a decent chart). If you're going to be that stubborn about it, just go and do the figuring yourself. There's little space for discussion there. Either one and one make two or they don't. ;-) --Kim Bruning (talk) 03:04, 20 March 2008 (UTC)

Note that I still appreciate your taking the time to draw so many charts. :-) --Kim Bruning (talk) 03:04, 20 March 2008 (UTC)

Yes, Chart 5b looks quite good, maybe we can do better yet? I think we could go with SmokeyJoe's suggestion Above) The chart should not aim to be comprehensive. and try Removing “revert” from the chart.

If reverts are deprecated, and I think they are, then we can try describing the more positive aspects of the editing process. This document (WP:CONS) is meant to be helpful, ie. encourage editors to understand and enjoy the editing experience.

However, if "Reverts" do retain their spot in the chart, for good reason, then we at least have explored the possibility of a minimally-simple chart. --Newbyguesses - Talk 03:29, 20 March 2008 (UTC)

5 is superior to 5b, for reasons already stated. 5b-iii-a shows promise though ;-) --Kim Bruning (talk) 04:35, 20 March 2008 (UTC)

A chart that everyone can love!

Seems discussion here has stalled/slowed since I last stopped by. I find I'm pretty happy with Chart 5, as it's even simpler than charts I've previously grown fond of. Again, I do think the first chart we show newcomers should be as simple as possible -- we don't want them struggling to understand the fundamentals of our process, and they can learn the rest as they go. At any rate, many thanks to Kevin for repeatedly drawing up new charts. – Luna Santin (talk) 17:44, 27 March 2008 (UTC)

Forum shopping

I've just read the following paragraph, with which I think we probably all broadly agree:

Asking for a consensus in a completely different "venue" or section of Wikipedia, in the hope of finding more support for a failed proposal, is known disapprovingly as forum-shopping. It's better to find the most appropriate page for discussing the topic, then ask there first and only. (This doesn't mean you can't take your proposal elsewhere if you're told you chose the wrong page for the topic.)

I imagine the last, parenthetical, sentence is aimed at editors who have inadvertently listed a template on miscellany for deletion (MFD) and been told they need to list it on templates for deletion (TFD) instead.

I'm questioning, though, the inclusion of this in the consensus policy. Surely it is quite fine and above board for a dispute to be escalated. For instance, our Requests for comment (RFC) process consists precisely of expanding the amount of attention paid to a proposal until consensus is reached to resolve the dispute, and parties failing to achieve resolution in an earlier process such as a conduct RFC can choose to escalate to Requests for mediation (RFM) or ultimately Requests for arbitration (RFAR).

So while there may be a kernel of truth in this (otherwise we wouldn't tend to nod and agree when we read the words) I think it's perhaps a case of poor drafting, or perhaps instruction creep. I think it should be redrafted or, perhaps, simply left to commonsense. --Anticipation of a New Lover's Arrival, The 14:19, 19 March 2008 (UTC)

So throw it out entirely, I'm not stopping you. :-) --Kim Bruning (talk) 17:11, 19 March 2008 (UTC)

I thought it might be better to discuss it first. ;) --Anticipation of a New Lover's Arrival, The 17:53, 19 March 2008 (UTC)

Perfidy! --Kim Bruning (talk) 19:19, 19 March 2008 (UTC) Yes, it's in that list ;-)

Maybe You'd Like To Rethink That Last Remark. (ROU, Gangster class) --Anticipation of a New Lover's Arrival, The 21:28, 19 March 2008 (UTC)

Funny, It Worked Last Time... Anyway, have at it. You know what to do, Eight Rounds Rapid. --Kim Bruning (talk) 21:41, 19 March 2008 (UTC)

You Forgot To Release The Safety Catch. --Anticipation of a New Lover's Arrival, The 16:09, 20 March 2008 (UTC)

Propose is not the mainstream method

Just pointing out that 90% of policy pages did not follow ye olde proposal process. More typical has been to document best practice over time. That's why the policy tag says "please ensure that your edits have consensus" as opposed to ... well... anything else. :-) --Kim Bruning (talk) 01:34, 20 March 2008 (UTC)

90% of policy evolved early in the project. Now people make proposals. Otherwise we'd be waist deep in guidelines rather than knee deep. --Kevin Murray (talk) 02:36, 20 March 2008 (UTC)

No. ~90% of policy has been written that way in total over all years. People can't quite agree what method was used for the remaining 10%.

We're not waist deep in policy. Radiant and friends have been fairly strict with the system.

--Kim Bruning (talk) 03:08, 20 March 2008 (UTC)

I can't agree, though I am a bit more anti-policy than Radiant. --Kevin Murray (talk) 04:03, 20 March 2008 (UTC)

I can report that the template standardization that led to Template:Ambox was a "proposal" prior to its implementation. Technically it wasn't a proposed rule, just a proposed standard... but considering how enthusiastically enforced the standard is, it's pretty rule-y.

Even if proposed guidelines or policies only turn into rules 1% of the time, that still means it's a way of creating rules. We should note its low success rate, but unless its success rate is verifiably 0%, we should not proclaim it to be 0%.--Father Goose (talk) 05:42, 20 March 2008 (UTC)

<scratches head> --Kim Bruning (talk) 06:02, 20 March 2008 (UTC)

A reason for having a low success rate in creating rules is that most proposals are flawed. We have more than enough rules already, and most wikipedians don't want any more. Frequently people propose rules where something already exists of which they are unaware. People also come up with prescriptive ideas of ways that things should or could be which fail. To say that few proposals pass is a compliment to the system. --Kevin Murray (talk) 11:28, 20 March 2008 (UTC)

"I have an anti-lightening necklace, I've never been hit by lightening, so that's proof that it works!" ;-) --Kim Bruning (talk) 20:07, 20 March 2008 (UTC)

Kim, I'm confused; are you one of the people who says "the proposal method doesn't work"? Or are you, Kevin?--Father Goose (talk) 00:15, 21 March 2008 (UTC)

For a proposal to succeed, it ought to be very sane. Not many proposals get up, the failures are not all worthless, but the successes, we hope, are excellent. --Newbyguesses - Talk 00:24, 21 March 2008 (UTC)

For the normal documentation process to succeed, all it needs to do is tell the truth. :-) --Kim Bruning (talk) 00:36, 21 March 2008 (UTC)

Not true anymore

I clarified the following, but was reverted: "If we find that a particular consensus happens often we write it down as a guideline..." This should read "If we find that a particular consensus happens often we propose it as a guideline..." Guidelines are actionable and just can't be written without demonstrable consensus. --Kevin Murray (talk) 02:34, 20 March 2008 (UTC)

I just clarified above. Still true. The proposal method was discredited, and the page describing it was redirected away. --Kim Bruning (talk) 03:09, 20 March 2008 (UTC)

Documenting global consensus is an important part of the project. That's what we're doing here. :-) So undeleted that section. --Kim Bruning (talk) 03:12, 20 March 2008 (UTC)

Though perhaps we could stress the writing of documentation more, rather than less. If you have any ideas where to put the text instead, feel free to move it or provide it with a header. I won't revert then :-) --Kim Bruning (talk) 03:15, 20 March 2008 (UTC)

Meh, I should know better. I've gone back to your edit, and created the new section :-) --Kim Bruning (talk) 03:21, 20 March 2008 (UTC)

I'm still not sure that this page is the right place for that discussion, but let's let it settle. I made a "minor" edit. I really don't like the last sentence. I really wish I could understand what you are trying to accomplich in the big picture. To me you seem to defending an ideal of freedom, but leaving the barn door open for unintended consequences such as a proliferation of contradictory guidelines etc., which will choke us. Why would that be a good thing? --Kevin Murray (talk) 03:32, 20 March 2008 (UTC)

Because no single person edits the wiki alone, what you actually have is an ecology of editors. Some of them do create guidelines, sure, but there are many others who update them, trim them, remove them, etc.

But the most important thing is that documentation is in sync with what's actually happening on the wiki. For one because that's what documentation is for of course. As a side effect you'll see that people who actually work on editing the encyclopedia tend to simplify things for themselves anyway, so harnessing their input is a good way to reduce creep.

So by stressing the ease with which "ordinary editors" can edit policy, the people who hang around policy pages and cause creep are held more in check.

--Kim Bruning (talk) 03:44, 20 March 2008 (UTC)

Can't agree. Once guidelines are accepted it is virtually impossible to get rid of them. Sad but true! The special problem with notability guidelines is that they are used for deletion of articles at AfD PROD etc. I think the problem is that we treat guidlines like policy an essays like guidelines, but the nomenclature has been set in custom. --Kevin Murray (talk) 04:01, 20 March 2008 (UTC)

Eh? Notability comes from AFD in the first place, right? That's a closed system practically, I'm not sure many ordinary editors ever use that page. When we're done here in a week or two, would you like to come and clean up Notability with me? :-) I have a feeling there might be a window of opportunity. --Kim Bruning (talk) 04:03, 20 March 2008 (UTC)

Well, we would be new best friends! But us and what army? --Kevin Murray (talk) 04:08, 20 March 2008 (UTC)

I think consensus is shifting there. It's a slight risk, but we may well get some cover, if we're careful and courteous. --Kim Bruning (talk) 04:31, 20 March 2008 (UTC)

Chart 5biii-a works for me. Cheers!--Newbyguesses - Talk 04:38, 20 March 2008 (UTC)

URK! Not 5b

5, very maybe, but that still has redundant steps. But 5b is broken. I don't know if your background is in social sciences or in hard sciences, so perhaps you think that different opinions are of equal weight? --Kim Bruning (talk) 21:40, 20 March 2008 (UTC)

CONSENSUS IN PRACTICE - ...to find the actual consensus (or what it will end up as), you actually need to carefully consider the strength and quality of the arguments themselves (including any additional concerns that may have been raised along the way), the basis of objection of those who disagree, and in more complex situations, existing documentation in the project namespace should also be checked. - The text carries the point, the chart is for illustrative purposes, not meant to be a fully working model. (Editors are not sub-routines-:) --Newbyguesses - Talk 00:35, 21 March 2008 (UTC)

Charts 1 and 5 are fully working models. I really like the idea of fully working models.

Humans are not perfect beings that can carry out subroutines, so these charts have a particular optimal outcome that can never be exceeded.

If a particular chart has as optimal outcome "everyone dies of old age while arguing forever"... you may want to consider a different chart. ;-)

--Kim Bruning (talk) 00:43, 21 March 2008 (UTC)

Yes, I agree that Chart 1 and Chart 5 work. Just thinking, Here's a rough and ready idea for A five-step process, with no branching.

Previous consensus (has been arrived at through previous editing and discussion at talk-page, VP etc.)

Make an edit

The edit is modified Yes/No

Discussion of the edit, and subsequent edits takes place Yes/No

New Consensus.

No branches, can that work? --Newbyguesses - Talk 01:05, 21 March 2008 (UTC)

It could be a solution to describe a part of the process, but without branches it doesn't fully describe the whole consensus process. However, I think that many of us are seeking a description for the process of change (CCC) which could be handled in a linear manner. --Kevin Murray (talk) 15:19, 21 March 2008 (UTC)

I still haven't seen a better flowchart than #1 so far. The original one gave a good overview of the process along with good advice about how to proceed through it, which is preferable to a more accurate (if that is even true) but less instructive chart.--Father Goose (talk) 02:10, 21 March 2008 (UTC)

• I'm happy to draw some more chart options. I like Chart 5b (displayed at project page), which I modified from Chart 5 in an attempt to address Kim's concerns, but I must have misunderstood and made it worse for him. Regardless, I was OK with Chart 5 so wouldn't object to using that. I'll upload it in case someone wants to substitute it at the page. If it works, I'm happy to change the yes and no lables to more descriptive labels, which seem to be popular. --Kevin Murray (talk) 14:51, 21 March 2008 (UTC)

Chart 5 as drawn by KM

This is the chart I would suggest. There is no need to push "revert" as part of consensus building. Editing forward is almost always more constructive, and nicer. There is no logical need to assume that Previous Consensus cannot be the same as the New Consensus. --SmokeyJoe (talk) 09:31, 23 March 2008 (UTC)

I suppose that to recognise Kim's preferred style, we might note that in continuing editing, "discuss" might be appropriately done in the edit summaries. --SmokeyJoe (talk) 09:34, 23 March 2008 (UTC)

I don't have a strong objection to Joe's chart. I prefer demonstrating that the status quo is perpetuated through reverts, but I can concede that point if it's not important to others. --Kevin Murray (talk) 14:57, 23 March 2008 (UTC)

There is a definite social difference between modifying and reverting. For one thing, one might have a volley of edits between two or more editors without any discussion necessary: just pure wiki collaboration. For another thing, reverts tend to stir up bad feelings. That's why I continue to like the original flowchart (#1) over all others I've seen so far. It documents the social aspects of the editing cycle, instead of just showing a technical approximation of it. Stripped of all useful advice, the diagram becomes a Powerpoint slide, and I don't even see the point of keeping it in the article.--Father Goose (talk) 10:01, 23 March 2008 (UTC)

Hmm, <do you accept the result?> -no-> [discuss]...

I'm not sure. This would avoid reverting good faith edits entirely (0RR is not a bad thing, I suppose ;-) ), on the other hand it doest take into account normal further editing of good faith contributions.

<scratches head> I guess that graph 1 was pretty well thought through already eh? ^^;; --Kim Bruning (talk) 20:20, 23 March 2008 (UTC)

Kim, try Head & Shoulders; you are going to go bald with all this head scratching. Seriously though, there are three problems with Chart 1: (1) doesn't acknowledge that discussing first is a possibility, (2) shows that a reversion creates a new consensus, and (3) it has at least one redundant box which could be eliminated. When I put some patches on Chart 1 (Chart 3 above) nobody liked it. --Kevin Murray (talk) 21:18, 23 March 2008 (UTC)

Discuss first: I would not reject a box representing this step as long as it stressed that pre-discussion is optional. More specifically, it's voluntary: if you feel like discussing your ideas first, you can. However, if you feel like discussing your ideas first, you will do so regardless of what this diagram says. So I don't see the benefit of adding it to the diagram.

Reversion creates a new consensus: At worst, this is a minor technical error; the arrow could be redirected to the "previous consensus" box instead of the "new consensus" box. (Doing so on diagram 1 would slightly clutter it due to the arrangement of the boxes in question.) However, thinking further about it, I started to feel that "new consensus" is the right description for it; the old result may be upheld, but it is a new consensus, comprised of a different group of participants, that has formed in support of it.

Redundant box: Yes, that could be eliminated.--Father Goose (talk) 03:49, 24 March 2008 (UTC)

"Hmm, <do you accept the result?> -no-> [discuss]..."

You should be able to go straight to the next edit, of course. --SmokeyJoe (talk) 21:55, 23 March 2008 (UTC)

"I'm not sure. This would avoid reverting good faith edits entirely (0RR is not a bad thing, I suppose ;-) ), on the other hand it doest take into account normal further editing of good faith contributions. "

The caption could state that a revert is a type of modification. It's supposed to be a simplified diagram, not an encapsulation of all that is possible. --SmokeyJoe (talk) 21:55, 23 March 2008 (UTC)

A volley of [good] edits would loop straight back to "Make an edit" from the box below, in any of the charts 1 through 5. --Newbyguesses - Talk 06:37, 24 March 2008 (UTC)

But in chart 5 (and all others derived from Kevin's changes), it passes through "discuss". You don't have to discuss iterative adjustments. That just slows the process. Chart 1 suggests "Think of a reasonable change that might integrate your ideas with theirs", which is the right advice for that situation.--Father Goose (talk) 20:20, 24 March 2008 (UTC)

Coming in late into the discussion, has the fact of whether or not the start point can/should really be called 'previous consensus' been discussed? TheRedPenOfDoom (talk) 21:59, 24 March 2008 (UTC)

Not really. At one point I think Kevin introduced the words "status quo" in its place. What's your thinking about what it should be called, and why?--Father Goose (talk) 22:18, 24 March 2008 (UTC)

'Previous concensus' makes it sound like there is/was/should be time when the article was 'at rest' / 'as good as it could be at the time' / that everyone agreed to live with / that the article at the time an editor enters has some special value. (I guess under BRD it does...) Or the point at which an editor first joins the process may not be a point of concensus. I am wondering if something like 'current state' would be a better descriptor? (and isnt there something somewhere that says 'there is no concensus version?) TheRedPenOfDoom (talk) 23:33, 24 March 2008 (UTC)

Yes, the current state or status quo is more correct. I see consensus as a process not a state of being. And as you say there may nt have been a consensus formed. --Kevin Murray (talk) 23:51, 24 March 2008 (UTC)

In the meantime, do we still have consensus for 5b to remain? I'm not seeing specific support of it, but it must be there for a reason. 1, 5, and 5c seem to be the current options, as I'm reading. – Luna Santin (talk) 17:47, 27 March 2008 (UTC)

I've switched the page back to Chart 1. If a consensus for a different chart emerges, I have no problem with that.

There is no consensus for Chart 1 and Chart 5 seems to have the most, if not minority, support. Therefore reinstated for now. --Kevin Murray (talk) 22:48, 28 March 2008 (UTC)

Separately, isn't it rather large at 400px? Would it be unreadable for anyone at 300 or 250?--Father Goose (talk) 22:14, 27 March 2008 (UTC)

400 was definitely too big. 250 might be a little small, but if others like that size, I am not opposed. TheRedPenOfDoom (talk) 22:28, 27 March 2008 (UTC)

A bit larger makes it more readable and draws more attention. --Kevin Murray (talk) 22:48, 28 March 2008 (UTC)

Proposed addition to "Exceptions" heading

What do you think of this proposed wording:

• A user is allowed to go against the consensus to correct a factual inaccuracy in an article, provided the correction is supported by a reliable source. An effort should be made to explain the merits of the correction before making repeated reversions.

Larry E. Jordan is a suspected sock puppet of Obuibo Mbstpo, and has been blocked indefinitely. Larry E. Jordan (talk) 19:51, 21 March 2008 (UTC)

I'd say that addresses too specific a problem and is a potential way of gaming WP:NPOV: "But this reliable source says all those others are wrong! I hereby override consensus!"

If you can make a clear case for something being factually correct, you should be able to develop a consensus for making the change. If you're faced with a local gang of editors going against sitewide policy, enlist help from other forums (maybe on the talk page of WP:V or something).--Father Goose (talk) 22:45, 21 March 2008 (UTC)

Village pump conversation on the use of "consensus" in policy/guidelines/etc.

Please see Wikipedia:Village_pump_(policy)#Consensus. My thesis is that we often place improper emphasis on decisions being made as a result of "consensus" or "discussion" rather than on the merits of the issue at hand (which discussion may or may not elucidate entirely). I think that, as we have found here, the term "consensus" is also a source of much confusion. But I won't rehash the whole posting here. Larry E. Jordan (talk) 19:56, 21 March 2008 (UTC)

Consensus must be formed in public

I would hope that the following does not need to be said, but maybe it does given recent history in IRC etc. - ...NPOV requires that content [and consensus] not be determined in back rooms, cabals, or private mailing lists. -per-WAS 4.250 (talk) 23:51, 19 February 2008 (UTC) [1] [Two words have been added] --Newbyguesses - Talk 21:00, 22 March 2008 (UTC)

That issue is more complex than is being stated there. --Kim Bruning (talk) 21:47, 22 March 2008 (UTC)

I don't understand this stuff about IRC and whatnot. You can't magically change Wikipedia content by making an email or saying something on IRC, somebody sooner or later has to edit the wiki, and at that point the change is subject to all the Wikipedia policies, including this one. You can't say something like "somebody told me to do this in email" because you'll be laughed off the wiki. --Anticipation of a New Lover's Arrival, The 22:34, 22 March 2008 (UTC)

Yes, the issue is more complex. One problem that is covered, I see now is stealth canvassing.

Because it is less transparent than on-wiki notifications, the use of email or other off-wiki communication to notify editors is discouraged unless there is a significant reason for not using talk page notifications. Depending on the specific circumstances, sending a notification to a group of editors by email may be looked at more negatively than sending the same message to the same group of people on their talk pages.

This paragraph applies to IRCs as well.--Newbyguesses - Talk 00:21, 25 March 2008 (UTC)

I think that particular page is crazy --Kim Bruning (talk) 00:53, 25 March 2008 (UTC)

How so, in what way is WP:CANVASS defective? --Newbyguesses - Talk 01:22, 25 March 2008 (UTC)

Among other things, it fails to account for the fact that we expect editors will discuss ongoing events between themselves. My impression is that, in an effort to prohibit a certain type of behavior while not appearing biased against new users, it was written in a way that makes it excessively broad in scope. — Carl (CBM · talk) 01:48, 25 March 2008 (UTC)

OK. I have only recently taken a look at the guideline in question; and it may be that it overstates its case. Is there a "matching" guideline which promotes healthy ways to conduct off-wiki interactions? --Newbyguesses - Talk 04:29, 25 March 2008 (UTC)

Good question. Perhaps we should write one! :-) --Kim Bruning (talk) 04:56, 25 March 2008 (UTC)

Here's a relevant snippet then from Wikipedia:Requests for comment/Wikipedia:IRC channels which would seem to promote healthy ways to conduct off-wiki interactions.

Whatever means of communication are employed now or in future, any such systems (including their users and the conversations held on them) must ensure they remain in alignment with the benefit of the project in their activities and operations, and should broadly adopt norms which encourage this. --per--FT2 (Talk | email) 12:15, 5 February 2008 (UTC)

This sounds generally right. --Newbyguesses - Talk 00:12, 28 March 2008 (UTC)

My preference is what's currently being discussed here: Wikipedia_talk:Understanding_IAR#Consensus_statements. How's that for support of your position? ;-)

But where to put it? Father Goose thinks it might best have its own page. I wonder if maybe it could better be a section someplace. Any ideas? (or bold actions?) --Kim Bruning (talk) 11:45, 28 March 2008 (UTC)

I brought this topic up because I knew nothing about it! Now, with help, I have got some idea; at least where to look for further information. I will have to "sleep on it" before making any further contributions. Thanks everyone for your help.--Newbyguesses - Talk 23:44, 29 March 2008 (UTC)

Discuss first

One big difference between Chart 1 and Chart 5x is the "discuss first" box. If there is agreement that the "discuss first" box can safely be omitted; ( I think it can, from the previous discussion on this page!) then Chart 1 probably works best, in my (h)opinion. I think working on alternative charts has been very useful, at least we have discussed various issues; it would always be nice to get input from even more thoughtful contributors. Chart 5x hasn't caused any dramas, but I am detecting a fair bit of support for returning to Chart 1. We haven't really "solved" the question of "discuss first Y/N", but it has been worked over, and doesn't look like gaining enough traction to prevail. Chart 1 has it's "discuss" box (think of a reasonable change) off to the side. It seems to me that there is most support at this time for essentially a "keep it like it was" scenario. --Newbyguesses - Talk 01:14, 29 March 2008 (UTC)

Possibly, but equally possibly I'm going to take the charts and start a new page with some of 'em. :-) --Kim Bruning (talk) 02:10, 29 March 2008 (UTC)

Chart 5c is pretty good except for that pesky "discuss first" box. We really need to discourage ownership of articles and encourage people to be bold. Just because five friends discussed something once on a talk page doesn't mean that I have to ask their permission before making further changes. I should go ahead and make the changes I think should be made, and if they disagree, then we discuss, with more bold edits being made along the way to force things forward, which eventually converge on something we can all agree with. Otherwise you just end up with endless discussions, fighting, acrimony, editors thinking they're justified in revert warring, and no consensus. — Omegatron 05:48, 1 April 2008 (UTC)

The "discuss-first" chart is really bad; aside from the fact that it discourages being bold, which is a positive behavior in my view, it means that the first decision point in the chart is a difficult question even for experienced users to answer. The chart should really include simple yes/no branching points like reverted/not reverted. Christopher Parham (talk) 06:43, 3 April 2008 (UTC)

Gauging consensus

Kevin claims that chart 5b has more support than any other version, including chart 1, but I haven't seen that from the discussions so far. I'd like to quickly test how much support there is for the various versions; I'll let this poll run for 4 days.

The result of the poll was sod all.--Father Goose (talk) 01:12, 4 April 2008 (UTC)

In support of chart 5b

Image:CCC Flowchart 5b.jpg

• I support 5, 5b, or Joe's truncated version. Or alternatively, I support Chart 3 which was Chart 1 modified to show the option of discussing first. --Kevin Murray (talk) 21:23, 29 March 2008 (UTC)

In support of chart 1

Image:Consensus new and old.svg

• Father Goose (talk) 21:13, 29 March 2008 (UTC)

• The simpler chart works. --Newbyguesses - Talk 06:16, 3 April 2008 (UTC)

Some chart

This is a good question. Nice and simple, two options. It was phrased in the negative, which is bad, but I fixed that.

• I definitely agree with there being a chart. This consensus thing starts out being horribly defined in a circular fashion in a non-real-world context. “Wikipedia does things by consensus, and consensus is how we do things. For more information, look at past practices.” The charts all highlight that consensus is achieved by a process, that it is found by evolution of the current best approximation, and that it is not one of the initial proposals that gets authorised by a vote. --SmokeyJoe (talk) 01:32, 1 April 2008 (UTC)

Polls are evil

• That and I probably want to use several of the charts, and move them to a different location entirely anyway :-P --Kim Bruning (talk) 13:40, 30 March 2008 (UTC)

I've come to see where polls are useful: a) when opinions are split over an unimportant matter (such as pagemoves), and it can be laid to rest by simply doing a headcount; and b) to gain a rough idea of how much support there is for a given idea. Polls have recently revealed, for instance, that people support a lowering of the RfB cutoff to 80%-85%. Sometimes you just need everyone to stand up and say "yes" or "no" (or something of the sort) to know what next step to take, instead of working on assumptions.

This poll certainly doesn't preclude what you would like to do with the charts... in fact, what you propose sounds intriguing.--Father Goose (talk) 20:56, 30 March 2008 (UTC)

I too dispute that “Polls are [absolutely] evil”. Instead, polls on wikipedia are frequently failed polls. A good poll has a well-defined question, and is Boolean (agree/disagree). This poll is therefore not a “good poll”. The appearance of a “third option” effectively invalidates a good poll. The wiki nature makes it harder to conduct a good poll here than it is in a traditional deliberative assembly. Of course, a failed good poll may still have been useful in stimulating participation.

I still like chart 5c, because it errs on the side of encouraging discussion (it is good enough if a few participants can keep discussion tied to a point by making the actual edits), because it doesn’t legitimise isolated acts of reversion (which I consider to be rude), and because it is simple (it has zero coss-overs). Remember that the audience is the newbie, or someone who has difficulty working with others towards consensus.

I am quite interested in seeing Kim’s proposed “more detailed charting of consensus building” page, and how he links it from the policy page. Should it link from a remaining simple chart (5c?)? --SmokeyJoe (talk) 01:31, 31 March 2008 (UTC)

I don't see how having additional options is necessarily a flaw; a poll containing only two options can present a false dilemma, which is demonstrably bad. Even if this poll is inconclusive, I think it will have value in demonstrating that we still have no consensus for any particular version. And if it shows strong support for one of the Generation 5 versions, that'll shut me up. How can you resist that?--Father Goose (talk) 03:07, 31 March 2008 (UTC)

I think Kim may have been making a joke. TheRedPenOfDoom (talk) 11:18, 31 March 2008 (UTC)

Having three (or more) viable options means that a simple vote is horribly flawed. This is well established in voting theory. Deliberative assemblies try to avoid it, as per Roberts Rules, by insisting that there can only be one active question (yes/no) at a time. By a “good poll”, I mean a poll that can be considered decisive. Of course, things that are not “good polls” can have value. Many such valuable non-good polls that I’ve seen would be better called “requests for ideas”. Father Goose seems to be using the fact that the leading candidates are near clones, and thus are splitting similar positions, to highlight non-consensus. I say that this is a demonstration a flaw in conducting a poll with a bad question. --SmokeyJoe (talk) 01:24, 1 April 2008 (UTC)

A vote on Wikipedia talk:Consensus?? Are you serious?

And no, if we're going to "vote" on Wikipedia, there should not be two options, but many. Having only two options to choose from is horribly flawed. Voters should be encouraged to vote for any option that they would be happy with, to state a rationale for their vote instead of just "support", and to propose new voting options that take into account voters' concerns. If a newer option is proposed that addresses your concerns better than an older one, cross out your older vote and add one to the newer. In this way, a proposal will eventually be made that most people can agree with. Instead of a majority rule vote, it would really be a structured form of consensus decision making in disguise. — Omegatron 05:34, 1 April 2008 (UTC)

Attempted clarification: No, I am not advocating a vote/poll/strawpoll. But if we vote, it is only valid if, in the end, there are only one or two options. Agreed, “Voters should be encouraged to vote for any option that they would be happy with”, but if multiple viable options arise, it should no longer be considered a vote, but a discussion. I agree that a rationale should always be provided. I like the way that on wikipedia votes (!votes) are weighted by the strength of the rationale provided. Yes, you go on to describe consensus decision making. This is consistent with Robert’s Rules. If the debate is continuing, a vote is not appropriate. Why are we here? I think Kim once said that the wiki is cannot be considered to be a deliberative assembly. I think maybe it can, with effort. Anyway, Weren’t you the major contributor behind the original chart? Which chart do you like (and why)? --SmokeyJoe (talk) 06:01, 1 April 2008 (UTC)

It's not a vote.

It's not a vote.

It's not a vote.

Listening yet?

I'm trying to see what the state of approval is for the various versions. I support #1, Kevin wants some version with the "discuss first", and I want to see what other people think. This will get us beyond saying "this has consensus", "no, this has consensus" and the edit war that would accompany it.

So far, the answer people have provided how dare you ask us in this manner!. I'll tell you, this "polls are evil" philosophy has become such dogma that people, when faced with a poll, criticize the poll instead of offering their opinions about the matter being queried about in the poll. "You should only offer two choices", "there should be many options", "you're trying to manipulate us", yada yada yada.

Give an opinion about the charts. Which one(s) you like, which ones you don't, and why. No outcome is predicated on what the various participants say, although if everybody seems to like one version, I'd be willing to call that a consensus.

Is that clear now? Is anybody willing to discuss the charts instead of the poll yet?--Father Goose (talk) 07:48, 1 April 2008 (UTC)

FG, at least you and I are in agreement to discuss the issue not the logistics of the poll. Halfway kidding, but I think that at minimum you made a good faith attempt to bring some closure. No matter what, we have several dedicated wikipedians thinking together here for the best interests of the project. --Kevin Murray (talk) 08:26, 1 April 2008 (UTC)

Father Goose, why so excited? You like chart 1, and that's what we've got. --SmokeyJoe (talk) 08:34, 1 April 2008 (UTC)

We're currently trying 5b on for size, actually. A little tight at the toes though ;-) --Kim Bruning (talk) 08:45, 1 April 2008 (UTC)

Sorry Father Goose. I failed to keep up with the incessant fiddling. I think it is reasonable to stick with chart 1 until there’s an agreement on which (if any) is better. --SmokeyJoe (talk) 11:05, 1 April 2008 (UTC)

Rare?

"In the rare situations where consensus is hard to find,..." Is it really the concensus of the community that it is a rare situation where concensus is hard to find? Have I just plopped into all of the rare situations? Maybe I should go buy a lottery ticket! TheRedPenOfDoom (talk) 00:13, 30 March 2008 (UTC)

Oh it is incredibly rare, almost unheard of, for us not to find consensus. We always find consensus. Of course, sometimes finding that consensus can take a certain amount of time, and involve a slight amount of disagreement. Not sure if you ought to buy a lottery ticket, maybe we need a "straw poll" on that? --Newbyguesses - Talk 00:26, 30 March 2008 (UTC)

Erm, we always have consensus. Getting to the NEXT consensus is the hard part ;-) --Kim Bruning (talk) 13:41, 30 March 2008 (UTC)

Consensus process at Talk:Race and intelligence

Kevin asked for input on 'how consensus works at the Race and Intelligence article' to gain insight into providing a 'descriptive' design of a flow chart for this page.

In the three or so weeks that I have been involved in editing that article, I am not sure that we have actually often reached much of a consensus on anything other than the fact that no one is really happy with the article as it stands.

Re: the first step in the diagram where the choice diamond is - I have not seen much that would indicate people are conciously asking that question before just making the initial edit, and even if they are, the answer seems to be overwhelmingly 'discussion? nope - just make the edit'. TheRedPenOfDoom (talk) 17:33, 3 April 2008 (UTC)

I got involved with that article as part of an AfD over a year ago. I think that it is among several troublesome articles where the consensus process is taxed, but those are where the most guidance is needed. --Kevin Murray (talk) 04:55, 4 April 2008 (UTC)

There is an old legal adage that borderline cases tend to make very bad case law. The example you cite may be a great example of a discussion in need of the kind of guidance that a consensus-seeking process should provide but that does not mean that we should look to that discussion for guidance on how to write this page. The better place to look is a discussion where consensus was clearly and definitively reached - then attempt to generalize about what worked. I'm sure there are many examples of successful consensus-building - one that sticks in my mind was the Talk:Irreducible complexity debate in July/early Aug 2005. Does anyone have other good examples that we should research? Rossami (talk) 05:27, 4 April 2008 (UTC)

I would say that at Wikipedia:Civility, plenty of the last fifty edits (13 March 2008-) have been Bold. At Wikipedia:User page, the same. (25 February 2008-). Sometimes, much discussion follows after. --Newbyguesses - Talk 06:16, 4 April 2008 (UTC)

Two things (A) I disagree about the "borderline cases", If a system doesn't work under stress it doesn't work. And (B) I think that we are drifting into being prescriptive when we deny what people are doing and tell them what they should do. Other examples we might look at are Titanic and Ybor City. I don't deny that initial actions tend to be bold, but as the consesensus process repeats discussions seem to happen in advance more frequently. This page is reaching what we could call "consensus maturation", where we are discussing more before editing, out of practicality and respect. The chart is suggesting an option, not prescribing a path. To remove the choice is to become prescriptive. Cheers! --Kevin Murray (talk) 15:33, 4 April 2008 (UTC)

We've stopped editing the page though, and are just jabbering :-P ;-) --Kim Bruning (talk) 17:41, 4 April 2008 (UTC)

True, dat.

Also, I'd like to say that any system will fail under extraordinary stress. The Twin Towers failed after being hit by planes, but that doesn't mean they were faulty buildings. Some articles on Wikipedia are a maelstrom and defy all attempts to achieve a consensus; however, the vast majority of articles can be edited less contentiously. I also think the "discuss first" option is really just the process outlined in Chart 1, but the cycle is already underway and in the "discuss" stage. Users new to an article under dispute should ideally review the talk page to be aware of the dispute, but are also right to survey the existing discussion and jump right to "think of a reasonable change" or "find a compromise". I've done that when interceding in existing conflicts, often with very good results.--Father Goose (talk) 21:55, 4 April 2008 (UTC)

Annnnd while I'm at it: if a discussion is producing compromise, that's great; it's working. If it isn't, it isn't working, and will both cement the inertia surrounding a dispute and deepen the dispute as frustration mounts. It's so easy to slip into a contrarian mindset in the midst of a dispute (and even more so an edit war), where discussion devolves into sniping and sophistry.

To counteract that pugilistic inertia, action -- editing -- is vital. But it generally has to be done by an outside party, because the parties active in the dispute have already demonized each other and are lost to the world. A bit of outside wisdom can break an argument's back (without harm to the arguers), but it has to occur outside discussion, if the discussion is broken ("Would you agree to this?" "Yes." "No, because he agreed to it so it must be bad for me.")--Father Goose (talk) 22:59, 4 April 2008 (UTC)

From Arrow's theorem, positive association of social and individual values or monotonicity: if any individual modifies his or her preference order by promoting a certain option, then the societal preference order should respond only by promoting that same option or not changing, never by placing it lower than before. An individual should not be able to hurt an option by ranking it higher. Hmm, that's curious. --Newbyguesses (talk) 06:53, 8 April 2008 (UTC)

Are you getting towards thinking of Nash equilibrium, where people "play" their game without changing theri strategy? This is generally a bad thing. Here, we are supposed to have a common goal, and we move towards it by learing from each other. --SmokeyJoe (talk) 07:48, 8 April 2008 (UTC)

In the light of that comment, yes, I think there are defects in most methods of seeking consensus, if they focus too much on supposed rules. Adhering to a common goal, and learning from each other, that sounds good. --Newbyguesses (talk) 07:57, 8 April 2008 (UTC)

Societal preference is one thing, animosity another. Haven't you ever seen someone embrace something endorsed by their political party, then lambasted it at a different time when it was put forward by the opposition party?--Father Goose (talk) 09:57, 8 April 2008 (UTC)

Yes, absolutely I have. --SmokeyJoe (talk) 12:52, 8 April 2008 (UTC)

(undent) Yasser Arafat made it to FA status - what was their process like? TheRedPenOfDoom (talk) 22:05, 8 April 2008 (UTC)