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. branden@debian.org | -- Stephen J. Carpenter http://people.debian.org/~branden/ |
Attachment:
pgpPSpHT1Oqak.pgp
Description: PGP signature