Re: A Solution

[joey@debian.org (Martin Schulze)]

Good morning folks,

Peter Tobias made the following proposal.

It contains all the ideas that I had have for the leading of the
Debian project.  I really would appreciate that the BoD and Bruce
would accept this proposal and we could get back to work.

| IMHO the best for the project would be:

| 1. (VERY important things)
|    - Bruce resigns as the president but stays on the board.

This would end the situation we have at the moment.  Bruce decides
strange things without discussion with developer (maybe without
discussion on the board, too?  I don't know).

|    - board members who have positions like vize-president and
|      so on resign from this position too but stay on the board
|      so we don't get a big hierarchy but a flat system where
|      we have the board and the developers (and of course the
|      users).

All members of this consortium (I prefer that name) have the same
rights.

|    - we DON'T elect a new president and other positions like
|      that. IMHO we don't need them.

True!!  Many of us thought that the board would be _the_ consortium
that makes the decisions.  Unfortunately they/we misinterpreted it and
Bruce still has all the power and can make decisions on his own.

|    - decisions should be made by the members of the board by
|      vote (the board is the democratic representation of the
|      Debian developers/community).

Proposals from developer that don't come to a decision have to be
discussed in the consortium, too, to get a decision.

Brian White wrote:
> This is fine for matters of policy, but you need to have a group
> of people that actually get things done.  Removing the existing
> hierarchy will only leave people not knowing who is doing what.

In former times this worked.  People made a proposal and finally
implemented it.

Partially our structure has to be reverted.  We IMHO need a public
available todo list.  It explicitely has to contain a detailed list.
So everyone who has some spare time or would like to do some
organizing, programming, documentation could try to fulfil one task.
(just like winni modified the init procedure which is much smarter
than the actual one, or like I modified adduser to support shadow
passwords)

Your list is an important step into the right direction.  I don't know
why you have never fulfilled my request to putting it on the
ftp-server - I even don't remember an answer...

The called group will exist.  I for myself am kind of sick of
maintaining packages that I don't want and never wanted to maintain.
I'd be happy to give some of them away and fulfil some of these tasks.

| 2. (Important things)
|    - the board assigns officers for specials tasks (for example
|      the webserver) and gives them limited power to decide
|      some things (the board can overrule the officer by decision)

These managers have enough power and rights concerning this task to
fulfil it.  Again, important changes should be discussed with the
consortium, if the answer is "no" they have to skipped.

I have come to the oppinion that it is bad idea to make one person
responsible for the whole project.  Partially it is too much stress
and too much responsibleness.  If it is only one person only one
person is flamed for his decisions.


|    - long term positions like the treasurer and so on should
|      be assigned to persons outside the board. There should
|      be only very few long term positions.
|    - the board should maybe have 2 or 4 more members (I'm not
|      sure about that)

I believe 8 ppl are fare enough.

|    - the board sents a short report about the decisions to
|      debian-private or debian-devel. The report has to include the
|      voting result (for example 5x yes, 2x no and "1x don't know")
|      and a short (1-2 lines) text why the decision was made (these
|      mails should be stored somewhere so we can look at it later
|      when a similar problem arises). If there is a 4 votes to
|      4 votes situation let the people on debian-devel decide.

Seconded.  Very important!!!

|    - elections for the board should be held every 6 months.
|      6 months is a long time. A short period makes it easier
|      ensure that there won't be arrangements between the board
|      members which would lead to a "one person decides" situation.

I for myself think that 6 months are enough.  I think we could also
live with a one year term.  I don't think that this period is that
important.

It is much more important that our leader in conjunction with the bod
decides to follow this proposal and that we can go on making our
distribution.  I heavily request for this

|    - we could either let the board decide when it is time to
|      make a decision about a topic that is discussed on debian-devel
|      or we create a way to send "decision-requests" to the board
|      (for example a given number of Debian developers have to
|      express that they think that a decision by the board is
|      necessary.
| 
| 
| Advantages of this proposal:
  ----------------------------

| - no decisions are made by a single person

Correct: no too important decision

| - it's a democratic way of deciding about important problems
| - ALL members of the board are responsible for a decision
|   and not only Bruce

Not only one person at all.  If something is decided then everyone
knows that there was a discussion in the leading commitee or
consortium and sees the result.

| Disadvantages of this proposal:
  -------------------------------

| - Bruce and Dan would lose their titles "president" and
|   "vize-president"

But what are titles?  Our goal is to create and maintain the best
distribution of Linux and to support free software.  Our goal is not
to create titles with which people can adorn theirselves.

| I think this is a proposal that the majority of Debian developers
| could live with.

This proposal would get us back to our original goals and would stop
this stupid rumors.

Gruesse,

	Joey

-- 
  / Martin Schulze  *  joey@infodrom.north.de  *  26129 Oldenburg /
 / The MS-DOS filesystem is nice for removable media             /
/                                             -- H. Peter Anvin /