[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Concerns about the idea of "Project Scud"



Hi Wouter,

On Tue, Mar 08, 2005 at 03:36:33PM +0100, Wouter Verhelst wrote:
> 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.

Out of curiosity, what decisions of great importance do you see such a team
making?

> 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)

So on the one hand, we have a group of chosen advisors, who have no formal
power, that the DPL can ignore at his whim because he's the only one with
constitutional authority; and on the other hand we have a group of chosen
delegates, who have power over specific areas of ongoing responsibility (or
over "specific decisions" -- you seem to have omitted that part of the
constitution when citing?), whose decision cannot be un-delegated, but whose
delegate status can be revoked at any time by the DPL because this is his
constitutional authority.

Where is the significant difference between these two scenarios?  How does
identifying a particular pool of potential DPL delegates that the candidate
plans to work with, or a particular group of fellow developers that he plans
to consult, make this untenable compared with past DPLs, who have surely
also not made their decisions in a vacuum?

> 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 really don't see how I can answer that question satisfactorily; if you
have concerns that a group of known, verbose developers are going to become
a shadowy cabal, or that they would try to cling to power without the
consent of the new DPL, I don't know why you would believe any reassurances
I gave you to the contrary, either.

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: