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

How Delegation Works, in 10 Easy Steps



The Constitution of the Debian Project specifies a decision making process
known as "delegation", which the Debian Project Leader can use to spread
decision-making authority throughout the Project.  Historically, this power has
been underused (including by myself), particularly in areas of infrastructural
administration.  This turns out *not* be due to past (or present) Project
Leaders' lack of motivation or desire to do so.

I have learned that part of the problem with delegation is that the
Constitution's concept of it is poorly understood by some of our developers,
particularly those who are not native English speakers and for whom the dry
legal language in the document is heavy going.

Here, then, is my attempt to put delegation in a nutshell:

 1. Any authority not otherwise assigned by the Constitution (e.g., to the
    individual Developer, Technical Committee or the Secretary) can be
    exercised by the Project Leader, either directly or through delegates.
    (§5.1.1, §5.1.2, §5.1.3, §5.1.4)
 2. In the case of "approving or expelling Developers or designating people as
    Developers who do not maintain packages", this authority *must* be
    exercised by a delegate, and not by the Project Leader directly.
    (§8.1.2)
 3. The Constitution suggests that there may be other powers which the DPL may
    not directly wield, and which he or she must delegate instead, but apart
    from the above, none are enumerated in the Constitution.
    (§8.1.2)
 4. The DPL can make two types of delegations: a particular decision, or an
    ongoing area of responsibility.
    (§5.1.1)
 5. If the DPL delegates a particular decision, he or she cannot retake
    responsibility for the decision personally, but can re-delegate it to
    someone else.[1]
    (§5.1.1, §8.2)
 6. If the DPL delegates an ongoing area of responsibility, he or she can
    withdraw that delegation.
    (§5.1.1)
 7. The DPL can add or remove delegates at his or her discretion.
    (§8.2)
 8. The DPL cannot make someone's status as a delegate dependent on the outcome
    of a particular decision that they make within their authority as a
    delegate.  That is, the DPL cannot say, e.g., "If you drop non-free from
    ftp-master.d.o, you no longer get to be a package archive
    administrator."[2]
    (§8.2)
 9. The DPL cannot override the decision of a delegate once the delegate has
    made it.
    (§8.2)
10. The Developers can override the decision of a delegate via a General
    Resolution with a simple majority.
    (§4.1.3)

Let me know if you feel this is an accurate characterization of the
Constitution; I've done my best, but I'm not infallible.  Also, I'd like to
hear your thoughts on whether you think delegation is a tool that I should use
more.  I appreciate your comments.

[1] One might argue that the prohibition on rescinding delegation of a
particular decision is tied the individual(s) to whom it is given, rather than
the decision in question.  This is important if the person or people to whom
the decision is delegated prove unable to make it.  This is another variant on
the old "what if Linus (Torvalds) gets hit by a bus?" problem.  One developer
has told me that my interpretation poses a different threat, however: "It looks
like you're going to decide this one issue in a way I don't like, so I'll take
it away and give the decision to someone who will decide it the way I want to."
Why a Leader would do this, or how he or she could expect to get away with it,
is not clear to me, but this scenario is not impossible.  If this ever proves
to be a non-hypothetical problem, I would ask for the Project Secretary's
interpretation of the Constitution.

[2] In practice this is hard to enforce perfectly, especially if the DPL keeps
his or her reasons for dismissing a delegate to him- or herself.  Personally, I
interpret this to mean that if the DPL attempts to sway or threaten a delegate
with the loss of their position if he or she does not do the DPL's bidding on a
particular issue, that the delegate should bring the DPL's misconduct to the
attention of the developers.

-- 
G. Branden Robinson
Debian Project Leader
leader@debian.org
http://people.debian.org/~branden/

Attachment: signature.asc
Description: Digital signature


Reply to: