Re: Consensus (was Affordability?)
From: Becky Weaver (beckyweaverswbell.net)
Date: Fri, 16 Mar 2007 20:01:02 -0700 (PDT)
--- Brian Bartholomew <bb [at] stat.ufl.edu> wrote:

> I think the arguments justifying consensus have
> problems due to the
> presence of voting.  Eliminating all voting would
> solve them.

Aha. You're assuming the "presence of voting" in a
consensus decison-making process!  I admit I have
heard of such a thing, but it is in no way required.
The consensus process that Kaleidoscope Village uses,
for example, doesn't have a voting back-up option. 

I dimly recall that there was a time when a "voting
backup" was considered prudent because people had
fears about consensus decision-making. But as the
knowledge base and skillset of those in the
group-decision-making world has improved, I think that
view is unmerited. 

> However, in cases when consensus reaches a deadlock,
> it resorts to
> majority vote.  

Certainly not.  

> It is said that consensus processes only work in
> groups that have a
> common aim, but that coho groups have common enough
> aims that the
> failure rate is small and tolerable. 

I disagree. To some extent, it depends upon the phase
a cohousing group is in. My only cohousing experience
is with a pre-move-in group. My experience in that
situation, is that "cohousing" is nowhere near a
clear/common enough aim. To succeed, groups in the
development phase must have a very well-defined aim,
covering location, expected price, environmental
philosophy, seniors-only vs. multigenerational,
expected level of participation, etc. 

Once built and moved-into, a community's material
reality answers many (though not all) of these
questions such that they are no longer issues. This
probably changes the equation somewhat. 

> However,
> messages that say in
> effect, 'don't depend on a van unless you can
> maintain majority vote
> political control of it', suggest to me that
> important differences in
> aims are not rare, and consensus is substantially a
> majority vote system.

I honestly don't understand how you are getting this
idea from what has been said on this list. Has
something along these lines happened to you in a
purportedly consensus-based organization? I am
interested to know what experiences lead you to hold
this concern. 

> Becky Weaver <beckyweaver [at] swbell.net> writes:
> 
> > *if* a project aspect such as a van is *not*
> considered an
> > important, financial-survival type item, it might
> get relegated by
> > the community to interior-decoration-type status.
> 
> What if a van is only a financial-survival type item
> for the few
> lowest income group members.  The group does not
> have a common aim in
> this area.  Where does the moral authority to
> default on a consensus
> promise made to this minority come from?
 
I can only conclude that you have never seen a
functional consensus process in action. 

In a consensus-based community with no voting backup,
the situation you describe might be handled this way: 

Defining the problem: We thought we could afford to
buy and maintain a community van. However, on further
exploration, it turns out that our consented-upon
maximum community assessments will not cover these
ongoing expenses *and* all the other expenses we have
already agreed must come out of the common funds. How
are we going to handle this? 

Looking for possible solutions:
We could:
- Arrange a carpool with personal cars, no van
- Set up a telecommuting office instead 
- Move to a different location
- Raise our assessment fees
- Give up
- etc.

The community looks at all the options on the table.
They agonize, discuss, brainstorm, etc. Do you really
think that 20 adults, competent enough to hold down
jobs and buy houses, can't come up with *any* better
solution than to kick the "minority" in the heads and
tell them to suck it up? 
 
> > If the van is a core personal value for only a few
> members, and the
> > community has to make a hard decision, the van
> might have to go for
> > the financial well-being of the community as a
> whole. Not because
> > nobody cares or is untrustworthy; but because the
> community is
> > struggling to find a solution that will cause the
> least harm overall.
> 
> This is utilitarianism: Sacrifice the van-dependent
> to save the
> project for the rest.  

I think you are building an artificial scenario with a
rigid two-choice either-or setup. You are creating a
"sucker's choice," i.e. artificially limiting the
options in order to justify a harmful action. "I
coudn't help it, it was him or me." 

One huge benefit of a functional consensus-based
decision-making process is that it creates paths
through a sucker's choice that an individual might not
find for himself. Sometimes the solutions that emerge
are amazing, in that no individual walked into the
meeting envisioning anything like the solution that
the group as a whole consented to a the end of the
meeting. Such a meeting can be truly inspiring to take
part in. 

> It's not a principle I would
> consent to in a
> decision-making process.  Not only do I not want to
> treat other people
> this way, but at any time I could become the next
> sacrifice!

Of course not! Consensus decision-making is a very
good way to ensure that doesn't happen, because when
everybody is trying to *solve a problem* instead of
*choose between several options,* they are more likely
to come up with solutions that answer all concerns. 

It sounds like you would benefit from reading some of
the consensus decision-making references out there. I
like to refer people to Tree Bressen's resources page:
http://www.treegroup.info/resources/ . 

Good consensus decision-making processes really do
obviate the kind of scenario you present above. I am
very sorry if you have run afoul of a group using a
poorly functioning "consensus" process. Honestly, it
doesn't have to be that way. 

Sincerely,

Becky Weaver
Kaleidoscope Village, Austin, Texas



___________________________________
A man becomes his attentions. His observations and curiosity, they make and 
remake him.
--William Least Heat Moon

Results generated by Tiger Technologies Web hosting using MHonArc.