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
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@example.com> and Lucas Nussbaum
<firstname.lastname@example.org>. 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@example.com, 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 (firstname.lastname@example.org)
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:
- Gift bugs and public TODO lists. Many users don't contribute because they feel that we don't need their help. We could have a list of bugs that are easy to fix, so users can start making useful contributions and we should spread the word.
- Sponsorship. It's often very hard for maintainers to find a sponsor. We should work on our sponsorship infrastructure to make it more rewarding (less boring and more fun!) to sponsor uploads (ideas here).
- NM process. It often takes too long for very good candidates to go through NM, leading to a lot of frustration and discouragement. We must work on the bottlenecks.
- Non-packaging work. Many users don't have the skills to contribute patches to bugreports. We need to provide tutorials to get them started on non-packaging work: documentation, translation, communication and coordination!
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 http://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 servicesWe have several unofficial services that would deserve proper integration into Debian:
- mentors.debian.net: this goes together with the improved sponsorship infrastructure
- backports.org: it's run by Debian developers, packages are prepared by Debian developers, we should work with the security team and the ftp-masters to see how it can be organized.
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 http://wiki.debian.org/DeveloperNews,
I will strive to communicate regularly on what's going on in the Debian
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.
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@example.com 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 http://wiki.debian.org/Teams and http://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.