On Wed, Jan 08, 2014 at 12:10:08PM +0000, Neil McGovern wrote: > > All, > > I think me and Kurt have now reached consensus about the issue - and as > such we'd welcome any comments on the draft, available below!
As there has been no comments on the draft text I'll make that
the official response. I want to thank Neil from writing this
all down.
Lucas,
I suggest that you read the summary carefully and review existing
delegations. I suggest that you make sure that you're delegating
a responsibility or decision.
Kurt
> ---------- draft below ----------
> It seems that two separate questions are being asked. Firstly, what is
> the ability of the DPL to create a delegation, and how pescriptive can
> this be on the day to day working of a delegate.
> Secondly, on the status of the Debian Policy Editors, and if they can be
> delegates.
> I will deal with both in turn.
>
> In writing this, general commentary appears { in curly brackets } -
> these bit aren't official interpretations of the constitution, but a
> commentay of my own :)
>
>
> 1) Ability of DPL to make pescriptive delegations
> The Debian Constitution is quite clear:
> "The Leader may define an area of ongoing responsibility or a specific
> decision and hand it over to another Developer [...].
> Once a particular decision has been delegated and made the Project
> Leader may not withdraw that delegation; however, they may withdraw an
> ongoing delegation of particular area of responsibility." (5.1.1)
>
> "The Delegates are appointed by the Project Leader and may be replaced
> by the Leader at the Leader's discretion. The Project Leader may not
> make the position as a Delegate conditional on particular decisions by
> the Delegate, nor may they override a decision made by a Delegate once
> made." (8.2)
>
> "Delegates may make decisions as they see fit, but should attempt to
> implement good technical decisions and/or follow consensus opinion."
> (8.3)
>
> This means that delegations should take care not to perscribe any
> particular process, or method for working that a delegate should adhere
> to. It is up to the delegate(s) to form a team and to produce a process
> themselves. It is, of course required as above that delegates should
> attempt to implement good technical decisions and/or follow consensus
> opinion.
>
> As a guide - it is the wording that "ongoing responsibility or a
> specific decision" that should be delegated - powers to act in an area,
> but not how that power should be wielded. How to organise and the
> process for exercising a power is a decision in itself, and thus for the
> delegate to decide.
>
> Should a delegate make a decision, or create a process or proceedure
> that the project is unhappy with, a Debian Developer is free to refer
> this to a General Resolution to reverse any taken decision.
> In a special case, where the decision is explicitly a matter of
> technical policy, it may also be referred to the Technical Committee, to
> decide the matter under 6.1.1:
> "This includes the contents of the technical policy manuals, developers'
> reference materials, example packages and the behaviour of
> non-experimental package building tools. (In each case the usual
> maintainer of the relevant software or documentation makes decisions
> initially [...])". This requires a simple majority.
>
>
> 2) The status of Debian Policy Editors, and the ability to be delegated
>
> To answer this, a series of questions should first be addressed;
> * What can the DPL delegate?
>
> In general, this reading of the constituion is being done from a
> "permissive", rather than "restrictive" view. ie: a developer may do any
> task which they have a general competence to do, rather than only being
> allowed to do anything explicitly defined in the constituon. This seems
> to follow the project's general favour towards "do-ocracy"
> If a restrictive view is taken, then a number of issues arise. For
> example, an individual may only make any technical or nontechnical
> decision with regard to their own work, and may not affect other
> people's work (3.1.1). It is likely that nothing that affects more than
> one person's work would ever be completed without a prior delegation
> from the DPL. Thus, a "permissive" view is more consistent with how
> current practice in Debian has developed.
>
> Further, the ability of the DPL to delegate is explicity not limited to
> decisions that the DPL can themselves do. See 8.1.2 for example, as the
> Debian Account Managers are not a function of the DPL, but are
> delegates.
> { There are things that the DPL cannot delegate, for example the
> secretary, and tech-ctte members/chair, these are appointments. }
>
> However, what is key here, and covered above in the first part of the
> mail, is that it is a decision, or a power must be delegated, not simply
> a process. Thus a sucessful delegation should be, for example, for the
> Policy Editors to be the primary decision makers on what goes in Debian
> Policy. This could mean that the Policy Editors could make a policy that
> no packages shall contain the letters q or z by pulling letters out of a
> hat and this would be within their powers to do so.
> { I suspect that this may come before the tech-ctte, DPL and a GR rather
> fast, however! }
>
> It is also important to note that delegations should not be used to
> implement change where responsibilty is already defined. The decision of
> a maintainer which effects their package content only is for the
> developer to make, although of course within the confines of what the
> project as a whole allows.
> Essentially, the power of delegation for general matters arises from
> "The project leader may make any decision for whom noone else has
> responsibility." (5.1.4)
>
> { And this would also apply to libraries - although there is an affect
> on other packages, it is a change that is taking place within a package
> itself. Again, uncoordinated transitions may well be frowned upon by
> another delegated team... :) }
>
> * What /is/ Debian Policy, and is it simply a package?
>
> It seems clear that Debian Policy is a concept, rather than simply
> another package. Not only is it referenced in multiple places as so, but
> it it also published at http://www.debian.org/doc/devel-manuals#policy.
> The fact that it is *also* a package is orthagonal to that. If the
> Policy Editors were simply package maintainers, without any additional
> decision making powers, then whatever goes in policy could be ignored by
> the rest of the project.
> However, this does not in practice happen, and it is not only because
> the Release Team, FTP masters, BTS admin etc follow it, but it is
> because the project as a whole does so. It would be difficult, if not
> impossible, for a maintainer to decide to ignore policy because they
> disagreed with it, see decisions from the tech-ctte for example. Thus,
> what enters policy affects others work, and is a delegatable position.
>
> { It is interesting to note that the developers reference also does not
> have a delegation - perhaps it should! }
>
>
> So, in summary:
> * Delegations should be for particular decisions and/or areas of ongoing
> responsibility, without being explicit as to the process that the
> delegates are expected to follow.
> * The DPL can (usually) delegate decisions and areas of responsibilty
> that they do not have the power to take themselves, as long as this area
> of responsibility has not already been defined.
> * Debian policy editors are a delegatable position by the DPL, but only
> if the DPL wishes to delegate the power to *set* policy, rather than to
> simply document current practice.
> * The tech-ctte can override any delegate who is setting technical
> policy by simple majority.
>
> Neil
> { Sorry it took a while to get the summary out - it's been quite a bit
> of work! }
> ---------- end draft ----------
> --
signature.asc
Description: Digital signature
