--
#use wml::debian::template title="Programme de Branden Robinson" BARETITLE="true" NOHEADER="true"
#use wml::debian::translation-check translation="1.4" maintainer="Nicolas Bertolissio"
#include "$(ENGLISHDIR)/vote/style.inc"
<h1 class="title">Programme de Branden Robinson</h1>
<ul class="spacey">
<li><a href="#s1">Introduction</a></li>
<li><a href="#s2">Pourquoi je suis candidat</a>
<ul>
<li><a href="#s2p1">Nous devons améliorer nos processus</a></li>
<li><a href="#s2p2">Nous avons besoin de processus plus ouverts et plus
transparents</a></li>
<li><a href="#s2p3">Nous avons besoin d'un responsable qui défende notre
cause</a></li>
<li><a href="#s2p4">Nous devrions prendre notre constitution plus au
sérieux</a></li>
<li><a href="#s2p5">On m'a demander de me porter candidat</a></li>
</ul></li>
<li><a href="#s3">Ce que je ferai</a>
<ul>
<li><a href="#s3p1">Je mettrai en place des mécanismes pour rendre nos
processus plus transparents</a></li>
<li><a href="#s3p2">Je travaillerai avec mes délégués, avec les
développeurs, et avec les utilisateurs pour identifier les parties
spécifiques qui ont besoin d'être améliorées, y compris la gestion des
éditions et le processus des nouveaux responsables</a></li>
<li><a href="#s3p3">Je ferai des comptes-rendus réguliers aux développeurs
sur mes activités de responsable du projet</a></li>
<li><a href="#s3p4">Je respecterai et renforcerai notre système de décision
constitutionnel</a></li>
<li><a href="#s3p5">Je respecterai la valeur et les contributions de chacun
de nos développeurs</a></li>
<li><a href="#s3p6">Je construirai des relations avec les autres
entreprises et organisations du logiciel libre et de code source
ouvert</a></li>
<li><a href="#s3p7">Je ferai tout ce que je peux pour faire du projet
Debian un exemple irrésistible à suivre</a></li>
</ul></li>
</ul>
<h2 id="s1">Introduction</h2>
<p>
Je suis développeur Debian depuis janvier 1998 environ. Je suis
principalement connu dans Debian en tant que responsable des paquets de
XFree86, travail que je réalise depuis pratiquement six ans, depuis
mars 1998. D'août 2001 à février de cette année, j'officiais comme
trésorier de Software in the Public Interest, Inc., l'organisation légale mère
de Debian et comme gestionnaire des avoirs du projet Debian aux États-Unis.
En 2002, j'ai rejoint l'équipe des rédacteurs de la Charte de Debian. Je
suis un pilier de la liste de diffusion debian-legal, et je participe avec
d'autres développeurs à l'examen minutieux et à l'analyse des termes et des
conditions d'application de diverses licences de logiciels, ainsi que la façon
dont elle concordent avec les directives de Debian pour les logiciels libres
(DFSG). Bien sûr, on me trouve aussi sur d'autres listes de diffusion de
Debian. J'ai 29 ans et je travaille comme développeur de logiciels libres,
je suis marié et sans enfants.
</p>
<p>
<p>
Au cours de l'année dernière, le travail dont je suis le plus fier est la
transition des paquets Debian de XFree86 d'un travail basé sur une seul
personne à celui d'une équipe. Grâce à cela, j'ai grandement accru la
visibilité au jour le jour du travail effectué sur les paquets Debian de
XFree86, et l'indexation de modifications, petites ou importantes, a été
incroyablement facilitée. La disponibilité publique d'un dépôt subversion
permet à chacun de récupérer et de construire les paquets à venir, de soumettre
des rustines, et de rechercher des erreurs dans les modifications. La
transition a demandé pas mal de travail car elle était faite en même temps que
la maintenance du paquet, mais cet investissement a déjà été récompensé en
terme de plus grande ouverture et de révision, et je pense que cela se révélera
encore plus payant dans l'avenir avec plus de délégation et de partage de
tâches. J'insiste sur ce travail car nombre de ces avantages pour gérer le
développement logiciel se retrouvent aussi pour la gestion de projets, comme je
vais le montrer.
</p>
<p>
D'abord, je vais expliquer les motivations qui m'ont fait me porter candidat,
ensuite je décrierai les actions que j'ai l'intention de prendre si je suis
élu.
</p>
<h2 id="s2">Pourquoi je suis candidat</h2>
<h3 id="s2p1">Nous devons améliorer nos processus</h3>
<p>
La plupart des pires conflits internes de Debian (aussi connu sous de nom de
« trolls ») ces dernières années portaient autour des trois questions
suivantes :
</p>
<ul>
<li>le cycle d'édition ;</li>
<li>le processus des nouveaux responsables ;</li>
<li>les tâches d'infrastructure et d'administration.</li>
</ul>
<p>
Bien trop souvent je vois des discussions sur ces sujets finir en cris avec
comme alternative : « untel nous empêche d'avancer » ou
« tout va bien, et votre plainte ne mène à rien ».
</p>
<p>
Ce genre d'arguments, à mon sens, et d'après tout le temps et toutes les pages
de courriel qui leurs sont consacrées, sont à côté de la question. J'ai la
conviction que nous avons ces conflits parce que les informations pertinentes
sont trop difficiles à acquérir, et les forums pour résoudre les réclamations
ou les doléances non techniques ne sont pas suffisamment développés.
</p>
<p>
Plus simplement, il est trop difficile pour ceux qui n'ont pas d'idées d'avoir
des idées, et en l'absence de procédure de sauvegarde adéquate pour les
personnes mécontentes, les attaques se font personnelles. Ce qui, à tour de
rôle, met les gens sur la défensive (parfois pour eux-mêmes, parfois au nom des
autres), et les récriminations perdent tout contrôle.
</p>
<p>
À mon avis, et tout compte fait, nous faisons un travail correct sur ces
points. S'ils étaient vraiment effroyables, le projet Debian ne serait pas
prospère. De nombreuses personnes ont la sensation que le cycle d'édition est
trop lent ; c'est possible, mais on devrait essayer de rappeler à quelques
uns des nombreux projets de logiciels libres (ou même des distributions) qu'ils
ne sont plus dans la course car ils n'ont jamais pu atteindre la
version 1.0, ou qu'ils ne peuvent plus supporter leur propre
développement. Notre processus des nouveaux responsables fonctionne aussi trop
lentement (et parfois trop mystérieusement) pour certaines personnes, mais nous
faisons bien mieux que lorsque nous n'admettions pas de nouveaux responsables
du tout dans notre projet. Il devrait également être évident que de
l'administration système aux listes de diffusion, aux démons de construction,
et au système de gestion des bogues, les choses essentielles fonctionnent, et
elles fonctionnent la plupart du temps sans à-coup. Je pense qu'il est peu
judicieux de dramatiser autant ces problèmes visibles<!-- it is unwise to
invest observable problems with a lot of drama --> ; malheureusement, je
suspecte que nous pourrions par mégarde encourager ce genre de drame<!-- drama
--> parce que c'est la seule alternative que certaines personnes voient pour
que leurs réclamations soient totalement ignorées.
</p>
<p>
Être bon c'est bien, mais nous pouvons être meilleurs. La compétence est
convenable, mais nous devrions faire notre possible pour atteindre
l'excellence. J'attends avec impatience de nous rendre meilleurs dans ce que
nous faisons.
</p>
<h3 id="s2p2">Nous avons besoin de processus plus ouverts et plus
transparents</h3>
<p>
Les améliorations sont moins précieuses, et ont moins de chances d'être
reconnues, voire <em>remarquées</em>, si elles se passent de façon invisible.
De la même manière, il est difficile de savoir ce qu'il faut corriger si ce qui
est faux n'est pas clair. Les propositions d'amélioration de certaines
personnes ont été écartées parce que leurs reproches sous-jacents n'étaient pas
clairs. Bien que je m'associe très certainement au désir de voir les plaintes
que portent les gens contre notre projet et le travail que nous faisons plus
précises, une erreur lors de la présentation des faits ne rend pas
<em>toujours</em> un problème inexistant. J'ai vu des gens passer énormément de
temps à corriger et à réfuter de telles erreurs, parfois avec un ton
particulièrement déplaisant.
</p>
<p>
La communication directe peut être très efficace. Dans de nombreux domaines, la
documentation sur le fonctionnement de notre projet est inexistante,
inadéquate, inaccessible, ou simplement trop difficile à trouver. Je pense que
nous pouvons empêcher les critiques qui font perdre leur temps aux
gestionnaires de nos infrastructures, en qui nous avons le plus confiance, de
les atteindre en améliorant à la fois la présentation des informations
factuelles sur notre travail et en ayant une méthode plus structurée pour
diriger ces plaintes vers les personnes appropriées. Il serait bon de séparer
le bon grain de l'ivraie — les plaintes justifiées des
approximatives — de façon claire et compréhensible, afin que les
gens puisse voir non seulement comment ça fonctionne, mais aussi <em>que</em>
ça fonctionne.
</p>
<h3 id="s2p3">Nous avons besoin d'un responsable qui défende notre cause</h3>
<p>
Dans mon travail, j'ai le privilège de parler à des gens de l'industrie (et pas
seulement aux États-Unis) de ce dont ils ont besoin dans une distribution
GNU/Linux. Je vois rarement des cas où il n'y a pas une occasion d'adopter
Debian (à l'exception des personnes qui cherchent une compatibilité avec Red
Hat ou SuSE — ou le format de paquet RPM — en
particulier, mais pas à cause de ce qu'elles cherchent à faire avec leur
ordinateur). J'ai montré de l'intérêt pour l'énorme croissance de Debian ces
quatre ou cinq dernières années. Debian a engendrée de nombreux sous-projets et
déviations compatibles, ce qui contribue à ce que nous nous montrions digne du
surnom de « système d'exploitation universel ».<!-- helps us to live
up the "universal OS" moniker -->
</p>
<p>
Debian empiète apparemment sur tous les domaines ; je veux accélérer ce
processus et évangéliser Debian partout où je le peux. Je ne vois pas du tout
le phénomène des sous-projets ou des déviations compatibles comme une menace
pour nous ; au contraire, c'est le guide de notre succès. À mon avis, nous
avons la capacité de faire de Debian un standard de fait de l'industrie ;
l'entreprise dans laquelle je travaille a obtenu un certificat de conformité
LSB pour un instantané de Sarge en janvier. Je suis enthousiasmé par Debian
depuis je jour où je suis devenu responsable de paquet, et je suis toujours
enflammé aujourd'hui. De plus, je peux communiquer cet enthousiasme et cette
flamme à un auditoire avec beaucoup d'effet.
</p>
<h3 id="s2p4">Nous devrions prendre notre constitution plus au sérieux</h3>
<p>
J'ai été déçu d'<a
href="http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00041.html";>\
apprendre</a> en novembre que le responsable actuel du projet ne pensait pas
que Debian ne fonctionnait pas vraiment grâce au processus de délégation de
notre constitution. Il a qualifié de « pragmatique » un refus de
nomination de délégués des administrateurs des archives, des administrateurs
système, et ainsi de suite. Je laisse à nos développeurs et nos utilisateurs
décider eux-mêmes de la justesse de cette décision, mais je sais que cette
position est contraire à mon interprétation de notre constitution. D'après
notre site la constitution de Debian est « un document de la plus haute
importance pour l'organisation ». En conséquence, je pense que nous
devrions lui porter un peu plus de respect. La constitution de Debian reconnaît
six groupes ou individus de décideurs : les développeurs (agissant en
groupe par une résolution générale), le responsable du projet, le comité
technique, les développeurs individuels travaillant à une tâche particulière,
le secrétaire du projet, et les délégué du responsable du projet.
</p>
<p>
Nous devons respecter le processus de délégation, ou l'amender. Je ne pense pas
que chaque « tâche particulière » du projet ressemble à la
maintenance d'un paquet. Les rôles de l'administrateur des archives, de
responsable du porte-clés du projet, et de l'administrateur système du projet
sont <em>importantes</em>. En pratique, nous distinguons ces rôles de celui de
responsable de paquet de plusieurs façons. Ils ont une importance particulière
et méritent une attention spéciale. Je ne pense pas qu'ils puissent
raisonnablement être mis dans la même catégorie que la gestion d'un paquet
individuel. Ils ont un pouvoir spécial et devraient être traités de manière
particulière. Le concept des délégués a été rédigé dans la constitution en
pensant à ces rôles. Je suis déçu qu'aucun des précédents responsables du
projet Debian n'ait franchi ce pas évident.<!-- That no previous DPL has taken
the obvious step is a disappointment to me -->
</p>
<p>
La constitution de Debian décrit le processus d'élection du responsable du
projet. Cela avait été fait ainsi en prévision de l'importance de ce rôle. Nous
devrions avoir un débat entre les candidats afin de permettre de comprendre qui
nous sommes et où nous allons. Je ne serais pas candidat si quelqu'un pouvait
voir les problèmes que le responsable du projet Debian était habilité à
résoudre.
</p>
<h3 id="s2p5">On m'a demander de me porter candidat</h3>
<p>
J'ai eu de bons résultats l'année dernière dans une triangulaire serrée, et je
me porte à nouveau candidat pour me charger de répondre aux besoins de nos
développeurs et de nos utilisateurs. La campagne n'est pas pour moi la partie
la plus joyeuse, je ne m'attends pas non plus à ce que le débat sur les
problèmes que je vois soit une partie de plaisir. Après avoir demandé l'avis de
nos développeurs sur la liste de diffusion debian-project, beaucoup m'ont
poussé à me porter candidat, et ils ont des vues très logiques sur ce qui ne va
pas dans le projet et sur ce que je pourrais faire. Il y a certaines
responsabilités que je souhaite accepter parce que je prends trop soin du
projet Debian pour ne pas lui donner toute l'énergie possible.
</p>
<h2 id="s3">Ce que je ferai</h2>
<p>
Maintenant que nous avons énoncé quelques uns de nos défis et de nos
opportunités, les solutions semblent venir d'elles-mêmes.
</p>
<h3 id="s3p1">Je mettrai en place des mécanismes pour rendre nos processus plus
transparents</h3>
<p>
Je suis en train de paramétrer l'installation d'un suiveur de requêtes (paquet
Debian <code>request-tracker3</code>) sur une de mes machines pour servir de
site « médiateur » (décision de débat<!-- HELP: dispute resolution
-->). Le système de gestion des bogues de Debian n'est, à mon avis, pas bien
équipé pour gérer les problèmes hors logiciels, et les listes de diffusion,
comme nous l'avons vu maintes fois, sont souvent une mauvaise alternative. J'ai
expérimenté le suiveur de requêtes à mon travail, et il n'est pas difficile
d'apprendre à s'en servir. Si cette expérience se révélait être une réussite,
je travaillerai avec les administrateurs système de Debian pour le déménager
sur une machine du projet Debian. De plus (et avec plus d'insistance si cette
expérience échoue), je poursuivrai d'autres voies pour rendre le fonctionnement
du projet clair là où il est actuellement opaque.
</p>
<h3 id="s3p2">Je travaillerai avec mes délégués, avec les développeurs, et avec
les utilisateurs pour identifier les parties spécifiques qui a besoin d'être
améliorées, y compris la gestion des éditions et le processus des nouveaux
responsables </h3>
<p>
Je ferai évidemment le pas décrit dans la section précédente, et je
formaliserai le statut des délégués et des nombreuses personnes importantes qui
font un travail critique pour notre projet et qui n'ont pas encore le statut de
délégué. Dans l'éventualité où je ne pourrais pas le faire, ou si j'étais
persuadé que c'était une mauvaise idée, j'expliquerais à tout le projet
pourquoi je ne peux pas, et puis, si nécessaire, je proposerais une résolution
générale pour amender notre constitution afin de refléter l'organisation réelle
de Debian.
</p>
<h3 id="s3p3">Je ferai des comptes-rendus réguliers aux développeurs sur mes
activités de responsable du projet</h3>
<p>
J'ai été déçu de la fréquence et du contenu des comptes-rendus du responsable
du projet aux développeurs ces quelques dernières années. En tant que
responsable du projet, je ferai des comptes-rendus de mes activités aux
développeurs au moins une fois par mois. Ces comptes-rendus ne seront pas
limités à des descriptions de conférences auxquelles j'aurai assisté ou
auxquelles je prévoirais d'assister, ou à des vues d'ensembles de l'état du
projet ; je décrirai aussi les tâches spécifiques sur lesquelles je
travaillerai et les problèmes qu'on m'aura demandé de résoudre.
</p>
<h3 id="s3p4">Je respecterai et renforcerai notre système de décision
constitutionnel</h3>
<p>
Je ferai tout ce que je peux pour assurer que notre organisation réelle reflète
notre constitution, et vice versa. Un projet qui ne prend pas en compte ses
documents et principes fondamentaux est un projet en difficultés, et peut
causer du tord à l'image que perçoivent ceux qui ne sont pas familiers du
fonctionnement réel de Debian, en s'attendant à trouver des renseignements sur
notre site web qui prétend les leur fournir.<!-- c est pas beau... -->
</p>
<h3 id="s3p5">Je respecterai la valeur et les contributions de chacun de nos
développeurs</h3>
<p>
Le projet Debian, d'après notre contrat social, existe pour servir nos
utilisateurs et les logiciels libres. Pour faire effectivement cela,
l'organisation de Debian doit servir les besoins de tous ses développeurs en
tant que groupe. C'est parfois un défi, car nous sommes un corps hétérogène, et
nos membres sont disséminés tout autour du monde. On peut parfois être tenté de
traiter de manière préférentielle avec nos amis ou avec ceux qui sont proches
de nous géographiquement. Quoi qu'il en soit, céder à de telles tentations crée
de l'injustice et de l'inégalité entre les développeurs. Debian
<em>devrait</em> être une méritocratie, et le mérite devrait être mesuré par
les contributions de chacun au projet, pas par la nationalité d'un développeur
ou ses relations non électroniques. Debian est née sur le Réseau et ne pourrait
pas exister sans lui. La facilité des communications électroniques est notre
avantage le plus important, et la manière la plus efficace que nous possédons
de gommer les injustices. Nous ne devons pas abandonner cet attribut essentiel
en faveur d'un quelconque provincialisme. Les développeurs qui ne peuvent pas
assister à nos conférences annuelles, ou nos autres rencontres physiques, ne
doivent pas être traités avec moins d'estime. Nous devrions tout faire pour
nous rappeler des contributions incroyables de Joel Klecker, contributions qui
n'étaient pas moins intéressantes à cause de sa quasi-impossibilité de se
joindre à une rencontre physique de développeurs.
</p>
<p>
En tant que responsable du projet, je ferai mon possible pour assurer qu'aucun
système de privilèges particulier ne soit établi ou ne perdure pendant mon
mandat. Je suis persuadé que les plus estimables de nos contributeurs n'ont pas
besoin qu'un seul avantage particulier leur soit conféré, et de même nous
n'avons pas besoin de réduire le potentiel de futurs contributeurs par des
pratiques qui les excluraient de fait, bien qu'elles puissent paraissent
innocentes et opportunes au premier abord.
</p>
<p>
Plus une décision est importantes, plus il est critique qu'elle soit prise de
façon ouverte et publique sans biais de procédure en faveur ou contre un
développeur. Il s'agit d'un critère fort, mais essentiel, et je promet de faire
tout ce qui est en mon pouvoir pour que nous nous y tenions.
</p>
<h3 id="s3p6">Je construirai des relations avec les autres entreprises et
organisations du logiciel libre et de code source ouvert</h3>
<p>
Je ferai appel à des volontaires pour exercer comme délégué officiel à d'autres
organisations quand nécessaire. Le responsable du projet Debian actuel a
désigné quelques personnes pour communiquer avec la Free Software Foundation à
propos de quelques unes des questions que nos développeurs se posaient sur la
licence de documentation libre GNU (<i>GNU Free Documentation License</i>) et
sur la façon dont cette licence interagissait avec les principes du logiciel
libre selon Debian. L'année précédente, Bdale Garbee avait nommé Mark Johnson
notre représentant à OASIS. Je pense qu'il s'agit de bons exemples, et ils font
partie d'un phénomène que je voudrais amplifier. Je ne vois pas pourquoi nous
n'aurions pas d'« ambassadeur » à la FSF, une personne qui comprenne
les besoins et les intérêts des deux organisations, si vous voulez, et qui
puisse contribuer à éviter des frictions inutiles. Et nous pourrions faire de
même avec Red Hat Software, Novell, FFII, FSF Europe, et ainsi de suite.
</p>
<h3 id="s3p7">Je ferai tout ce que je peux pour faire du projet Debian un
exemple irrésistible à suivre</h3>
<p>
Récemment, une personne a écrit à la liste debian-project en demandant des
conseils pour savoir comment elle pourrait utiliser l'exemple d'organisation de
Debian pour sa communauté de logiciels à but non lucratifs. J'ai été flatté et
je pense que nous pouvons tous l'être en lisant ce message, mais comme vous
pouvez le voir ci-dessus, nous pourrions être encore un meilleur exemple. Dans
de trop nombreux cas, une organisation qui voudrait suivre notre exemple serait
déçue car nous n'avons pas mis en œvre nos spécifications
— nous ne faisons pas ce que nous écrivons. Tout projet est unique,
et c'est <em>la raison</em> pour laquelle nous devrions faire mieux en
expliquant au reste du monde ce que nous faisons — ainsi nous
pourrions aussi prendre le temps d'expliquer pourquoi nous le faisons. En
faisant cela, nous pourrions examiner de nouveau les hypothèses que nous avions
faites, et à travers ce processus nous pourrions améliorer Debian.
</p>
<p>
En tant que responsable du projet Debian, je m'engagerai à rendre le projet
Debian une organisation ou les choses sont faites de la bonne façon. Nous avons
déjà pratiquement acquis une reconnaissance universelle sur ce point lorsqu'il
s'agit de questions techniques. Pourquoi devrions nous nous résoudre à moins
lorsqu'il s'agit de notre organisation ?
</p>
<p>
J'ai affronté les défis que j'ai rencontrés dans mon travail pour le projet
Debian dans le passé, et je suis prêt à affronter celui d'être le responsable
du projet Debian.
</p>
<p>
<strong>Merci de votre soutien, et pour votre participation au projet auquel je
crois.</strong>
</p>
Attachment:
signature.asc
Description: Digital signature