Programme de Branden Robinson

Introduction

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.

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.

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.

Pourquoi je suis candidat

Nous devons améliorer nos processus

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 :

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 ».

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.

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.

À 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 ; malheureusement, je suspecte que nous pourrions par mégarde encourager ce genre de drame parce que c'est la seule alternative que certaines personnes voient pour que leurs réclamations soient totalement ignorées.

Ê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.

Nous avons besoin de processus plus ouverts et plus transparents

Les améliorations sont moins précieuses, et ont moins de chances d'être reconnues, voire remarquées, 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 toujours 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.

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 que ça fonctionne.

Nous avons besoin d'un responsable qui défende notre cause

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 ».

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.

Nous devrions prendre notre constitution plus au sérieux

J'ai été déçu d'apprendre 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.

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 importantes. 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.

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.

On m'a demander de me porter candidat

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.

Ce que je ferai

Maintenant que nous avons énoncé quelques-uns de nos défis et de nos opportunités, les solutions semblent venir d'elles-mêmes.

Je mettrai en place des mécanismes pour rendre nos processus plus transparents

Je suis en train de paramétrer l'installation d'un suiveur de requêtes (paquet Debian request-tracker3) sur une de mes machines pour servir de site « médiateur » (décision de débat). 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.

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

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.

Je ferai des comptes-rendus réguliers aux développeurs sur mes activités de responsable du projet

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.

Je respecterai et renforcerai notre système de décision constitutionnel

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.

Je respecterai la valeur et les contributions de chacun de nos développeurs

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 devrait ê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.

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.

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.

Je construirai des relations avec les autres entreprises et organisations du logiciel libre et de code source ouvert

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 (GNU Free Documentation License) 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.

Je ferai tout ce que je peux pour faire du projet Debian un exemple irrésistible à suivre

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 œuvre nos spécifications — nous ne faisons pas ce que nous écrivons. Tout projet est unique, et c'est la raison 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.

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 ?

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.

Merci de votre soutien, et pour votre participation au projet auquel je crois.

XHTML 1.0 valide ! CSS valide !

Valider le XHTML de cette page.
Valider la CSS de cette page.

$Id$