RFD: herding cats [was: on project leadership]

[Fabrizio Polacco <fpolacco@icenet.fi>]

Bruce Perens wrote:
> [...]
> Look, guys, this organization isn't going to work the way it is now.
> Even if it can't ever be run like a business, it should at least be
> run like a volunteer organization.
> Right now, it's more like herding cats.
> 
>         Bruce
> 

200 herding cats are unmanageable, it's clear.
We cannot start a riot on every fish that crosses our way. ;-)

The problems as seen from a bottom-up perspective:

- The lists have too much volume, so people tend to avoid to
  partecipate to discussions (even not reading them at all).

- Discussions go further and then die with nobody to sum up.

- All is on the Leader's shoulders; every thread is waiting for his
  Word, but reacts badly when it comes hastily formed (how could be
  differently? There are only 48 hours in his day :-)


"Divide and Conquer" was the emperor's motto, and we know that it works
well in sorting things out :-)

So I dare to come out with "something" to be discussed. These are not
all original ideas of mine: I've grasped them from the lists, but I
can't remember who has proposed each of them for the first time :-(

1) Split the development effort into pieces: every thread worth of a
   decision should become a new list where people interested in the
   topic could debate it. After some time the list should choose a
   volunteer to lead the discussion, report periodically to the proper
   main list and be responsible for what should be done.

2) Create an intermediate group between the developers and the Leader
   (or the BoD) simply composed by each of the volunteers responsible
   for "something" more than his packages (= leader of a list).


Granularity can be achieved using the rules for lists creation and
management:

a) create each list with the "full" set of subscribers, letting
   uninterested people to unsubscribe. This can seem a harsh measure,
   but the alternatives are the actual debian-devel high-volume list
   or the actual empty-on-start lists that died under crosspostings.

b) lists should be half-closed: everyone can subscribe read-only, but
   only active members can post in. More granularity: there could be
   even "private" lists, where only developers can subscribe; the
   "superlist" is surely one of these.

c) Set a limit to the number of lists in which each developer can be
   active. This is the trigger to focalize people. One can read the
   whole discussion panorama, but *must* focalize his partecipation.

d) Set few exceptions to the last rule: security lists where only
   "senior" developers can be members, high skilled (or crowded)
   lists which count more than one for the limit above, etc. ...

e) Let the "supergroup" (the intermediate level) have FIAT power with
   a simple and fast voting gear.

f) Don't use names from the corporate metaphor. A little effort of
   fantasy can avoid misunderstandings and flames. (Most objections
   to the BoD were for its name more than for its rule)

g) With the exception for security concerns, let the people feel free
   in what they do. Most of the times this is only a formal matter.


We could apply this schema also to debian-user, even if this seems more
difficult and needs a group of volunteers to manage it, but will produce
the User Council as yet requested.

Comments?

Fabrizio
-- 
+----------------------------------------------------------------------+
| fpolacco@icenet.fi  fpolacco@debian.org  -  Using Debian GNU/Linux ! |
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E |
> Dog meat? Don't worry, Gwendolen, I'm on my way! [Wallace]           |
+----------------------------------------------------------------------+