Introduction

I'm a 28 year old man. I'm married and have no kids yet. I'm self-employed and I decide alone how I spend my time.

Concerning Debian, I've always been interested in organizational issues and in quality assurance. To give more precise projects: I've helped setting up Alioth and I co-administrate it currently. I created the Package Tracking System and still maintain it with the help of a few others. A long time ago, I also pushed forward the sponsorship principle. I did my share of packaging, bug squashing, NMU, perl/python-policy creation, debian-cd maintenance and stuff like that all over the 8-9 years where I have been involved (1998-2007).

I already ran once for DPL in 2002. Please check the platform that I wrote at that time. Check out how many of my ideas/projects were right and have been implemented since, and how I consistently implemented several of the projects that I announced.

Why do I run for DPL this year? Only because...

I want a DPL board

I think that I have a good understanding and a good experience of the project as a whole. I would like to use that experience to serve the project, but would I have to handle alone the duties of such a demanding role, I would not run. I'm sure that I'm not alone in that position. I think the time is over to put too much hope in a single candidate each year.

I'm really convinced that working within a DPL board is the best way for me to serve the project and make constructive propositions. I'm in no way perfect, and I make mistakes, but I'm used to working with others (even when they don't agree with me), and the DPL board needs to exist because of this: I always need the advice of other trusted members to enhance any proposal so that it can be broadly accepted. I don't need to fear antagonisms within the board, because I'd rather drop an idea when I see that 3 members don't like it instead of proposing it broadly and generating yet another useless flamewar.

Believe me or not, I'm convinced that we can agree on some basic level and build from there.

How could it work? I outlined it in a recent mail to debian-project and I asked for feedback. I plan to delegate all the powers of the DPL to the board with a set of rules defining how the board can take decisions. After that I shouldn't have to directly use my DPL powers (except if the board needs fixing), and I expect to play an active role in the board making proposals when needed.

All board members would be added to the alias [email protected]. Near that a publicly archived discussion list restricted to the board members will be setup. That list would be the main tool for the board. Whenever a board member feels the need for an official decision, he makes a proposal which is then discussed on the list.
Some time after, the proposer decides that enough discussion has happened and he asks for a vote. This vote lasts for one week and the quorum is very small. The vote is usually a simple yes/no/further discussion. But the proposer may request a Condorcet vote if that's what is most appropriate according to him.

The board should represent the project in its diversity at a smaller scale. This should enable discussions by proxy where the discussion stay civilized because the board has been chosen with that objective in mind. The membership of the board should be chosen with a goal of maximizing the ability of each developer to relate to someone in the board so that he can express his point of view with confidence that someone will understand him and represent his opinion.

What would the board do? Whatever the board members think is needed. They have the DPL power and I expect them to use it wisely to pursue any beneficial Debian activity.

If possible I would like to work with this board:

The first four are unconditionnaly ready to serve within a DPL board. Josip would rather support an elected board like he described on debian-project. The others prefer to reserve their decision until the vote is over. Steve Langasek obviously wants to wait until Etch is out. Wouter and Sam would probably prefer be involved if the project decides that having a DPL board is a good idea. And they also don't want to indirectly endorse my candidacy.

This board will probably be extended by one german-speaking developer and another one from asia/australia. I couldn't get the required agreements in time for this platform, so it's left as first exercise for after the end of the election.

My personal projects / opinions

Of course, if I am elected, the ultimate decision on my projects will be up to the board. Still, it's worth telling a bit more in which direction I'd like to push the project.

Transparency and communication

I've read my share of flames over the years and it's getting boring to see that we have some recurring problems that could be mostly avoided with a couple more mails coming from responsibles behind various role addresses. Obviously they have their reason to stay silent most of the time and I believe this is directly related to the (bad) communication habits that we developed within the project.

My experience with Alioth proved to me that giving news in public will bring you some unneeded criticisms. Nevertheless, I continue to give news and handle much stuff publicly because I believe it's required for the long-term health of the team. Without this we couldn't have recruited two new volunteers.

Alioth is now used to maintain many packages and develop important part of our infrastructure, so the service is important and as closely watched as other DSA-maintained services. But it looks like we avoided most of the criticism while handling it.

I want to build on that experience and write a set of guidelines for internal teams that would be widely approved by the project, and then, over time, work with the various teams to help them meet those objectives.

Use what we package and package what we use

This is not really a project, but a policy that I'd like to promote. There are too many cases where we're using stuff which is not packaged in our main repository. In general we have good reasons for that: because it is Debian-specific and/or a hack. Examples that come to my mind: the DSA-maintained ssh, the PTS (yes, I did not package it), the difference between sbuild on buildds and the sbuild package, etc.

I think we should aim at always using our Debian main packages because that would require us to think a bit more globally and adapt our tools so that they can serve others too. We have many derivatives but they don't always use the same infrastructure as we do, partly because of that. Another advantage of having packages is that it naturally offers the BTS interface that can be used to report problems, ideas for improvements... and this in turn is useful for volunteers who want to help out some specific team and who are looking for something interesting to do.

Empower people to do (useful) stuff

Historically, we have numerous examples of people who have done stuff alone without any approval from the project/team in charge: Anthony wasn't ftpmaster when he wrote britney, I pushed for Alioth because I thought it was a good idea and DSA never approved nor blocked anything, the same goes for the testing security team.

If some people feel they are blocked in their work by a current problem and are willing to help, I'll do whatever I can to provide them the required resources. Alternatively I will come up with innovative ideas to go around the problems. Let's take the example of the lack of DD-accessible alpha porter machine. We could imagine a service that would let third parties offer access to their own machine. The Debian Developer who needs access to such a machine would request it on some webform. The machine owner would just have to install a specific package which would export three chroot and auto-update the access list (including public SSH keys) every 15 minutes from a central trusted place. The machine would also export some items of description (contact info, RAM, available disk space, CPU type, ...) that can be used by the developer to select on which machine he's likely to be able to do his work.

Support the occasional contributors

We strive to be the universal operating system and I fully share this goal. But for this, we need to leverage the power of the many occasional contributors. Some recent discussions have shown that we can do better at this: we could provide some better overview of packaging related changes to the hundreds of packagers that spend only a few hours a month on their (usually small) packages. Announcing policy changes on debian-devel-announce has been proposed and is likely to be done. I also think that the idea proposed last year by Anthony Towns should be implemented: after some successful rounds of sponsorship, we should be able to give upload access for that specific package to its maintainer and we shouldn't require him to go through NM if he doesn't want to because he's not more broadly interested in the project. Of course, we have to put some checks to avoid any loss in quality.

Why vote for me?

Why not? It looks like lots of my projects have had a positive outcome. Let's try some more!

Rebuttals

On my own platform

I have voluntarily focused on a limited list of projects but there's much more to do, in particular concerning Debian's outside communication. I'd like to use the board to draft some documents explaining the relationship of Debian with the various players from the free software world (see the original idea from my 2002 platform). Also we have some good communicants within the board and I'm sure that this will lead to more visibility for Debian.

Wouter Verhelst

I agree with most of what Wouter said. His plan to discuss first and decide next, is the only sane thing thing to do. But this information gathering step is best done within a team because it provides a better coverage of the various inter-personal relationships that are into play.

If I'm elected, I hope that he will confirm his participation in the DPL board and that he will pursue all the goals that he outlined in his platform.

Sam Hocevar

All of Sam's goal are interesting. I share most of his analysis of the situation. However, as an independant DPL I fear that he would be too much isolated to effectively interact with all the internal teams.

If I'm elected, I hope that he will confirm his participation in the DPL board and that he will pursue all the goals that he outlined in his platform.

Steve McIntyre

Steve's platform doesn't give many concrete projects but rather a global direction that he wants to follow. I welcome any initiative to solve the problems that he outlined.

I'm glad that he accepted to be part of the DPL board.

Anthony Towns

Anthony recognizes the need for more assisting leaders to share the load. He even explains how being involved in DPL activities helps you being more effective as full DPL later.

Clearly being DPL gives you access to more information than the average DD and this information is crucial to make Debian evolve without (too many) disruptions. I think this information needs to be shared by as many wise persons as possible and this is the intent of a DPL board.

I like his choice of topic-keywords but most projects outlined do not require to be DPL. I'll gladly provide him the required support so that he can complete his project of supporting non-DD maintainers. Having ambassadors is a nice idea, but with a board, we already have many co-DPL which are de-facto ambassadors of the project. I'm still open to the idea however.

Aigars Mahinovs

His big plans won't come into reality simply because he has been elected. The only Debian-specific project is so ambitious, that it's unlikely to ever be completed. However I'd definitely welcome new tools to make collaboration with derivatives easier, but this won't happen if it needs a big-bang change like he suggested.

Gustavo Franco

There are so many ideas in his platform, that he should have structured it and prioritize them. I lack the reasoning behind this large selection of projects/ideas.

Simon Richter

Simon sees the DPL as someone who must participate in all important discussions with the goal to promote an intermediary, reasonable position. This is a difficult task because you inevitably favor your own opinion. That's why I prefer having the discussions at a smaller-scale within a board representing Debian's diversity. The goal is the same, but it's done differently.

His platform only tackles this single internal communication problem. I lack a broader view of the direction where he wants to take Debian.

Sven Luther

His platform was not online when I wrote the rebuttal.