Programme de Matthew Garrett

Introduction

Je m'appelle Matthew Garrett et je suis candidat au poste de responsable du projet Debian. Je suis développeur Debian depuis 2002. À l'intérieur de Debian, j'ai été impliqué dans l'entretien de paquets, dans le portage de Debian vers des noyaux non-Linux et dans des discussions concernant les problèmes techniques et philosophiques environnant le projet. Cela comprend des négociations avec des détenteurs de droit d'auteur pour essayer d'obtenir des logiciels sous une licence libre compatible avec les principes du logiciel libre selon Debian, l'analyse du caractère libre (ou non) de licences et la défense de ce que je considère comme des standards libres appropriés pour Debian. Je représente Debian au bureau consultatif de Gnome, je fais la liaison avec des représentants de Sun, Novell, Red Hat, IBM et d'autres. À ce sujet, j'ai obtenu l'engagement que Gnome ne dépende pas de fonctionnalités Java non libres. À l'extérieur de Debian, j'ai été développeur principal du projet dasher (une application d'accessibilité), j'ai travaillé à améliorer l'état du support par Linux de la suspension et la reprise avec l'interface avancée de configuration et de gestion de l'énergie (ACPI) et je contribue au projet Gnome.

Dans la vie, je suis doctorant en biologie calculatoire au département de génétique de l'université de Cambridge. J'ai l'intention d'utiliser mes compétences au bénéfice des forces du bien.

Les sujets que doit affronter Debian

Communication

La communication interne de Debian est pauvre actuellement. Les standards de communications qu'attendent les équipes qui sont responsables de la plupart de l'infrastructure du projet ne sont pas clairs. En même temps, les informations sont parfois demandées d'une manière qui n'encourage pas les équipes à répondre. L'ensemble de cela fait que tout le monde est mécontent de la communication.

Vous pouvez retrouver dans ce problème des débats aussi classiques que pourquoi des paquets ne sont pas encore construits pour certaines architectures, pourquoi quelqu'un n'a pas été accepté comme responsable et beaucoup d'autres. Ces disputes produisent rarement des discussions utiles, consument du temps qui pourrait être dépensé ailleurs et entretiennent la perception d'une atmosphère agressive dans Debian. Le manque de communication engendre aussi chez les gens une mauvaise image de ce qui se trouve entre l'état actuel de Debian et notre version publiée. Notre mauvaise communication est le seul et le plus important des problèmes que le projet doit affronter actuellement. Il doit être corrigé.

Consensus

Debian est un projet de logiciels libres. La discussion sur la résolution générale qui a modifié le contrat social (et bien plus de débat que vous ne pourriez l'imaginer sur debian-legal) montre que les gens ont des critères très différents de ce que « libre » signifie dans ce cas. J'ai constamment défendu mes convictions sur la liberté contre la ligne la plus dure des définitions qui ont été développées, mais il n'est pas facile de savoir laquelle de ces définitions correspond au plus près à ce que pensent les développeurs.

Une divergence fondamentale de ce type entraîne encore plus de débat, mais il n'y a actuellement aucun moyen pour déterminer quelle est la bonne définition. Depuis que le contrat social a été écrit, le monde a changé et les questions pour lesquelles nous nous battons maintenant n'avaient jamais été imaginées en ce temps-là. L'une des conséquences est que nous sommes incapables de nous mettre d'accord sur l'acceptation (ou pas) de licences qui cherchent à protéger les gens des poursuites sur les brevets. Et peut-être pire, le manque d'accord sur ce en quoi nous croyons rend plus difficile la pression pour nos convictions. Si je suis élu, je ferai tout mon possible pour aider Debian à atteindre un accord sur ce en quoi nous croyons.

Autres

Ce ne sont pas les seuls problèmes que rencontre Debian et je crois que la plupart des autres problèmes sont la conséquence de ceux-ci. Nous avons échoué à publier une version car des nouvelles questions n'arrêtent pas de se poser. Avec une communication adéquate, une grande partie de ce délai aurait pu être évitée. L'approche des questions de licence par Debian est souvent critiquée, mais il nous est difficile de répondre car nous manquons d'un consensus suffisant à l'intérieur même du projet.

Il se pourrait bien que certains autres problèmes ne soient la conséquence d'aucune des deux questions que j'ai soulevées — la communication et le consensus. Quoi qu'il en soit, je crois qu'ils sont assez négligeables en comparaison. Nous devrions nous concentrer à corriger les carences principales avant de nous inquiéter d'une multitude d'autres plus mineures.

Ce que je ferai pour cela

Améliorer la communication

Après les élections, je contacterai chaque équipe pour discuter de la façon qu'elle considère la meilleure pour communiquer avec le reste du projet. Cette information sera documentée et rendue publique. Ensuite, s'il y a des plaintes sur la communication inadéquate d'une équipe, j'examinerai la question et ferai ce que je pourrai pour m'assurer que la situation ne se reproduise pas. Dans le cas où une équipe faillirait à maintenir une communication adéquate avec le reste du projet, je ferai tout ce qui sera nécessaire pour m'assurer que le problème sera corrigé. Il est inacceptable que le développement soit ralenti parce que certaines personnes ne sont pas sûres de ce qui se passe. Quoi qu'il en soit, il est également inacceptable que des développeurs abusent des membres d'une équipe. Les développeurs qui sont incapables de communiquer de façon raisonnable ne doivent pas s'attendre à recevoir de retours utiles, et cela doit être accepté par la communauté.

Dans le passé, Debian était plus petit et la communication entre les personnes était plus facile. Maintenant nous avons grossi au point qu'il est parfois difficile de se rappeler que chaque personne impliquée est un bénévole. Cela ne modifie en rien l'importance de la communication et ce doit être le travail du responsable du projet de s'assurer que cette communication vitale existe.

Construire un consensus pour l'avenir

Après la publication de Sarge, j'engagerai un débat sur le contrat social. Il sera scindé en deux parties :

S'il devenait clair que le contrat social actuel ne reflétait pas les convictions des gens à propos de Debian, alors je travaillerais à écrire une version préliminaire de résolution générale pour le modifier. Je chercherais à m'assurer que les répercussions de toutes les modifications soient bien comprises avant de procéder au vote, afin d'éviter une controverse sur les résultats ensuite. Bien que ce processus entraîne sans aucun doute de longs débats enflammés, je pense qu'ils réduiront les désaccords sur ce que Debian représente à l'avenir.

La publication des versions

Au moment où j'écris ces lignes, cela fait 31 mois que la dernière version de Debian a été publiée, en juillet 2002. Cela n'est pas acceptable. L'équipe de publication a été entravée par des problèmes de communications entre les équipes, ce qui a fait que des problèmes bloquant la publication n'ont pas pu être découverts avant qu'il ne soit trop tard pour les éviter. Je travaillerai avec l'équipe de publication pour m'assurer que les soucis potentiels soient exprimés clairement à l'avance et pour m'assurer que l'on travaillera activement dessus. Une meilleure communication n'entraînera pas directement une publication plus rapide, mais elle permettra de montrer quels progrès ont besoin d'être réalisés avant que la publication ne survienne.

Veuillez remarquer que des publications plus rapides engendreront d'autres problèmes, augmentant le nombre de versions que nous devrons entretenir en même temps. Je me rapprocherai de l'équipe de sécurité et du gestionnaire de la version stable pour m'assurer que nos utilisateurs ne soient pas obligés de faire trop de mises à jour ou ne doivent utiliser une distribution qui n'ait plus de support de la sécurité.

Pourquoi je souhaite faire cela

Je ne crois pas que le responsable du projet Debian devrait être responsable de la gestion quotidienne de Debian. Je ne crois pas non plus que le responsable du projet Debian devrait décider de la direction que devrait prendre le projet. Je crois que ces responsabilités incombent aux développeurs du projet et aux équipes qui ont autorité sur diverses sections de la distribution. Le rôle du responsable du projet Debian devrait être de s'assurer qu'il est possible pour chacun de tenir son rôle. Je crois que la meilleure manière d'y arriver est de réduire les opportunités de conflits à l'intérieur du projet, d'améliorer la communication, la transparence et le consensus. Les objectifs que j'ai soulignés ci-dessus sont généraux, mais je crois fortement qu'ils sont les plus importants dont le projet ait à s'occuper et je crois qu'ils seront réalisés le plus facilement grâce aux pouvoirs conférés au responsable du projet Debian.

Pourquoi moi ?

À la fois dans et hors de Debian, j'ai montré ma capacité à engager des discussions sans confrontation. J'ai de bonnes relations avec les membres de la majorité des équipes de délégués dans Debian, ce qui m'a permis de travailler sur de la documentation pour fournir des informations sur leurs rôles et leurs responsabilités au sein de Debian. J'ai représenté Debian avec succès auprès de figures de l'industrie, m'assurant que nos préoccupations étaient entendues.

En résumé, je crois qu'atteindre un consensus et communiquer sont les défis les plus importants que rencontre Debian actuellement, et qu'en tant que responsable du projet Debian je serai capable de les relever.

Réfutation

Trois des autres candidats ont débattu de la façon dont le responsable du projet Debian devrait effectivement déléguer des tâches. Anthony Towns dit :

J'ai la conviction que Debian pourrait s'améliorer ici simplement en donnant aux délégués une autorité claire pour prendre des décisions dans leurs domaines d'expertise, ainsi qu'en acceptant que l'on puisse persuader et convaincre les délégués et les responsables de paquets que quelque chose pourrait être fait d'une certaine façon.

Et la proposition « Scud » de Branden Robinson et d'Andreas Schuldei de désigner une équipe de délégués pour remplir de nombreuses fonctions du responsable du projet Debian ont été largement débattus.

Il est vrai qu'il faudrait fournir aux délégués l'autorité de prendre des décisions, et s'attendre à ce que la bonne décision puisse être prise sans recevoir de critiques indues. Cependant, les délégués ont besoin d'être responsables devant le projet entier, pas seulement le responsable du projet. Il est tout à fait raisonnable que les développeurs demandent comment les délégués sont arrivés à prendre certaines décisions, et tout à fait juste de s'attendre à recevoir des réponses raisonnables. Si cela devait conduire à des demandes inacceptables comparées à la disponibilité des délégués, nous devrions nous saisir des causes principales du problème en nous assurant que les délégués aient plus de ressources disponibles. Le manque de temps ne devrait pas être une excuse pour le manque de responsabilité envers tout le projet.

Le projet Scud est une courageuse tentative pour résoudre les problèmes historiques de communication entre les délégués, le responsable du projet Debian et le reste du projet en élargissant la position de responsable du projet Debian. Cependant j'ai quelques inquiétudes sur les mécanismes engagés. Le rôle du responsable du projet est de s'assurer que la bonne personne fait le bon travail, pas de s'occuper de ce travail lui-même. Andreas dit :

des tâches plus petites sont déléguées au membre de l'équipe le plus approprié.

Au lieu de cela, je dirais que ces tâches devraient être déléguées au membre du projet le plus approprié. Désigner des délégués à l'avance de cette façon fait courir le risque de réduire la capacité du responsable du projet à choisir la personne la plus appropriée pour ce travail en rendant plus difficile la justification du choix de délégués supplémentaires.

Plutôt que de nommer une équipe à l'avance, je choisirai les délégués en fonction des besoins comme décrit dans la constitution. Restreindre mon choix à l'avance ne semble pas être la façon la meilleure de résoudre les problèmes lorsqu'ils surviennent.

Comme je l'ai souligné dans mon programme, mes priorités sont d'améliorer la communication et le consensus à l'intérieur du projet. Je ne crois pas que fournir plus de pouvoir à un petit ensemble de personnes soit la manière la meilleure pour résoudre ces problèmes. Le pouvoir devrait être distribué à travers tout le projet, pas concentré sur un petit sous-ensemble.