Since Martin and Bdale have posted their platforms to this list, I guess
I should do likewise, though I do wonder if there's anyone who reads
this list who hasn't already seen all of the platforms.
The voting information page for this election is at:
http://www.debian.org/vote/2003/vote_0001
My platform is available at:
http://www.debian.org/vote/2003/platforms/branden
Platform for Branden Robinson
Introduction
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 2001, 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 in the United States. Late last
year I joined Debian's team of Policy Manual editors. I am a fixture
on the debian-legal mailing list, and participate with other
developers in the vetting and analysis of the terms and application of
various software licenses, and how they mesh with the Debian Free
Software Guidelines (DFSG). Of course, I'm often found on other Debian
mailing lists as well. I am 28 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 either
of my DPL Platforms from the past two years. Since I have run twice
before, unsuccessfully, this year I questioned the utility of running
again, and wondered whether my perceptions of where this Project's
problems and opportunities lie were widely shared. Rather than
attempting to guess at the answer, or engaging with people in informal
conversation in effort to gauge the degree of common ground, I decided
earlier this month to circulate a questionnaire among Debian
Developers via the debian-vote mailing list. This, I felt, would give
me some more concrete, if not strictly scientific, data to work with.
The experiment paid off. I received 73 replies, of which about 60 were
from Debian Developers (the remainder were from Debian users, most of
whom are in the New Maintainer queue).
While I have done no rigorous quantitative analysis of the
questionnaire results, I actively solicited free-form commentary
within the questionnaire, and most respondents were apparently happy
to oblige, and were very free with their opinions. Moreover, there
were some recurring themes in the replies -- themes which include
points of concern that I share. Therefore, I have concluded that there
is a significant number of Debian Developers who would like to see the
next Project Leader attempt to tackle some specific issues.
Consequently, I am standing as a candidate again this year, and I
pledge to do what I can to address those concerns.
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. A Project Leader will need to be flexible enough to cope with
problems and opportunities as they arise, and as he or she learns more
about them. A Project Leader needs strategies, but not necessarily a
generic recipe that is applied to all issues. 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.
Some of the respondents to my survey are a bit disenchanted with
Debian's constitutional system of governance. I still feel as I did
last year: Debian's democratic, constitutional foundation is a sound
one. Our Constitution is, however, not directly applicable to how
everyday decisions get made in the Project. Neither is it, I feel, an
instrument of last resort. Instead, it is a tool that is well-suited
to solving certain kinds of problems, and making certain kinds of
decisions. It is less well-suited to others. In my opinion, the
Constitution is good for three things: distributing power and
responsibility within the Project, resolving important issues that are
contentious, and soliciting the input of every Developer where
appropriate (as in Project Leader elections).
The role of Project Leader is an important one. The DPL is the
Project's primary representative and spokesman, both internally and
externally. 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 strive to maintain an
environment that encourages experimentation, novel problem-solving,
and reinforcement and reward for the volunteer spirit that is the
backbone of our Project. Finally, the Project Leader must be able to
present Debian's "best face" to the press and other people and
organizations.
Delegation and Accountability
The central -- and overriding -- issue to my mind about the role of
DPL is the process of delegation under the Constitution. I feel as I
did last year -- delegation is potentially a great mechanism, whose
potential has not yet been realized as I think it could be.
First and foremost, I think we need more visible delegates from the
Project Leader. For the most part, Debian Developers have very narrow
bounds within which they can exercise their personal discretion.
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, or because there
is a single point of a failure, and only one person is doing a
particular task.
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. The
DPL need not necessarily assume personal and direct responsibility for
the problems of the day, but rather he or she should delegate
responsibility for these duties, and set clear and reasonable
expectations for their fulfillment. 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. The DPL must
also follow up with the delegates, and ensure that they understand
their responsibilities; not just so that they know what is required of
them, but so that they know what is not required of them. Because this
is a volunteer project, it makes no sense to heap more upon a delegate
than can reasonably be borne. It is primarily the Project Leader's
responsibility to recognize the situation and act when a delegate is
overwhelmed. Any task that can benefit from parallelization and a team
approach should receive one, as long as qualified delegates can be
found to do the job.
My perception, and that of many of the respondents to my
questionnaire, is that we don't presently have enough delegates, and
we particularly don't have enough in some key areas of infrastructure.
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 specifically dedicated to DPL delegates: it should enumerate
them, describe each one's responsibilities, state the date each one's
term began, and provide a link to each delegate (or team's) webpage
where they can post news and status information, where applicable.
Delegates should be directly involved in establishing their own
standards and responsibilities; this is not only more fair to
volunteers, but this should also serve to get the DPL and the delegate
off to a good start in having open channels of communication. The best
goals are those we are free to set for ourselves. While the DPL cannot
single-handedly ensure that everyone's goals are met, he or she can at
least develop a strong knowledge of the Project's strong and weak
points in the delegation structure, and solicit volunteers to
reinforce the weak points.
Other Issues
There are some other things I'd like to accomplish during my term as
DPL, but they all take a back seat to the above.
* Refereeing internal disputes: if delegation and accountability is
the DPL's primary focus, then this surely is the top-ranked task
in the second tier. A great many survey respondents felt that the
DPL must highly prioritize efforts to resolve disputes internal to
the Project. While I largely agree, I do not feel that this should
be priority number one, at least if the DPL is expected to be a
sort of diplomat. No one (at least, not anyone who's actually
getting any work done) has the time to try and quench every
flamewar. I do think, however, that when an internal dispute rages
for a long time and/or substantially impedes productive work
within the Project, the DPL should strongly consider stepping in.
If the DPL has a novel perspective or path to resolution to offer,
he may consider presenting it. For the most part, however, I think
that important internal disputes will in most cases devolve to
delegation and accountability issues (see above); where they
don't, the best thing for a debate that seemingly won't stop is
probably a General Resolution.
* Attending trade shows and doing press interviews: these tasks are
important for maintaining Debian's visibility to the "outside
world". They are important, but they are also highly delegable. As
DPL, I will not feel a strong compunction to attend as many trade
shows as possible, or handle every press contact myself. While I
will want to attend the most important trade shows that are within
my financial means, I am happy to delegate the honor in cases
where I cannot. Bdale Garbee, for instance, is an engaging and
effective spokesman, and he is an example of a person to whom I
could delegate the mantle of "Debian representation" with complete
confidence. In many cases, though, Debian is best represented
simply by the number of dedicated, energetic, and friendly
developers we muster. When it comes to press or other external
contacts, I imagine that in many cases, the DPL is the person whom
people contact simply because they don't know of anyone else. When
I'm not the best person to whom to address an inquiry, I am more
than happy to forward it along to more appropriate personnel.
* Establishment of a "developer emeritus" status for inactive
developers is very widely regarded as a good idea; the only real
hurdle appears to be simply finding someone for the task of
implementing the technology and working with the Debian Account
Management (DAM) team to ensure that it's used. As DPL, I'll
definitely want to look into this.
* Finally, I would be interested, if response is positive and if the
Project Secretary is amenable to the idea, of using our voting
machinery to periodically circulate surveys about issues of the
day. These would not, of course, by anywhere near as comprehensive
as the questionnaire I posted earlier this month; I am thinking
instead of possibly circulating a survey listing several options
about the possible disposition of the non-free section of the
archive (since it is one of those flamewars that flares up
occasionally with great violence, never truly dying). By using the
Condorcet method, we can learn without a binding vote how the
Developers really feel about the issue, and this data might be
very useful in deciding whether to try and move forward on some
sort of General Resolution, and if so, what sort of ballot options
appeal to people.
Conclusion
Thank you for your attention. I welcome your feedback on my platform,
and I strongly encourage you to vote in the forthcoming election.
Rebuttal
The Project Secretary has afforded the candidates and opportunity to
rebut the platforms of the other candidates. My thoughts on each
follow.
* I disagree with Moshe Zadka's philosophy of leadership ("I promise
to do as little as possible"), at least when there are known,
significant problems within the organization being governed. It is
perhaps easy to mock Mr. Zadka's approach, but anyone who does so
is probably ignorant one important aspect of leadership: knowing
when to keep one's hands off. A leader who tries to do it all
himself will likely succeed at accomplishing nothing, or making
things worse. That's why I have placed so much emphasis on
delegation. As DPL, I will be conscious of the need to empower
others, ensure the presence of good communication channels between
delegates and the Project, and do my best to let both succeed.
With regard to Mr. Zadka's specific campaign planks, I cannot say
that I perceive much in the way of problems that need solving: I
do not think there has been a problem with SPI misusing Debian
funds; I am not cognizant of a movement within Debian to make it
an explicitly political organization; I do not perceive much
remaining of the past hostility between the Freenode and OFTC IRC
networks; and I am not aware of any efforts to undermine English
as the lingua franca of the Debian Project, nor any efforts to
freeze out translation efforts to other languages. It is possible
that Mr. Zadka shares these impressions to some degree, which may
explain why he feels a passive DPL is a good idea. My diagnosis of
the Project's ills, however, is different.
* I find Martin Michlmayr's platform more difficult to critique
because it reminds me a lot of my own from last year. I think Mr.
Michlmayr has many good ideas but, as he recognizes, many of them
can be done without the benefit of the DPL's mantle of power. Mr.
Michlmayr places too little emphasis, I think on systematizing and
structuring the delegation process; he recognizes that the main
aim of the DPL should be to "lead, motivate, and coordinate", but
he does not present concrete proposals for fulfilling that
mission, as I have. If elected, I would hope that Mr. Michlmayr
would be interested in a delegate's position to tackle one or more
of the problems he has identified.
* Finally, we have the incumbent's platform, that of Bdale Garbee. I
am not certain that Bdale even needs a platform, given that we
advantage of his past year of service to reflect upon. Bdale has
been, by all accounts, an outstanding spokesman for the Project to
the outside world, a dedicated participant in the IA-64 porting
effort, and a solid package maintainer. However, I -- and many of
the respondents to my questionnaire -- am not certain that Bdale's
tenure as leader has turned out as he projected in the [9]platform
upon which he was elected. This is not to say that Bdale's
accomplishments haven't been worthy of credit and recognition --
far from it. It is my feeling, however, that the Project could do
with more shoring up from the inside, to ensure that we operate
more smoothly (one might say that this is my personal take on
Bdale's concept of facilitation). In his 2002 platform, Bdale
spoke of several issues: values, vision, quality, release
predictability, user first impression, (technological)
infrastructure, security, and the Linux Standards Base. All of
these are indeed important, but we've seen little direct followup
on most of these issues by Bdale himself. We did in fact release
Debian 3.0 ("woody") during Bdale's term, but that release was
pretty far along when he took office, and more to the point, we
don't seem to me tumbling headlong towards another release at
present, which doesn't do very much for the plank of "release
predictability". I think the Release Manager has most of the
responsibility for making releases, and any credit or blame to be
assigned lies first and foremost with that position, and
secondarily with the Developers as a whole -- I think it is
difficult for a leader to command a release to happen. The
security team has been doing a bang-up job, but I gather they
managed this largely under their own power, as the term does not
appear in Bdale's 2003 platform. Quality, user first impression,
and the Linux Standards Base are all other items from Bdale's 2002
platform that have received little followup in his platform for
re-election. Of course it is not necessary for Bdale to
recapitulate, point by point, his platform from 2002 when running
for re-election, but when I checked for a "bits from the DPL"
message to find other follow-up data on the points, the most
recent one I could find was from 17 September. Perhaps all this
means is that Bdale was too ambitious in his earlier platform; we
could certainly do worse than to have Bdale as a Project Leader.
Still, there are some internal problems that existed in April 2002
that have gone largely unresolved in the past year -- if you share
my thoughts about what they are, you may feel that I'm a better
candidate this year. Bdale has drawn his focus more narrowly for
this year's platform, and that's a good thing: his major planks
are release flavors, internationalization, and the Project's
communication with its userbase. These are all noble goals, but
I'm not sure one needs to be Project Leader to make headway on
them. Bdale appears to have a talent for the latter in particular,
and I applaud him for that. I'd be delighted if he'd share his
thoughts with me on how to further each of these goals if I am
elected this year.
I am not going to conclude with a rhetorical prophesy of doom or
irrelevance for the Project if any other candidate is elected, since I
don't feel that's the case. I am also not going to imply that no one
else is capable of providing "clear and effective leadership", to
quote a platform from years past. I will instead rest on my analysis
of Debian's strengths and weaknesses, my stated priorities, my record,
and my experience. I urge each voter to take these factors into
account for all candidates, consider carefully, and make the best
possible decision you can make. It is my hope that if you share my
perspective and goals, that I have inspired your confidence, and that
you feel the Debian Project would be better served with me as your
representative for the next year.
Thanks again for your attention, and for your part in making the
Debian Project such an exciting place to be.
______________________________________________________________________
References
9. http://www.debian.org/vote/2002/platforms/bdale
--
G. Branden Robinson | We either learn from history or,
Debian GNU/Linux | uh, well, something bad will
branden@debian.org | happen.
http://people.debian.org/~branden/ | -- Bob Church
Attachment:
pgpehOewQ_TlI.pgp
Description: PGP signature