On Mon, Jan 06, 2014 at 07:39:55PM +0000, Neil McGovern wrote:
> On Mon, Jan 06, 2014 at 03:38:46PM +0100, Lucas Nussbaum wrote:
> > Doing that now. :-) Also, I'm more worried with the interactions with
> > Constitution 6.1.1. It seems to me that a Policy Editors delegation
> > should have come from the TC, not the DPL.
> > Dear Secretary, what do you think?
> >
>
> Thanks for doing it officially :) Me and Kurt are looking at it now.
> There's two conflated issues, but we hope to get a full view out in a
> day or two.
>
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!
Neil
---------- 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 ----------
--
Attachment:
signature.asc
Description: Digital signature