What does "consensus" mean regarding TWiki?

Specifically regarding TWiki's direction, development, writing, and organisation?

The word consensus is slung around a lot and it does have this warm fuzzy feeling to it. But I wasn't sure what it meant in general, and I'm even less sure what it means regarding TWiki. So I looked it up:

From the American Heritage Dictionary:

1. An opinion or position reach by a group as a whole.
2. General agreement or accord

Yep, still a warm fuzzy feeling. But what does it mean specifically to TWiki and, to a lesser extent, OSS in general? Here are some questions I have:

• What is the "group"?
  • Whoever is in #twiki during a discussion?
  • Whoever is in #twiki_edinburgh during a meeting?
  • Whoever comments in a Codev topic?
  • The "Core group", whatever that means?
• What constitutes general agreement?
  • 100% agreement?
  • A majority, with the minority accepting the agreement? What constitutes a majority?
  • A majority, with vehement opposition by one or more people?
  • A majority, as long as no one from the core group disagrees?

Without some general agreement of what consensus means (and, yes, I realise that this is self-referential to this topic), how are "we" (ditto) to ever decide (ditto again) when a consensus has been reached?

-- Contributors: MeredithLesly

Sounds like an excellent dictionary. Could you lookup "compromise" for me while you're in there?

-- SteffenPoulsen - 15 Apr 2006

A couple of definitions:

• A settlement of differences in which each side makes concessions.
• A middle way between two extremes

Note that the first implies that there are a small number of "sides" and the second implies that the extremes are at the ends of a continuum.

-- MeredithLesly - 15 Apr 2006

I should also point out that having to reach consensus before being able to do something is as anti-wiki as I can imagine. Which is not to say that anarchy should reign. But there's a certain irony in having to regularly engage in anti-wiki behaviour while working on what purports to be a wiki.

-- MeredithLesly - 15 Apr 2006

Sometimes actually seeing the painting helps in discussing what the painting should look like (finding a good compromise/establishing consensus). - And this is even if the sketch is not done on the final canvas.

-- SteffenPoulsen - 15 Apr 2006

Well, as I said elsewhere, it's pretty clear that it's a waste of my time to do anything but fix bugs when I need to, write plugins when I need to, and write documentation that ordinary users can use. The general TWiki community will gain from my programming skills but not my documentation skills. Oh well.

You still haven't addressed my main questions, however: what constitutes a consensus?

-- MeredithLesly - 15 Apr 2006

I can only state my opinion: Consensus on i.e. a change is ~reached if and only if "the change" [tm] "makes it" and becomes "body of TWiki". Even then the change will usually represent a compromise, not consensus per se.

At any time, even when "the change" has made it to the body, consensus can break, and a new questioner of the change must be made part of the compromise. All to uphold highest degree of consensus possible (and to allow the change to continue towards body).

-- SteffenPoulsen - 15 Apr 2006

I'm struggling with the consensus idea and its relevance in an open source project.

Most (all) changes to TWiki have been because someone wants that change. Thus, those changes are all for a customer/user.

Now, I notice that there are alot of people asking for 'Concensus' before they write code - in many ways, this means (to me) that they either don't have a customer, or don't really want to develop it (or in the case of non-developers, support and encourage a developer to take an interest in it).

I do see the importance of Consensus in determining what goes into a release, and what needs to be a plugin - but trying to tell people what they should or should not be intersted in?

-- SvenDowideit - 16 Apr 2006

This discussion has missed thus far a fundamental distinction about "consensus" that for me is the starting place for any meaningful disucssion - that is, the distinction between consensus in the general sense of common agreement and consensus as a defined process for making decisions.

Except for very small, informal groups, the statement that "we make decisions by consensus" is really only meaningful within the context of having a clear structure of authority and decision-making. The real issue in TWiki.org is not with our degree of concensus or lack there of, but that there is simply is no clear structure of how we make decisions, or indeed who has the authority to make decisions - be it about what goes into a release, where development focus should be directed, or how twiki.org is organized. What we have as result, is what was once referred to as "the tyranny of structurelessness." This kind of situation is virtually guarenteed to engender frustration, confusion, and resentments on all sides. It also tends to obscure where and how the real power in decision making is exercized.

In short, I think it is time to review, renew, and revise as needed the basic "social contract" that underlies our shared community around developing the best wiki in the world. A good place to begin, and I began this a bit over the weekend, is to review how other open source projects are governed. So far, I haven't seen anything that exactly matches the circumstance and needs of this community.

-- LynnwoodBrown - 17 Apr 2006

Seen from the sideline TWiki is a project with constant battles for power. The picture is very clear in #TWiki on Freenode IRC where these constant battles for power are going on. And also here on Codev where every 2nd topic created is about who decides what.

I have never seen a project in any private or public or sport or anything that could work without a project manager or coach that the rest of the team follow because the only way a team can accomplish and win is by going in the same direction towards a common goal.

In any modern private project team or any well working sport team the leader listens to the team because the individual team members are often more experts in their special fields than the coach or project manager. And any proposal which is great and that both the project manager and a "consensus" among especially the most experienced team members will be no-brainer decisions that take off and fly right away.

But the reality is that we do not agree on everything. There is not consensus on every thing proposed. Let's test ourselves

• Plugins on SVN
  • Plugins should only be one place on SVN (reasons I have heard are e.g.: "plugin authors are not regular developers and they get confused", "I do not want to bother maintaining plugins many places", "plugins for each release branch promotes making plugins not compatible with all/latest few releases")
  • Plugins should be in every release branch (reasons I have heard are e.g.: "plugins cannot be compatible with all releases", "plugins needs to be able to take advantage of features of the next major release", "plugins authors need to be able to have a broken work in progress plugin in DEVELOP while maintaining a stable version in TWiki4")

• New Webs on twiki.org
  • Create an attic web in which to throw all the stale codev topics. (example reasons: "I cannot cope with the 1000s of topics on Codev")
  • Do not create an attic web. (example reasons: "Does not really solve the problem with the stale content. You just move the dirt around and make it more difficult to know where to go when you arrive at twiki.org")
  • Create a doc web with docs for normal users. (example reasons: "TWiki web contains too many difficult documents that newbies will not understand", "Need a clean place to build up a place with only the most important docs")
  • Do not create a doc web with docs for normal users. (example reasons: "How long is a newbie user newbie? When he gets more advanced the split in two different webs will make it more difficult to find the right info", "The problem is true but should be resolved by better start pages and better structures left bars")
  • Create a showcase web. (example reasons: "We need a place where users can share fully working twiki apps that can sell TWiki", "We need a place where users can pick up good examples of complex searches, ways to use forms etc")
  • Do not create a showcase web. (example reasons: "It appears out of nowhere and there was nothing in it so I removed it", "It is a great idea with a showcase but it would be best if there was a dedicated server for it where really advanced twiki apps that assumes its own web with forms and everything can be installed and really sell TWiki")

• TWiki compatibility (where are you in the scale from 1-5)?
  1. TWiki does not need to be backwards compatible. The users can stay on current version. It is the developers that does the work so they decide everything and the users shall just be happy and shut up.
  2. TWiki should be forked out in a TWikiPro which is not backwards compatible and a TWiki Classic which is just barely maintained with bug fixes and no new features.
  3. TWiki should follow the TWikiMission as the general rule. Protecting the great value invested in the information contained in topics should be first priority. Our customers should be able to upgrade to new versions of TWiki and still be able to use their already created topics. Upgrade tools/scripts are OK.
  4. Same as above but upgrade scripts should be avoided with very rare exceptions.
  5. TWiki must always follow the TWikiMission to the last letter. There can be no exceptions.

• Mr NN currently prevented from participating on twiki.org should have his account re-activated.
  • Yes, forgive and forget
  • No, the original reason for it has not disappeared.
  • Keep me out of this discussion. This is where most of us are I guess. We that likes both parties of the conflict don't want to take side.

Just those 4 examples will show that we do not all agree on everything above. And we will not be two teams: The white hats on one side that agree with each other on one side and the black hats on the other side that all agree on the opposite. We will be split differently on each topic. And there are topics where most will choose not to take side.

This project has been in a leadership crisis for years. And there is not one person to blame. Peter could chose to very visibly act as the God King. Heil the God King! I think this project would loose key developers if this was the approach that was taken. The other extreme is the "I will try to be friends with everyone and see how it goes". Been there. Tried that. Did not work. Because it leaves a power void. The tone on #twiki not nice and must scare away people that just come to get help or find out if TWiki is a project for them.

Again COMPROMIZE is needed.

Time for proposals!

I think the best way for this project to move on is:

• Split power on several individuals. They are given the power by the community for one major release at a time. The developers will respect that this person has the "last word" in the cases where consensus cannot be achieved.

Areas of competence.

• twiki.org and its structure
• The DEVELOP branch - the power to refuse code because of quality level or poor implementation.
• The TWiki4 branch - the power to refuse code because it is not just bug fixes or poor implementation.
• SVN. Decides who has access and who does not
• Bugs web. Decides how develop.twiki.org is organised and working.
• Advocacy. Decides how TWiki should be profiled in the public.
• Release Management. Decides how releases should be built and managed including the list of distributed default plugins.
• Pattern Skin. Decides how the main default skin looks like and works.
• Security. Decides if a report is a threat that needs the special action or not.

• Core Team Veto: If all - no exception core members can agree against a decision a veto can be made to revert or delay a decision.

The areas can be combined. They are just my proposal. And in all areas the rule should be - try to reach consensus first. The person that has been granted the priviledge should only need to make a formal decision when needed and always in writing on Codev and always with a detailed reason.

I do not consider myself to have enough "old" in the core team to seek any of the positions. I am perfectly happy with the influence I have already. I feel that people listen to me very well. But I know this is not the general oppinion among developers and this is why I make my proposal.

-- KennethLavrsen - 17 Apr 2006