Re: Concerns about the idea of "Project Scud"
Op di, 08-03-2005 te 17:20 -0800, schreef Steve Langasek:
> 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?
I see the function of DPL, and the responsibilities that lie in that
role, to be of great importance to the whole project. If the
responsibilities of that function are shared among a group, then it is
likely that this group will be making important decisions.
> > 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?),
I have not, but I didn't think it relevant at first. That might have
been a mistake, if the plan is really to delegate on a per-subject basis
(as Andreas explained to me on IRC), rather than naming the people in
the beginning of the year as I thought you planned to do.
> 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?
The fact that the decision cannot be un-delegated in the second
scenario, whereas it /can/ be ignored in the first.
However, if the plan is to delegate cases, rather than responsibilities,
then this isn't as important as I thought it was.
> 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?
I imagine past DPLs to usually have requested information from their
delegates, or normal developers involved in the subject they are about
to make a decision on, rather than working with a small 'DPL-team' who
will always be the same people for the whole term.
I'm not saying that having a small team instead of one person in this
position is necessarily a bad thing -- on the contrary. However,
creating such a small team might lead to the idea among Developers that
there is a group of people that make all the decisions of the Project,
and that there is no way a "mere mortal" developer can influence them.
We already have people flaming our delegates on -devel every time their
pet problem is popping up again; it would be naive to assume that these
people would not flame the DPL team members, I'm afraid.
Let me turn your question around for you. How is it better to create a
small 'core team', rather than to consult those people actually working
in the field -- delegates, prominent developers -- when the elected DPL
requires input?
> > 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.
It appears my last paragraph wasn't clear, then :-)
The first part of my mail was about expressing the reservations I have
regarding the potential for success of project scud. The second part
(this part) assumed that Project Scud /would/ be successful, and that
after a term of one year, people would want the experiment to continue.
Thus, the question here was: how, if at all, will you ensure that there
will be some continuation of this team (i.e., that not all would say
'bye bye' after the one-year term has completed), while still allowing
people to leave if they have other interests, and fresh blood to join
the team?
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: