Introduction

I'm running again this year, so if you wonder who I am, please read my platform of last year, my situation hasn't changed except I'm one year older :-)

While you're at it, you can also check out the platform that I wrote in 2002. As you can see, many of the ideas I had in 2002 were implemented, and are now considered important parts of Debian. But there are still many things to do.

A DPL team, yes... but

Last year I proposed a relatively large DPL board. I think it was a mistake to try to have a board representative of Debian's diversity. That's why the DPL team that I'm proposing this year is much smaller (3 persons only). It's thus far easier to coordinate and to get a consensus within the team: we willl spend our time on getting work done, not on organizing ourselves.

Hopefully, with three like-minded (yet still open-minded!) people sharing common goals, we can tackle more projects as well. Shall I get elected, I would work with Moritz Muehlenhoff <[email protected]> and Lucas Nussbaum <[email protected]>. Moritz is 28 years old, german, and works as a software developer. Lucas is 26, french, doing a PhD and teaching. I've already met both of them and I know that it will be a pleasure to work with them.

Our project for Debian

(I'll continue using the first person for clarity but Moritz and Lucas also share this project)

We're all here to make Debian the best universal operating system. In my opinion the role of the DPL is to help the other developers by using his/her leverage to solve the frustrating problems that are too difficult to solve as a normal developer: problems that include social aspects, or that require coordinating many people.

Please find below some projects on which I want to work if I am elected. The DPL status will help for several of them: he's the best spokeperson when the project wants to push a message to the larger free software community (see "Recruit more contributors" below), his constitutional powers will help to redynamize core teams, and he can use Debian's money to organize work meetings to complete some of the projects that he finds essential for the future.

More visibility for our work

We need to actively generate more attention to all the great things we're doing. We can learn from Ubuntu here.

We need to push more announcements through [email protected], and I'll take care to draft some of them myself. Not only factual announcements of what we did, but also reminders of who we are, what we're about and what we want. The marketing team ([email protected]) must take off and become a core team to which any contributor can submit ideas of news and announcements. As Debian developers are not very good at that, we probably will have to recruit new volunteers who actually enjoy doing this instead of coding!

Our website needs to be improved (both in its design and in its content) to be a useful tool to promote our distribution. The marketing material that it contains need to be updated and extended. We could also create a Debian event box similar to GNOME's one. It contains a lot of useful material to hold a booth.

More recognition of our work can only lead to good things like a boost of motivation to do even more cool new stuff.

Recruit more contributors

While the number of packages in Debian increased a lot since 2001, the number of active developers stayed the same. We could definitely use more developers to continue increase the quality of our distribution (teams with hundreds of bugs are quite common). We made a first step with the Debian Maintainer proposal, but we can do more. I'm not saying that we should give upload rights to less skilled people: we don't want to compromise on quality. But we could have more contributors by improving simple things:

Redynamize core teams

This work has been started last year by Sam and the first results with the DSA team have been very positive. We need to build on that and get more developers joining all the core teams to prepare them for the future and to be ready to scale. This concerns at least the keyring managers, NM/DAM, ftpmasters, the press team.

Ideally, we should end up with teams that maintain their own description page on https://wiki.debian.org/Teams where they provide guidance for people who are looking to help. Fresh blood that brings back innovations is the best outcome for any team. The evolution of the security team is admirable in that regard.

Integrate useful unofficial services

We have several unofficial services that would deserve proper integration into Debian:

Share knowledge and help spread information

The DPL is often the privileged point of contact and as such he should participate actively in the diffusion of the relevant bits of information. In the spirit of https://wiki.debian.org/DeveloperNews, I will strive to communicate regularly on what's going on in the Debian world.

Add your ideas here

As DPL, I will listen to anybody who gets in touch with me. If you convince me, I'll see if there are ways for me to help you. If not, I might at least try to give you some advice. If you face problems related to Debian's internal organization, I'll do my best so that you can continue your volunteer work.

Rebuttal

DPL presence

Neither Steve nor Marc have explicitely endorsed the concept of a DPL team but both recognize the need to have a DPL that stays visible and involved. Unfortunately, between conferences and mail processing an already busy individual (like we all are!) will have troubles doing the extra work required to report regularly. At least Marc recognize the problems and plans to delegate a lot, but it's not clear what will be delegated and to whom.

On my side, I decided to work with Lucas and Moritz: they'll receive the mails sent to [email protected] and we will thus share the work of handling mails. With complete access to the DPL information, they can effectively share the important bits of information directly in day-to-day discussions on mailing lists and on IRC. A visible DPL is not only sending announces and reports, he also participates in public discussions. And last but not least, with 3 members it's much less likely to have a leader MIA during several weeks.

Communication and reporting

Both Marc and Steve acknowledge the fact that most teams need to communicate more about what they are doing. Steve doesn't say what he will do to make that change. Marc wants to pull the information and give it out. I don't think it's sustainable in the long term. The DPL's role is to solicit the teams and to show the example but he shouldn't have to do the work by himself (or by one of his delegate). It's in that spirit that I created https://wiki.debian.org/Teams and https://wiki.debian.org/DeveloperNews. We need simple tools to make it easy for teams to communicate and we need to change our habits to use them spontaneously.

Ideas and goals

Steve says a lot of sensible things about the current state of Debian in his platform, but doesn't say much about what he is going to work on if he is elected. Because of the lack of concrete proposals, there's not much to disagree with.

Marc has many good ideas and I would like to see them implemented in Debian. However I fail to see how being DPL will help him tackle those. The DPL status (and powers) should be used in priority to fix the problems that take the fun out of the Debian work.

I chose to limit my platform to the few things I really want to work on during my term. I do have lots of other ideas of interesting stuff that could be done, and I'll probably throw them out through the year so that volunteers people can pick them up, but I didn't want to include them in my platform. At the end of my term, I want to have made signifiant progress on each of the goals listed in my platform.

The state of core teams

Steve hasn't dealt with the topic in his platform. Marc acknowledge the problems but doesn't plan to do more than "constructive criticism". It's a good first step, but it's definitely not enough. I want to continue what Sam started: discuss to understand the problems, make proposals, implement possible solutions, be determined and do not let the situation rot indefinitely.