Concerns about the idea of "Project Scud"

[Wouter Verhelst <wouter@debian.org>]

Hi,

While I agree that Debian needs change if we want to face the future,
and that the idea of Project Scud might be the change we're looking for,
I still have a few reservations, mainly situated around the status the
team, as proposed by Project Scud, will have in the Debian Project's
structure.

As we all know, the Debian Constitution does not define the DPL's
function as a team; it only defines the DPL's function, that of the
Project Secretary, the Technical Committee, of Delegates, and of the
Project's Developers. By excluding the bodies that are not of relevance
to the DPL's position, there are only two options:
      * The members of Project Scud (other than the DPL himself) do not
        actually have any real power, except that the DPL will stand by
        them if any of their decisions are challenged (thus, their power
        will only exist de facto);
      * The members of Project Scud (other than the DPL himself) will be
        formally appointed as delegates (thus, they will have real
        power, backed by our constitution).

Both have their problems.

The first option leaves us in a situation that, IMHO, feels very
awkward; should the DPL seriously disagree with some of the team
members, it may jeopardize the whole undertaking. While I understand the
intention of Project Scud is to avoid this, the possibility is still
there, and I feel very uneasy at the thought. I am also not so sure it
is a good idea to create the sort of semi-official body this team would
end up being, if it is to make decisions of great importance to the
whole project.

The second option has some procedural problems; I understand the idea of
Project Scud is to share the whole of the DPL's responsibilities amongst
a group; however, that is in conflict with the phrasing as it exists in
section 5.1, first point, of the Constitution, specifically,

"
The Leader may define an area of ongoing responsibility or a specific
decision and hand it over to another Developer or to the Technical
Committee.
"

because, if the intention is indeed to share the whole responsibility of
the DPL among a group of people, then to "define an area of ongoing
responsibility" is exactly what the Project Scud-DPL will not be doing
("make the decisions the DPL will usually be making" does not qualify)

Another concern is what will happen if Project Scud's experiment is
successful. Will the team remain the same, or will other people be
appointed? If the former is true, what guarantees are there to make sure
that accusations of it being some sort of 'cabal' will not be grounded
in truth? If the latter is the case, how will this be done? Will the
team simply cease to exist, leaving the next DPL to make up his own
team, or will the team choose new members among the existing developers?
Or will we have a 'DPL Team Election' next year, rather than a 'DPL
election'?

I would appreciate it if Project Scud members (not just those that are
DPL candidate), would address my concerns.

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune