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 ---------- --
signature.asc
Description: Digital signature