Platform for Bill Allombert

Background

I am 32 year-old and I have a Ph.D. in Pure Mathematics since 2001. I am teaching and doing research in Mathematics at the University of Montpellier, France.

My involvement in Debian:

I decided to join Debian because it is a successfull fully volunteer project, and the political significance of that appealed to me, more than the purely technical aspect.

I am Debian developer since June 2001. Initially I was involved in packaging computer algebra systems, because I developed them or used them in my work. Then I saw that a number of Debian-specific projects that I found important were not maintained (menu and popularity-contest) so I decided to fix them myself. Comparing their state in Woody and Sarge show that I have been successful.

I was also involved in improving the woody to sarge upgrade path, and I am contributing to the Debian policy mailing-list.

I am regularly participating to free software events in Europe, the Libre software meeting, Solutions Linux and FOSDEM, so I have met quite a number of you in real life. Unfortunately due to the uncertainty of my life, I have missed several Debconf in a row, but I was at the 0th one. I was at FOSDEM this week-end.

Why I have applied so late:

To avoid people to believe I am controlled by a giant tamagoshi, I will explain why I applied at the last moment.

I was at FOSDEM this week-end, and someone told me that Lars Wirzenius (which was also there) had denominated himself. At this point, I was not comfortable to vote for any of the remaining candidate, so I decided to take the matter in my hands and nominated myself, when it was clear no one else was nominating themself. However, I am not Lars, and I will not try to replace him.

Debian

In my opinion, the crucial point to have in mind when dealing with Debian is that Debian is a fully volunteer project.

This has several implications:

  1. No one can be forced to do anything.
  2. You depend on the good will of the others volunteers.
  3. Volunteers perform better the task they are interested in.
  4. Volunteers resent bureaucracy as a waste of time.
  5. Responsibility came with autority.
  6. There should be no articial barrier to contributing.

Communications

I will take the opportunuity to state some rules for better communications from my experience:

--- Be strict in what you send, liberal in what you accept.

When writing emails e.g., be careful that you wrote in no offensive to people etc. , but do not mind too much what other people write. Only the technical detail are important. One way is to cool down in that case, is to read the email and to wait 24 or 48 hour before replying.

--- Respect other people feeling.

Some developers have spent a lot of energy in some parts of the project and are emotionnaly attached to them. They deserve some "protections". If you break their feeling, it make no difference whether if your are technically right or wrong, they will resent it and communication will be very hard. Sometimes it is better to concede a point rather than breaking other people feeling.

--- What people can do by friendship, they will not do it by force.

People can agree to follow some rules to be friendly with others. They can object to the exact same set of rules if they are imposed upon them.

--- No one should ever feel obligated to reply to an email to a public forum (because one feel it is very inacurate, deficient, inappropriate, etc.).

In most case, the people reading the forum will reach the same conclusion about the deficiency, so there no point adding to the confusion and escalading the issue. Most of the time people writing 'Sorry, I had to reply' would have better ignored the post completly.

Whether or not I am elected, if you agree with these rules, please try to follow them!

How I see the DPL task.

In my opinion, the most important task of the DPL is to mediate between the developers. Some one most developers would be confident to appealing to in case of disagreement who would give at least a kind answer if nothing else can be done.

However there are lots other task to perform that must no be forgotten (coordinating, representing the project to the ouside, relation with Debian based distribution), but some of them can be delegated.

My projects

1 Thinking globally.

One of the problem of Debian is that too few developers consider the distribution globally rather than a collection of packages. For example, a package can be perfect by itself, but not fitting well with the rest of the distribution.

One reason is that working locally need much less coordination and is easier. Working globally usually require support from a lot of other people.

However thinking globally is very important to ensure the quality of the distribution and the coherence of the project.

2 Promoting "assistant" projects.

I would like to promote projects that are partially identical major Debian functions without duplicating/overstepping them. They are a great way to learn how to perform the function and to eventually get trusted to perform the major one. For example the Debian Testing Security team performs a similar job to the Debian security team, and the debian-volative team do an archive-management kind of job. We could have similar project for Debian system admin, port handling, etc.

3 Taking care of Debian-specific projects.

A lot of what have made Debian the leading edge is Debian-specific projects. Unfortunately such projects tend to get unmaintained over time, and this is a major issue.

As DPL, I would strive to ensure such project keep a minimal level of support.

4 Observers

The idea is to have neutral people regularly reporting about some task of Debian they are not involved with, trying to keep a neutral view.

The idea is that neutral observers do not suffer from the pressure of performing the task so can more easily (and less emotionnaly) describe what is going on, and they can be chosen for their interest and skill at reporting rather than their interest and skill at performing the task, which can be very different.

This could reduce the frustration of waiting for some task to complete, warn about tasks being without anyone anymore to fullfill them, etc.

I think this is an idea worth experimenting that could improve transparency.

Why should you vote for me

Rebuttals

Jeroen van Wolffelaar and Andreas Schuldei platforms

Jeroen and Andreas were part of the so-called "DPL team". Unfortunately this team failed in the promised status report and transparency, which has the side effect of making hard to evaluate the work they did.

In a large part, the current stress the project experiment is a direct consequence of this lack of DPL status report.

Objection on the "DPL team" concept

First, I must say I have no objection to a team of developers willing to act together to improve Debian through mediation, but I don't think they need the DPL label, especially when composed on developers working in the day to day operations of Debian, which should have already enough authority by themselves.

The DPL should be neutral to be able to mediate between everybody. However the DPL is not in a good position to mediate with members of the "DPL team".

That is not to say I believe the DPL should do everything alone, far from it, but the DPL should keep their independance, and probably give an equal chance to everybody willing to help him to do so, instead of relying on preselected hand-picked team.

Ari Pollak platform

Since Ari posted his rebuttal before seeing the other candidates platforms, I will preserve the balance in the force by posting this part of the rebuttal after the election is over.

Steve McIntyre platform

I agree with Steve on most points, in particular "Communications within the project". I certainly agree with this item. It is very important the developers feel that the DPL is actively working on issues. The failure to do so stress the project and cause heat.

However, I strongly disagree with "Mailing lists and IRC". In the current situation, I am not in favor with the creation of a code of conduct for mailing lists that is actively enforced. I don't think there is any consensus in Debian about what a code of conduct should say, and trying to introduce one would create yet more tension in the project.

Also, to make a long matter short, I would not feel confident to entrust the enforcement of such code to Steve.

Anthony Towns platform

Anthony is very involved in Debian infrastructure, and it is difficult to separate in his platform between what he will do as a DPL or as a regular developer. My feeling is that Anthony position in Debian is too central for him to play a mediation role and this role is very important to keep the balance in Debian.

Jonathan (Ted) Walther

While Jonathan enthousiasm is impressive, I am not sure he is entirely serious with his platform.

Thanks a lot to have read so far, and do not forget to cast your vote!

Friendly,
Bill