Since Raphaël did posted his platform in text form here, I guess I'll follow suit.
Branden Robinson's Platform for Debian Project Leader -- 2002
_________________________________________________________________
Introduction and Biography
Greetings, fellow Debian developers.
The purpose of this message is to outline the reasons I am running for
Debian Project Leader (DPL), and to present an idea of some specific
things I would like to accomplish during my term, if elected.
First, a brief biographical introduction is in order. My name is
Branden Robinson; I have been a Debian Developer since approximately
January of 1998. My most prominent work in Debian has been as
maintainer of the XFree86 packages, which I have done since March of
1998. Since August of last year, I have also been the Treasurer of
Software in the Public Interest, Inc., Debian's legal parent
organization and manager of the Debian Project's assets. I am 27 years
old, employed as a free software developer, married, and have no
children.
Some of this platform may be familiar to you if you have read from my
DPL Platform from last year. This is because some of the issues I was
concerned about have not been addressed in ways that I'm completely
happy with.
I will also note that there are few specific courses of action in this
document to which I am wedded. The purpose of this document is to
identify my guiding principles and priorities, not to draw a roadmap
which I will follow in excruciating detail. Since I feel that a
diagnosis of problems is less valuable without proposed solutions, I'm
suggesting possible solutions. I look forward to interested people
stepping forward and participating in the process of solving these
problems. To me, leadership means listening, and then taking action on
an informed basis. If you feel that some of my proposals suffer from a
lack of information, I urge you to waste no time in bringing me up to
speed.
Unlike some, I firmly believe that Debian's democratic, constitutional
basis is a sound one. I do not believe it retards our growth or
viability as a software project. On the contrary, I think that by
distributing the lion's share of power among the Developers, rather
than vesting it in the Project Leader, the Debian Constitution ensures
our Project's long-term prosperity. It protects our Project's identity
and goals from being excessively over-identified with a single
individual. In the Debian Project, you shouldn't ever have to worry
about what happens if developer X "gets hit by a bus", or -- more
likely -- resigns (whether formally or by simply vanishing without a
trace).
That said, the role of Project Leader is still an important one. The
DPL must have an awareness of the challenges that face our Project
which are too large for any one Developer to surmount, and attempt to
allocate resources towards overcoming those challenges. At the same
time, the Project Leader must maintain Debian as an environment that
encourages experimentation, novel problem-solving, and reinforcement
and reward for the volunteer spirit that is the backbone of our
Project. Debian is an organization where one can simply leave if one
is unhappy, so a Project Leader must do more than simply give lip
service to consensus-building. The Debian Project does not have a
captive membership; poor leadership will lead to loss of people, loss
of vitality, and loss of relevance.
Major Issues
The following is a list of items that will be high on my priority
list.
I. THE DEBIAN PROJECT LEADER'S DELEGATES
The central -- and overriding -- issue to my mind about the role of
DPL is the process of delegation under the Constitution. I think this
is a great mechanism (potentially) that has been underutilized to
date.
First and foremost, I think we need more delegates from the Project
Leader. For the most part, Debian Developers have very narrow bounds
within which they can exercise their personal discretion. This is,
largely, the right way to do things. Since we are such a large body,
and since we invariably have such a large pool of varied opinions
about how any particular thing (technical or otherwise) should be
done, this helps to keep Debian harmonious. In other words, we may
argue, but there is a fairly clear perimeter within which any
individual developer can act with a legitimacy recognized by the rest
of the Project. This perimeter is pretty much confined to the details
of maintaining packages.
However, the larger issues of administration and coordination are
often neglected; sometimes because there is no one to do them, and/or
because no one has a clear mandate to act upon them.
This is where I think the Debian Project Leader is required to act;
indeed, I consider this to be perhaps the central duty of the DPL.
And, moreover, not to personally and directly act upon the problems of
the day, but to delegate responsibility for these duties. The days are
long gone when the Project Leader could fulfill many administrative
tasks himself; instead, the DPL must identify knowledgeable,
dedicated, and willing people already within the Project to handle the
jobs.
I am confident that we don't presently have enough delegates, since
there are many things that need to be managed that presently are not,
and which are not properly within the decision-making authority of any
individual developer as such.
I would like to see greater formalization of the delegate status. As a
first approximation, I believe there should be a webpage on the Debian
site that not only enumerates them, but describes each one's duties,
and stating the date each one began. Delegates should serve for a term
of one year, or until the next DPL begins his term. I would like to
think that in many cases, a delegate could continue to serve out his
or her year-long term even across a DPL transition, but I also believe
that delegates must derive their status from the sitting Debian
Project Leader, since this only makes sense. It does not make sense to
me for one DPL to be able to name a delegate, who then holds that
position until resignation. Very little of the above is formalized in
the Constitution. It either should be formalized in some official
document, or a set of sound traditions should be established.
Furthermore, I think that each delegate must be held to some standard
of responsibility. The delegate must fulfill the role to which he was
appointed, or be prepared to step down. The Constitution is clear that
a delegate can be dismissed by the DPL for anything except a
particular decision. It does not say say that the DPL cannot dismiss a
delegate if that delegate isn't making decisions at all. Of course, if
the Developers disagree, they can bring a General Resolution under the
Constitution to put a stop to it (or recall the DPL himself). As DPL,
I would publicly put delegates on notice that their inactivity is
causing problems before withdrawing their status.
At the very least, I believe the current DPL delegates of Project
Secretary, Release Manager, Debian Account Manager, and Debian System
Administrators should be completely formalized under this process. I
also believe that it should be made explicit that delegates have the
authority to sub-delegate, or nominate stand-ins for themselves to
handle any duties already delegated to them if they are personally
overwhelmed or otherwise busy.
I believe that all existing DPL delegates, and the majority of Debian
Developers, have the best of intentions, but are sometimes not good at
recognizing when they no longer have sufficient time to dedicate to
the tasks for which they have volunteered. Implementing policies and
mechanisms for correcting this deficiency -- in a way that minimizes
stress and conflict between developers -- is my top priority as DPL.
II. KEEPING THE DEVELOPER BASE ACTIVE
Anyone who's been a regular in the #debian-devel IRC channel over the
past few years will know that I've long complained that the Debian
membership needs to be "reaped"; that is, we need to identify
developers who are on our rolls but no longer really contributing.
This is important because the core of our work -- our packages -- can
end up in the hands of people who no longer have time for their Debian
responsibilities, and thus we end up with parts of our distribution
that are effectively unmaintained. This is even worse than having some
critical piece of software unpackaged (consider, theoretically, the
case if we didn't have a "bind" package), because by advertising the
presence of a package, we are implicitly telling our users that we
support it. Support means keeping it up-to-date, fixing bugs,
coordinating with other developers to make sure it fits into the rest
of the package structure in a clean and elegant way, and communicating
with the users of that package. When a package is left unmaintained,
none of these things happen. As we've seen over the past year, when
critical packages go unmaintained in this way, our release process
gets bogged down.
Not to be ignored is the fact that inactive Developers on the rolls
swamp our Constitution's Standard Resolution Procedure by artificially
inflating the value of Q, making it difficult for quorum to be met,
and action to be taken. This has the effect of falsely amplifying the
influence of people who prefer the status quo. Not being around to
even be aware of an issue under discussion is not the same thing as
preferring that a General Resolution not come to a vote. See our
[1]Constitution for more background on this problem.
I am sympathetic to all kinds of reasons a package maintainer may be
unable to contribute to the level required by the package, and the
expectations of reasonable users. However, we must nevertheless be
able to identify unmaintained packages and idle developers, and take
appropriate steps to recognize their status as such.
I propose that we experiment with, and ultimately apply, automated
tools for tracking package and developer activity, and act
accordingly. Idle developers should be moved into an "Emeritus" state,
lose their Developer status under the Constitution, and have their
packages distributed into the [2]WNPP system. There are already some
tools in existence to handle the identification of idle maintainers,
but I am less concerned with the specifics than with an effective
result.
Finally, I think implementing the above will go a long way towards
addressing the "stigma" of Non-Maintainer Uploads (NMUs.) Right now,
we have a great many packages in our archives that claim to have
maintainers, but in actual fact, they don't. The maintainer may be
otherwise active but neglecting a particular package, or the
maintainer may simply not be participating in the Debian Project
anymore. If we have ways of recognizing these facts, I think the
fundamentals of our NMU procedures can remain unchanged.
III. DEBIAN'S REPRESENTATION AT FUNCTIONS
(By "functions" I mean any gathering -- typically, but not always, a
"real-world" event like a trade show -- at which it would be
worthwhile for Debian to have a recognizable presence.)
This is one area where we've made some progress since last year;
however, problems struck again anyway at LinuxWorld in New York and at
the Annual Linux Showcase.
Therefore, unless there is strong opposition, one of the first things
I would like to do if elected Debian Project Leader would be to
delegate, on a regional basis, Event Coordinators for Debian. These
people would be responsible for keeping track of trade shows, major
Linux User Group events, etc., at which Debian should have a presence.
For each specific event, they would either handle contact with the
coordinating entity directly, or delegate a person (preferably one who
will be in attendance) to do so.
One role that Event Coordinators can fill is that of handling
complaints about exhibition controllers. USENIX was quite militant and
almost extortionate in the way it treated non-profit booths at the
Annual Linux Showcase last year. Even when we run our booth admirably,
efforts by exhibition administration or sponsors to restrict access by
non-profit groups -- especially with insidious methods like banning
"outside" equipment and charging $130 for a table -- put a huge damper
on Debian's ability to make itself visible to new users. Cash
donations at booths also must not be ignored when considering Debian's
revenue streams. Debian is funded entirely by donations; if
exhibitions keep us off the show floor, they strangle us financially.
As Debian Project Leader, I am willing to attend conferences and
expositions, make presentations and speeches, and otherwise be a
representative of the Project. I have public speaking experience and
am happy to speak before an audience of any size.
IV. DEBIAN'S RELATIONSHIP WITH SPI
Here is another issue where substantial progress has been made since
last year. However, in my opinion, this progress has been
insufficient. SPI is in much better shape than it was one year ago,
but there is still much to be done.
As Debian Project Leader, it is my intention to recruit volunteers on
behalf of SPI and attempt to grow the organization.
As SPI Treasurer I am aware that there is a risk of a perceived
conflict of interest if I am also elected DPL. I will do whatever is
necessary to ensure that any such perception is unfounded and
refutable. I think the appointment of a "shadow treasurer" who also
receives all mail sent to the SPI Treasurer and to whom I CC all
correspondence as SPI Treasurer (as it happens, I already CC the
entire SPI board on such correspondence when functioning as SPI
Treasurer) would help to achieve this.
I am prepared to resign one of these two offices if the general
consensus is that it is completely impossible for me function in both
of these roles without jeopardizing either organization. However, I am
confident that this is a problem that can be solved through
accountability and visibility. It is my intent to resign as SPI
Treasurer as soon as there are procedures in place to enable future
Treasurers to do their jobs efficiently, rather than having to inherit
headaches from previous Treasurers who may have neglected their
duties.
V. REACTIVATION OF THE DEBIAN TECHNICAL COMMITTEE
The Technical Committee appears to have stagnated. There have been
issues placed before the Committee and the Committee has failed to
hold votes or otherwise reach conclusions on them. (Here is [3]one
example, and here is [4]another).
This is a serious problem because the Debian Constitution vests a
great deal of authority in the Technical Committee. This body must be
active and functioning. As DPL, I will exercise all powers available
to me to ensure that the Technical Committee is able to execute its
functions in a manner that is both timely and consistent with our
Constitution.
VI. THE RELEASE CYCLE
This is a question that is practically inescapable. What can we do to
get Debian GNU/Linux to release more frequently? Hundreds of kilobytes
of armchair analysis and thought have been given to the issue on our
various mailing lists. I'll be frank and say that I don't know that I
have a definitive answer. Changing our policy on point releases of the
stable distribution to include more than just security fixes and
corrections for completely broken packages sounds like one part of a
larger solution. As DPL, I'd like to invite Release Managers past and
present, and other interested parties, to help a structure a new
approach to release management.
One thing I won't -- and don't want to -- do is yank the rug out from
under the current Release Manager. Yes, the woody freeze has been
taking a long time. However, it would, in my opinion, be folly to
derail the process now, no matter how much some people are frustrated
with it. Anthony Towns, the current Release Manager, needs your
support. I'm very interested in hearing proposals for what we can do
post-woody to make the release process less susceptible to friction,
but right now the best thing anyone can do is to test fresh woody
installs, test upgrades from potato, and find and fix release-critical
bugs. If we hadn't made substantial progress on releasing I might feel
differently, but we have. Anyone who feels that we haven't needs to
review the [5]facts.
Lesser Issues
The following are issues that I consider of secondary importance to
the ones listed above. Nevertheless, they are ideas I have and I
thought I would take this opportunity to enumerate them.
VII. APPOINTMENT OF A DEBIAN LEGAL TEAM
Just as Debian has a Technical Committee, I'd like to see a body of
legally-minded people formed who are empowered to render official
decisions regarding the interpretation and application of the Debian
Free Software Guidelines. As with the Technical Committee, of course,
their decisions could be overridden by a General Resolution of the
developers. The point is to get a formal structure in place for
handing issues like this that don't require General Resolutions in and
of themselves. GRs are a very weighty process, and where decisions of
this nature can be made, it is good to have a mechanism for making
them.
VIII. REVISION OF THE DEBIAN MACHINE USAGE POLICY
When I first read the [6]DMUP I felt it was a poor fit in places for
Debian. I was told that many of its terms were lifted verbatim from an
ISP's Acceptable Use Policy (AUP). As DPL, I'd like to appoint a team,
including at least one representative from the Debian System
Administrators, to draft a new one that better reflects the nature of
the Debian Developer as a creator of content, not just a consumer of
bandwidth and other resources. I believe it is possible to keep the
donors of our Project's bandwidth and rackspace happy without
addressing our Developers as if they are hooligans. In my opinion, the
current DMUP veers a little too far to the latter, and is worded in an
overbroad manner in some places.
IX. THE DEBIAN PROJECT'S VOICE IN THE LARGER POLITICAL SCENE
Debian is a heterogeneous project; as such it affords a wide spectrum
of political and philosophical beliefs among its membership.
However, there are a few cases, especially with respect to
intellectual property law, where a general consensus of opinion among
Debian developers can be expected. Debian's profile is growing, both
within the Linux community (as we continue to survive and thrive even
as some other distributions reduce their scope or vanish altogether),
and outside it, as the phenomena of Linux, GNU, and Free Software (or
Open Source) appear with increasing frequency in international media.
I think it would be a shame if Debian did not make an effort to lend
its weight, however great or small, to specific political issues where
it is important to do so. For instance, I imagine that Debian
developers would be fairly united behind repeal of export controls on
cryptography in the United States, and to support and reinforce recent
initiatives in Europe to adopt Free Software at the governmental level
as an act of public policy.
As DPL, I would like to take steps to get Debian's voice heard in the
halls of government if and where appropriate, so that our ideals --
and our means of achieving them -- are not legislated out of existence
by governments hostile to them (or, more likely, governments that have
sold sections of their lawbooks to large corporations comfortable with
past models of intellectual property and its distribution).
X. MIGRATION AWAY FROM NON-FREE SOFTWARE SERVING OFFICIAL PROJECT FUNCTIONS
A quick review of our [7]Social Contract reminds us that our
priorities are our users and Free Software. In my opinion, we do the
latter a little bit of a disservice by continuing to run the
non-DFSG-free program qmail on the machine that hosts our mailing
lists.
Our mailing lists are the lifeblood of our Project, and I think it's a
shame that we might be slighting various fine -- and DFSG-free -- Mail
Transport Agents (MTAs) through omission.
In my tenure as DPL, I'd like to do whatever is feasible to transition
official Project infrastructure away from non-DFSG-free software. A
question in the business world that I've heard from time to time is:
"Do we eat our own dog food?" -- meaning, of course, do we trust our
own operations to the tools that we claim are sufficient for use by
the rest of the world? I think the answer is: yes, we can -- but in
some places, we don't. Not because we doubt the quality of the Free
Software we devote our labor to, but because at some point in the
past, the best way we could serve the needs of our users was to place
our trust in a non-free tool. For our mailing list server, I believe
that time has passed. Transitioning our list server is no small job,
and doing so without disrupting our development process is a serious
business. As DPL, I'd like to recruit volunteers to handle this task
and prepare a schedule for executing a transition.
As a Debian developer, I'm proud of the work that we do, and I see no
reason not to trumpet the virtues of Free Software -- including its
quality -- not just from the rooftops, but from our Received: headers
as well.
Conclusion
Thank you for your attention, and I hope this message has not been
overlong. I welcome your feedback on my platform, and I strongly
encourage you to vote in the forthcoming election.
_________________________________________________________________
[8]Valid HTML 4.0! [9]Validate this page's HTML.
References
1. http://www.debian.org/devel/constitution
2. http://bugs.debian.org/wnpp
3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107150&repeatmerged=yes
4. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517&repeatmerged=yes
5. http://master.debian.org/~wakkerma/bugs/
6. http://www.debian.org/devel/dmup
7. http://www.debian.org/social_contract
8. http://validator.w3.org/
9.
http://validator.w3.org/check?uri=http://people.debian.org/~branden/platform.html
--
G. Branden Robinson | It doesn't matter what you are
Debian GNU/Linux | doing, emacs is always overkill.
[EMAIL PROTECTED] | -- Stephen J. Carpenter
http://people.debian.org/~branden/ |
pgpZNs0fqyObO.pgp
Description: PGP signature
