Steve McIntyre's DPL platform

Introduction

I've been a Debian Developer since October 1996. I originally joined to maintain the Debian version of mikmod; I was the upstream developer at the time, and wanted the Debian version to work well too. In those days, the NM process was rather simpler than today: I installed Debian, then two days later I mailed Bruce Perens with a PGP key and asked him for a Debian login. He responded almost immediately with account details - I was in!

Since that point, I've worked on quite a wide range of packages, some large and some small. Probably the most noticeable work I've done for Debian is within the debian-cd team, both developing the debian-cd software itself and using that same software to create the official CDs (and now DVDs) that accompany each Debian release. I've been involved with the CDs for almost every major and point release since Hamm.

Goals

Most of the things I'd like to see changed/improved in Debian are well known problems - they are issues that have affected us for a long time. I've separated them into two areas here: social issues and professionalism, even if there is quite a broad overlap in some of the cases.

Social issues

Communications within the project

This is a long-term bugbear; DPL candidates have been promising to work on improving communication within the project for as long as I can remember. There are several places where communication has been problematic in the past. Sometimes DPL effort has helped to fix things, but more often there has been no visible improvement.

Simple, regular status updates from the various teams within the project can help a great deal here. Equally, regular reports from the DPL are needed to make sure that the Debian community are aware of what is being said and done on their behalf. Even if some of these reports consist purely of "Sorry, I've been busy in real life and not accomplished much", simple confirmation that posts are not sitting unattended is better than nothing. I aim to encourage these updates, and if elected I will commit to distributing regular news from the DPL.

Mailing lists and IRC

Recent events suggest that we should learn a lesson from Ubuntu with their code of conduct. Free Speech is an ideal that many of us within Debian hold dear, but the negative, abusive language that often appears on the development mailing lists and IRC channels is not productive. Because of this, many people within and outside the project are becoming leery of contributing to our technical discussions. This hurts us both directly and indirectly: public perception of the project can suffer when our external contacts are unfriendly.

We need to agree a Debian code of conduct and then also to abide by it. We already have the beginnings of such a document, and I'd like to help develop it and encourage other developers to adopt it.

Training and NM

Currently the NM process contains detailed tests of an applicant's technical abilities, and of course this is a good and useful thing to do. Unfortunately, we don't select for social skills; we need to work together as a community!

NMs are often asked to show their skills by constructing a new package and/or taking over an orphaned package. This can be good for testing packaging skills, but can lead to NMs working on packages in which they have no real interest - further down the line these are most likely to be the packages that are abandoned.

I'd like to suggest that more NM training can/should happen more within teams. We have a large number of packages where the maintainers could do with help, and a large number of NMs looking for jobs to do. I believe this is a great place where we can improve. We need some sympathetic maintainers to make this work - they will be responsible for the work done, and then will be expected to report to the relevant AMs. I have already volunteered some of my own packages towards this effort, and I'd like to encourage other DDs to do the same.

Openness within the project

We promise to be as open as possible, but we often fail on this front. Sometimes this is necessary (e.g. when discussing embargoed security updates), but much of the time it is not. Sometimes discussions are private when they do not need to be, and this is not good for us. Sometimes technical work is done within our various teams and when this work is presented to a wider audience "cabal" accusations are made.

Unfortunately, there is no magic way to improve this situation. I believe a major blocker here is the aggressive attitudes that are often shown in our development forums, and these need to be curtailed first. Once we have a healthier atmosphere for discussion, then more open discussion will happen naturally.

Professionalism

Technical standards

In our large repository of software, we have a very large number of packages and a very large number of maintainers. Most of the work in Debian is done very well, but unfortunately not all of it. Much has been said in the past about our developers being volunteers who cannot be forced to do work that they don't want to. That may excuse people working slowly on their packages, but it does not excuse some of the sloppiness that happens from time to time, for example packages that fail to build on a clean system.

We have a growing number of tools that a maintainer can use to check the quality of their packages (linda, lintian and now piuparts). We have build tools that can reduce the chance of broken dependencies and other build-time issues (sbuild, pbuilder, etc.). Yet we still regularly have broken or low-quality packages uploaded.

There are two issues here, as far as I can see. Some of our maintainers are not aware of updates that have happened to our tools and procedures. Some of us don't feel the need to use those newer tools and methods. Both these issues should be fixable: more documentation on best-practice packaging and testing methods will help, both in describing what's available and why they're good.

Working effectively; asking for help

Continuing on from the previous point: another part of the DD's job is to work effectively, both on our individual packages and within the project as a whole. This includes simple things like handling the bugs in our packages in a timely fashion, but also includes bigger things, such as considering the impact of changes on the release schedule. Working effectively is not just important for our own gratification; it also makes a major impact on how long we take to release and the experience our users have with using Debian.

In my opinion, a key part of working effectively is honesty. We can all suffer from a lack of time to do the jobs that we've promised to do. After all, real life has a nasty habit of intruding on our so-called "spare" time. So long as we don't let things delay too far, we can cope and still contribute. But at some point, we need to be more honest with ourselves and actually admit that we can't continue with the jobs that we've promised to do. It's a hard thing to do, but in a friendly community where we're all working together towards a common goal there should be no shame in asking for help.

In a larger scope, procedures exist for DDs to temporarily leave the project if real life has overtaken them, and re-join when the situation changes. Again, there is no shame in doing this - we should be happy to acknowledge all the contributions that people have made to Free Software when they could. But, still, many people don't take this route and instead simply become missing in action (MIA). It can take quite a while to pick up on DDs who have simply dropped out of the project. I have heard several suggestions on how we can detect them more quickly and more easily, and I wish to support this.

Why vote for me?

We have a large field of candidates this year, which may make it difficult for our developers to decide how to vote. I believe I can do a good job as DPL due to the following qualities:

Summary

I have touched on some issues here that are hopefully not surprising to most of our community. I must also acknowledge the fact that the DPL does not have the power to simply impose changes as he/she sees fit. The best that the DPL can do here is to encourage us to improve, sometimes by discussion and debate and sometimes by leading by example. I don't claim to be perfect, but I believe I can help us to achieve some of the social and professional goals I have listed here. My own priority would be to fix some of the social issues first, as these are most pressing and in my opinion the most likely to cause long-term damage to the project.

Thanks for your time in reading my platform.

Rebuttals

Up front, I should say that I believe this year we have a selection of good candidates. Many of the issues that have been highlighted in the platforms have been raised by several of the candidates, and there are quite a few common solutions proposed. This makes a rebuttal really quite hard to write, short of saying things like "Jeroen smells bad"! *grin*

Nonetheless, I should put some effort in here. I'd like to be DPL (obviously, otherwise I wouldn't be standing!) but I'd also be happy enough to see any competent person elected. In more detail, my thoughts on the other candidates and their platforms:

Andreas Schuldei

Andreas has proved he is capable of co-ordinating large projects well - look at the succession of Debconfs he has been worked on over the last few years. In terms of his platform, I think his focus is on making Debian more effective by promoting the use of small teams for tasks. In many cases, I think that works well. But it's not immediately clear that they always work well; specifically, the DPL team from last year may have got tasks done, but there was very little visible to the rest of the project.

Anthony Towns

AJ is well-known to all of us; he's been a release manager, an ftpmaster and a debbugs guru in his lengthy and productive history as a Debian developer. He has plenty of experience to prove his commitment to the project. His goals this year of vitality, recruiting and direction all sound fair enough to me. I wish him well; the last year has shown that he has continued to work towards his goals despite not being elected, and I admire that.

Ari Pollak

I think that Ari is selling himself short when he describes himself as a "half-joke candidate". I actually laughed out loud when I first read his platform, which caused a few raised eyebrows at work... :-)

Bill Allombert

Bill was a very late entrant to the DPL race. His goals have a fair degree of overlap with others. I've not had much experience of working with Bill, but his work on the menu and popcon packages suggests Bill is capable. I'm worried that he may not have had much experience of working in/with core teams.

Jeroen van Wolffelaar

Jeroen hasn't been in Debian very long, but has had a profound influence already. As I understand it, he started Team Scud, the DPL team that supported two candidates last year and again two candidates this year. Jeroen has also worked as a member of the ftpmaster team, and has been a great help to me personally in terms of providing resources for the CD team. I still have some minor reservations myself about the DPL team, both in idea and implementation, but despite that I'd happily support Jeroen as a DPL. He's competent and a pleasure to work with, and our goals have a large amount of overlap.

Jonathan (Ted) Walther

I make no apologies for discounting Mr Walther as a serious candidate in the DPL race. We have a tradition of attracting joke candidates from year to year, but I see no humour in this candidate's platform. During the election last year I described him as a kook, and I see no reason to change my appraisal of him.