On the bah-ohs-talk list there's some talk of how to do decision
making. This is stuff I wanted to share but also made me feel
like I was spraying.

This is also related to the unrevdb experimentation Kathryn and I
are doing. In there, observers will be able to evaluate the value
of a message by rating it.

----------
Date: Sun, 26 May 2002 17:30:14 -0500 (EST)
From: cdent@burningchrome.com
To: ba-ohs-talk
Subject: Re: [ba-ohs-talk] What are we trying to accomplish?

On Tue, 21 May 2002, Eric Armstrong wrote:

> Other alternatives for decision making including voting
> systems, and "rated evaluations", where an alternative
> eventually snowballs to victory based on the strength
> of the evaluations and the reputations of the people
> giving them. (So when 3 very respected people give
> proposition X a "+5", I'm inclined to go along for the ride!)
>
> Personally, I think that rated evaluations make a lot of
> sense. But we need tools to structure the decision and
> sort things according to their ratings so the cream rises
> to the top, where it is on screen.

(There's a fair amount of personal spray in this message, and for
that I apologize, but I figure it's worth sharing some of this
stuff.)

As an aside, I have some very simple perl code called
Agendamaker, which is a very simple, semi-anonymous, consensual
issue management system. I don't think I've mentioned it before
but I'm not sure[1]. I used it in a workplace to encourage those
without a voice to raise issues (literally) up an agenda. There's
more info here from an advogato entry on July 29 of 2000:

   http://www.advogato.org/person/cdent/diary.html?start=19

One iteration of the code is here:

   http://www.kiva.net/~cdent/cgi-bin/toot/agendamaker.cgi

that page has a link to the source. I used it as part of a CGI
tutorial I did for the tech support people at that organization.
That's at:

   http://www.kiva.net/~cdent/toot/

Unfortunately I've recently discovered that my cookie management
(preventing individuals from voting more than once per issue is not
really working).

I mention this because in separate conversation with Mei Lin
about high performance teams I recalled that what makes a team
high performance is not complex, highly-engineered tools that do
lots of neat stuff, but instead the will to be high performance,
the ability to share knowledge, and an attention to processes that
allows for the identification of the tight roadblocks to
communication and process. If those roadblocks can be identified
some of them can be eased or removed by small, focused tools that
are not complicated in themselves but have large results.

Agendamaker was supposed to be one of those tools but it did not
achieve the desired results. Instead of giving voice to people,
it led to the confrontation that nearly got me fired and caused
me to leave my job. However the methods had led to some other
tools and processes that were very helpful:

  McFeely (a generic distributed task automater):
    http://web.systhug.com/mcfeely/
    See:
      http://web.systhug.com/mcfeely/examples.html
    for examples of what it was used for.
  Arts (a simple knowledge base manager):
    http://arts.sourceforge.net/
  A simple search interface to the group email archive, using
  glimpse, just from the command line:
    http://www.webglimpse.org/

None of these tools are even remotely close to perfect, but they
loosened roadblocks that raised our productivity immensely.


[1] Webglimpse is not a perfect tool, but could provide an easy
system for creating indexes of the mailing list archives. With
that I would have been able to search for reference to
agendamaker in the archives. This is a considerably different task
from the conceptual access on which Kathryn and I are working.