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

DPL platform

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:

My platform is available at:

                         Platform for Branden Robinson


   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

   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

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.


   Thank you for your attention. I welcome your feedback on my platform,
   and I strongly encourage you to vote in the forthcoming election.


   The Project Secretary has afforded the candidates and opportunity to
   rebut the platforms of the other candidates. My thoughts on each

     * 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.


   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

Reply to: