Branden Robinson has written a small memo about the issues of using Delegation according to the Constitution of the Debian Project.
From the debian-devel-announce-list:
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.
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.
4. The DPL can make two types of delegations: a particular decision, or an
ongoing area of responsibility.
5. If the DPL delegates a particular decision, he or she cannot retake
responsibility for the decision personally, but can re-delegate it to
6. If the DPL delegates an ongoing area of responsibility, he or she can
withdraw that delegation.
7. The DPL can add or remove delegates at his or her discretion.
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
9. The DPL cannot override the decision of a delegate once the delegate has
10. The Developers can override the decision of a delegate via a General
Resolution with a simple majority.
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.
 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.
 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.