RE: [AD] Allegro Leadership Structure

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Michael Bukin writes:
> IMHO, it is necessary to define 'priviledges' for the dictator,
> i.e. duties and rights.  Otherwise, amount of work may scare potential
> dictators, and nobody will agree to become one.

How about:

- Code changes can be made by anyone who has CVS commit access (obviously
:-) When people without commit permission have new code, they must send it
to someone on the commit list, who will check it over for naming
consistency, general quality, etc, before it actually gets committed.

- API changes must be approved by the dictator. This doesn't mean they have
to do the work, just that nobody commits any changes to the API (this
includes adding new features as well as altering existing ones) before the
dictator agrees that this is a good idea. In practice this is unlikely to be
much work (usually the issue will be debated by everyone, so the dictator
only has to say "ok" to whatever result of that discussion), but it makes
sure these big changes will always get an extra layer of scrutiny before
they are put into practice.

- The dictator is in charge of adding and (in worst case) removing people
from the CVS commit access list.

- If the dictator wants to retire, or if too many people disagree with them,
the CVS commit people can have a majority vote to replace them with someone
else.

Most likely none of this will ever actually affect anything, but it can't
hurt to have a slightly more formal legalistic type fallback position just
in case the usual "talk about it until everyone agrees" method does someday
break down :-)

I agree that Peter would be a good choice, or maybe a trio of Peter, Michael
Bukin, and Eric Botcazou? (in which case use a vote to decide any nasty
issues). In fact, all the active developers seem competent to do this, but
those three have been around longer than most...


-- 
Shawn