Programme d'Anthony Towns

Introduction

Bonjour ! Voici mon programme !

Mes notes m'indiquent que je devrais garder cela simple, aussi vais-je juste énumérer quelques thèmes généraux pour l'année prochaine et les choses spécifiques sur lesquelles j'avais pensé travailler pendant cette année qui vient. J'ai également inclus un résumé des choses qui se sont produites pendant mon mandat de responsable du projet Debian cette année.

Hors de Debian, je suis assez impliqué dans l'équipe de Linux Australie, et cette année je suis également impliqué dans la planification de la conférence des développeurs de code source ouvert 2007. Globalement, je trouve cela plutôt en symbiose avec mon implication dans Debian qu'en concurrence en matière de charge de travail, mais avec mes projets d'étudier sérieusement les logiciels libres de comptabilité l'année prochaine, je m'attends à devoir faire plus attention à la répartition de mon temps que je ne l'ai fait cette année.

À cet effet, si je suis réélu, j'étendrai le concept 2IC pour obtenir un certain nombre d'assistants responsables qui auront chacun leurs propres projets et l'autorité pour les implanter, et qui pourront répondre aux demandes d'entrevue et autres, afin de répartir la charge de travail. J'espère que certains des autres candidats seront disposés à considérer ce rôle si je suis réélu, et de même je serais heureux de me porter candidat pour un tel rôle si je ne suis pas responsable du projet Debian. Dans le meilleur des cas, j'espère que certains des autres candidats pourront réaliser certains de leurs projets aussi bien avec ce genre de fonction, et qu'ils en tireront en même temps une introduction plus douce au rôle de responsable du projet Debian que nous n'en avons habituellement. De manière idéale, je voudrais encore concourir l'année prochaine contre trois ou quatre coresponsables du projet Debian avec lesquels j'aurai travaillé cette année, perdre face à l'un d'entre eux, et qu'il nous invite tous de nouveau à travailler ensemble en 2008, sous sa direction.

J'ai un blog, et mes programmes de 2005et de 2006 sont également disponibles.

Revue du responsable du projet Debian – avril 2006 à février 2007

Mes buts pour l'année dernière étaient vitalité, recrutement et orientation. En ce qui concerne la vitalité, je pense que l'année dernière s'est assez bien passée. Il y a eu beaucoup de choses intéressantes qui se sont poursuivies, qui se sont passées et qui ont progressé, et même les principales disputes que nous avons eu ont au moins été au sujet de nouvelles choses, plutôt qu'encore une répétition des mêmes vieilles discussions.

Notre recrutement n'a pas été aussi réussi que je l'aurais souhaité — c'est toujours un processus important pour ajouter de nouveaux développeurs, et il n'y a toujours pas assez de place pour les personnes qui veulent contribuer mais ne peuvent pas s'engager à devenir un développeur complet. Nous avons eu un certain succès en travaillant avec d'autres organismes, à la fois par SPI et directement, mais je pense que nous pourrions faire beaucoup mieux sur ce point également.

Nous avons eu un peu de succès en réfléchissant à la direction que devait prendre Debian hors des seules élections du responsable du projet – bien que pour en apporter la preuve il y ait eu un vote de révocation du responsable du projet Debian, ce n'est peut-être pas un succès dont je devrais me vanter... :)

Quoi qu'il en soit voici une idée brute de ce qui a occupé mon attention au sujet de Debian l'année dernière, pour ce qui en vaut la peine :

Ce n'est pas tout à fait complet, et plusieurs de ces items ne se sont pas limités à un seul mois de travail, mais c'est probablement utile pour avoir une idée de ce qui a été réalisé. Évidemment il y a eu beaucoup de choses qui se sont produites et qui ne m'ont pas impliqué de quelque façon que ce soit !

Quoi qu'il en soit, voici pour les thèmes de cette année.

Technologie

La chose la plus importante au sujet de Debian est sa technologie – les idées ingénieuses que nous avons mises en œuvre pour mieux faire marcher les choses. Que ce soient les logiciels que nous avons écrit pour mieux faire fonctionner nos paquets, ou faire notre système d'empaquetage nous-mêmes, la modification de notre politique de licence et de celle des autres pour encourager une boucle de retour d'expérience positive des améliorations, les procédures et les chartes que nous avons publiées pour faciliter une maintenance des logiciels de haute qualité, ou les structures d'organisation que nous avons inventées pour nous permettre d'opérer en tant qu'organisation mondiale distribuée dans un monde qui s'attend à ce que nous soyons centralisés et isolés.

Bien sûr, la plupart des améliorations technologiques pour Debian ne font pas (et ne doivent pas faire) participer le responsable du projet. Il y a cependant un rôle que le responsable du projet Debian peut jouer – c'est en étant un exemple en travaillant constamment à ses propres améliorations techniques, et ainsi en encourageant les autres à faire de même.

J'ai fait beaucoup de choses techniques en 2005 – y compris travailler aux pdiffs pour apt, à l'amorçage inter-architecture, à un ensemble de débogages dont les étiquettes et les catégories utilisateurs, ainsi que les feuilles de style, à quelques améliorations mémoire pour britney, au soutien de l'équipe de sécurité de la distribution de test pour employer security.debian.org sans avoir besoin de privilèges vendor-sec, à certain travaux pour rendre les archives capables d'accepter l'architecture amd64 et à quelques autres choses.

Depuis que j'ai été élu, je n'ai presque pas fait de chose au niveau de la programmation ; il y a eu un certain nombre de choses pour garder l'architecture amd64 en bon état et aider l'équipe de publication, il y a eu le déménagement de ftp-master sur un nouveau serveur, et quelques autres mises à jour pour l'équipe de sécurité de la distribution de test qui commence à être utilisée. Je pense qu'une partie de ce que je fais à la place est technique au sens significatif, y compris travailler avec SPI pour le rendre plus efficace, impliquer Debian dans le camp d'été de codage de Google, travailler sur les licences de marque déposée, et aider des personnes à former des organismes et à lancer des événements au nom de Debian ; mais finalement Debian est une organisation de logiciel libre, et nous devons être plus visibles pour notre logiciel que pour ce qui est autour.

Donc personnellement, les travaux techniques sur lesquels je projette de travailler au cours des mois à venir sont jetring le nouvel outil de gestion de porte-clés de Joey Hess ; dak le kit d'archives de Debian pour lequel j'espère que nous obtiendrons quelques bonnes améliorations pendant le camp et la conférence Debian ; ainsi que la revue toujours attendue concernant la gestion des publications de dunc-tank.

En plus de cela, j'espère que nous pourrons mieux souligner notre travail technique l'année prochaine grâce à un certain nombre de choses, dont la publication d'Etch, la charte de développement pour Lenny, des essais et une intégration améliorés de l'assistance qualité, et tout autre travail qui doit être fait.

Communauté

La communauté est probablement le principal mot à la mode pour Linux Australie – nous essayons de maintenir nos activités concentrées sur des activités de la communauté, que ce soit la communauté d'utilisateurs ou la communauté de développeurs ou d'autre chose. Cela est une méthode vraiment efficace pour nous, pour nous assurer d'accueillir correctement de nouveaux membres, de continuer à fournir un retour d'expérience à nos membres, d'être accessibles à toute personne impliquée dans la communauté australienne de Linux, qu'elle soit membre ou pas, que nos activités sont centrées sur les bénéfices de la communauté, plutôt que sur des projets importants particuliers, et cætera.

J'ai essayé d'éviter de mettre la même emphase sur la communauté à l'intérieur de Debian, parce que je suspecte qu'un bon nombre de personnes pensent à ce mot comme n'étant rien d'autre qu'un mot à la mode ou une stratégie de vente ou encore une tentative de réduire au silence quiconque ne serait pas d'accord avec moi en ne se considérant pas comme faisant partie de la communauté. Mais il n'y a aucun moyen de l'éviter : Debian a une énorme et vibrante communauté, et même s'il y a des désaccords importants à travers toute cette communauté, c'est quand même une communauté – de développeurs, d'utilisateurs, de défenseurs, d'entreprises, de développeurs amonts, de dérivés, de concurrents et finalement de chaque personne travaillant sur Linux et le logiciel libre – qui rend Debian prospère. Enfin c'est quelque chose qui mérite d'être identifié, parce que le logiciel, comme la liberté, ne peut pas exister sans personne pour le créer ni le maintenir.

Je prévois donc de rester impliqué dans Software in the Public Interest et d'aider à le faire travailler avec d'autres organismes tels qu'OFTC, PostgreSQL et FreeDesktop.org pour construire et maintenir des liens avec ces organismes. SPI a fait un excellent travail pour se réorganiser récemment, et à mon avis, devrait véritablement devenir une ressource excellente pour les groupes de logiciels libres, en fournissant encore plus de soutien à ses projets existants, y compris Debian.

Une personne peut difficilement en faire autant, bien que, d'après quelques commentaires récents de Martin Michlmayr, je pense qu'il est également intéressant de nommer quelques développeurs en tant qu'ambassadeurs de Debian. L'idée est qu'ils seraient des gens qui promouvraient régulièrement Debian lors des conférences et des expositions, ou participeraient aux groupes d'industrie ou assisteraient à des rencontres de développement en tant que représentants de Debian, et Debian les soutiendrait en participant aux frais de déplacement ou en s'assurant qu'ils aient des CD et autres à distribuer. Je m'attendrais à ce que cela inclue le responsable du projet Debian et d'autres membres de l'équipe de direction, et en tant que tel cela autoriserait des remboursements de vols – quelque chose que je n'ai pas voulu faire pour moi-même cette année.

Comme je l'ai écrit l'année dernière, je pense que nous devons étendre notre communauté de développement pour permettre aux responsables qui sont actuellement parrainés de participer plus directement. J'espère que jetring s'avérera être la principale pièce manquante à cette proposition, mais nous verrons ce qui se produira.

En plus de cela, je pense qu'il est important de continuer à soutenir d'autres activités basées sur la communauté, telles que des conférences locales ou régionales de Debian, des réunions de travail, les forums officieux des utilisateurs de Debian, ou de nouvelles initiatives comme Debian-Community.org proposé par Holger Levsen.

À faire tout simplement

Au cours de l'année dernière, et à un moindre degré depuis déjà un bon moment, j'ai passé un certain temps à essayer d'expliquer aux gens qui se plaignent de la manière dont Debian fonctionne quelles sont (d'après mon expérience) les manières les plus efficaces de réaliser réellement les changements qu'ils souhaitent voir, et à les décourager d'essayer de communiquer leurs désirs de manières qui (à mon avis) causent plus de mal que de bien.

Autant que j'en ai vu, cela n'a eu aucun effet productif – finalement l'attention des développeurs est une ressource limitée et précieuse et il vaut mieux la dépenser à créer de bonnes choses et à travailler avec des personnes productives et utiles qu'à répéter les mêmes disputes avec les mêmes personnes.

Personnellement, je vois plein de choses qui ont besoin d'être améliorées dans Debian et je pense qu'il sera en fin de compte mieux de passer mon temps à travailler dessus, qu'à essayer de faire comprendre à chacun mes priorités. Il est fort probable que cela puisse ne pas marcher, et il est possible que je ne l'ai pas très bien expliqué – mais, et bien, c'est en gros mon idée. ;:)

Réfutation

Communication

Plus de communication est fréquemment proposée comme une solution à la plupart de nos problèmes, et cela a été une question importante dans un certain nombre d'élections passées de responsable du projet Debian – avec Martin critiquant Bdale pour un manque de communication en 2003, et faisant de cela un point important de son programme de réélection en 2004. De même, Branden a fait de la communication et de la transparence l'un des principaux sujets de son programme en 2003, 2004 et 2005. Cette année c'est une partie des programmes respectifs de Raphaël, de Steve, de Wouter, de Sam, et de Gustavo.

Le problème avec ceci est que communiquer est beaucoup plus dur qu'il n'y paraît – à la fois pour établir ce qui vaut la peine d'être dit, comment le décrire d'une manière que les gens peuvent comprendre, où et comment le dire, comment traiter les malentendus, les mauvaises interprétations ou simplement les désaccords, et pour laisser retomber l'énervement qui est normal lorsqu'on parle à toute sorte d'assistance, en particulier lorsqu'elle est large et souvent critique. Vous pouvez trouver beaucoup d'exemples de cette difficulté – que vous regardiez la performance des responsables du projet Debian au cours de ces dernières années pour maintenir chacun au courant de ce qui se passe, les gens promettant de mettre à jour leurs blogs plus régulièrement, ou la crainte infondée des personnes de prendre la parole en public.

Il n'y a simplement aucune solution facile pour faire que la communication se passe bien ; c'est un problème où vous devez constamment faire beaucoup de petits efforts et accumuler des améliorations croissantes.

Un secteur dans lequel le projet n'est pas très bon est la reconnaissance des efforts qui sont faits, et l'assurance que la critique est concentrée sur les domaines qui en méritent le plus.

Par exemple, l'année dernière, il y a eu huit annonces raisonnablement importantes concernant les annonces de sécurité de Debian, de Joey (nouvelles listes packages.d.o et backup.d.o), de James (temps d'arrêt et compromis), de Ryan (db.debian.org et wiki.debian.org), de Joerg (enchaînement sur db.debian.org) et de moi-même (délégation de travail sur les annonces de sécurité). En plus de cela, ils sont dans le processus de discuter du problème qu'ils rencontrent à utiliser le système de gestion des bogues pour suivre les problèmes en créant une instance temps réel (qui, au moment où j'écris, est toujours dépendante de la disponibilité de spohr.debian.org), ce qui devrait fournir une surveillance efficace des progrès de cette équipe, à la fois publiquement pour la plupart des questions, en interne et par le responsable du projet Debian pour les questions privées.

Cela ne signifie pas qu'il ne reste pas des améliorations à faire, ou qu'il n'y a pas d'autres personnes qui finissent par perdre du temps parce qu'ils n'arrivent pas à trouver ce qui ne va pas. Ce que cela montre, c'est qu'il y a de vraies actions qui sont entreprises par des gens qui sont critiqués continuellement pour leur manque de communication, et si nous voulons vraiment améliorer la communication et la transparence, la première chose que nous devons faire est de prendre l'habitude de reconnaître, d'apprécier et d'encourager finalement la communication dont nous disposons déjà.

Pour sympathiser

En tant que grand projet, un aspect important de notre succès est que soit en travaillant ensemble chacun de nous réalise plus que ce qu'il pourrait faire seul, soit nous nous marchons tellement sur les pieds que nous faisons moins ensemble que nous ne réaliserions seul.

C'est un défi à de nombreux niveaux – mais il y en a deux que je voudrais mentionner en particulier.

Équipes de direction

La première chose dans une équipe de direction : il y a un tas de manières qui ne fonctionnent pas pour rassembler une équipe, que ce soit un comité perdu dans des débats, une bureaucratie perdue dans des procédures, une hiérarchie où seuls les bénis oui-oui se font entendre, ou quoi que ce soit d'autre. Nous avons eu quelques exemples pratiques montrant que cela ne fonctionne pas mieux dans Debian – que vous considériez l'efficacité du comité technique ou du conseil de SPI il y a quelques années, ou la capacité de l'équipe du responsable du projet Debian en 2005 de travailler ensemble, ou les désaccords entre Andreas et Jeroen pendant la campagne 2006 de responsable du projet Debian, ou entre Andreas et Raphaël en 2006 ou Raphaël et Sam cette année. Aucun d'eux n'est nécessairement un briseur d'élan, mais faire travailler une équipe est autant une question de trouver des moyens d'éviter ce genre de tensions et de s'assurer que votre temps passé ensemble est utile et agréable que de trouver des choses à faire et de les faire réellement.

Il n'y a absolument rien de facile à ce sujet, et ce n'est certainement pas quelque chose pour laquelle je vais prétendre avoir une réponse. La seule manière de la traiter que je connaisse est de l'identifier comme un problème et d'être préparé à la contourner si vous trouvez qu'une équipe n'arrive pas à travailler correctement. Que Steve et moi soyons parvenus à aller plus ou moins dans la même direction la majeure partie de l'année était non seulement une question d'un gros effort et de coopération entre nous tout au long de l'année, mais également pour bonne part de la chance que nous nous soyons souvent avérés être d'accord tous les deux sur la manière dont les choses devaient se passer. Et si les choses s'étaient trouvées différemment et si nous n'avions pas pu travailler ensemble, pour quelque raison que ce soit, alors l'abandon de tout le concept 2IC était toujours sur la table : si travailler ensemble ne s'était pas avéré amusant, nous savions tous deux comment travailler à nouveau séparément. Je ne suis pas sûr que Raphaël dispose d'un plan de secours semblable si son équipe de responsable du projet Debian ne réussissait pas à travailler ensemble de la manière qu'il espère, et étant donné notre expérience jusqu'ici, je ne pense pas que la difficulté d'obtenir une bonne équipe doive être sous-estimée.

Amis et influence

Obliger des individus à travailler ensemble est un défi ; un autre est d'obliger des groupes à travailler ensemble. Par certains côtés cela a toujours été une partie de Debian – notre contrat social indique que nous travaillerons à la fois avec les développeurs amonts et d'autres groupes de logiciel libre, par exemple. D'un autre côté, c'est toujours une chose que nous avons trouvée difficile : soit en ne coopérant pas très bien avec les distributions dérivés, soit en nous disputant avec des développeurs amonts ou d'autres groupes de logiciels libres, ou en ne trouvant pas les moyens de travailler avec les entreprises qui utilisent Debian.

C'est quelque chose que j'ai essayé de faire ces dernières années, soit en travaillant avec Sun sur leurs paquets non libres de Java, soit en faisant participer Debian au camp d'été de codage de Google, ou en aidant les distributions dérivés à plus s'impliquer dans Debian, ou encore en travaillant avec SPI, ou en promouvant généralement l'idée que d'autres projets peuvent et devraient travailler avec Debian.

Je pense qu'il y a deux raisons que je soulève ceci. La première est le commentaire dans le programme de Sam Ubuntu n'est « pas le Diable » que dans le sens de Google. Google et Ubuntu peuvent beaucoup contribuer à Debian, et bien plus, ils contribuent déjà beaucoup à Debian. Tandis qu'il est certainement juste d'être en désaccord avec la manière dont ils font des choses   tous deux ont des applications web significatives pour lesquelles ils ne publient pas le code source, par exemple ! – il est précieux de garder du respect sur ces désaccords, de sorte que nous puissions continuer à coopérer dans les domaines où nous sommes réellement d'accord. Demander, même occasionnellement ou pour plaisanter, qu'un autre groupe ne suive pas ses principes de manière la plus stricte est une excellente manière d'arrêter toutes ses contributions potentielles pour toujours avec l'éventualité de n'obtenir aucun gain pour nos utilisateurs ni le logiciel libre dans son ensemble.

La seconde raison qui découle de la première est que : je doute qu'il y ait jamais un temps où personne dans Debian ne dira quelque chose de pareil, soit en plaisantant soit avec le sérieux le plus complet, et pour les personnes qui ne sont pas fortement impliquées dans Debian, faire la différence entre une personne quelconque sur une liste montrant sa capacité à présenter son propre avis de la manière la plus courte possible, et la voix officielle du consensus établi de Debian peut être assez difficile. Et les listes et la politique de Debian peuvent être suffisamment difficiles et confuses que, plutôt que de poser la question, de chercher un peu plus, ou même de continuer à discuter, cela mettra souvent un terme à la discussion, et nous aurons encore perdu un contributeur et un collaborateur potentiel.

En fin de compte, je pense que c'est là que le concept de Wouter de ne pas chercher la polémique rencontre son plus grand problème – si nous voulons être activement impliqués dans la communauté du logiciel libre autant que possible, je pense qu'il est nécessaire que quelqu'un recherche ses désaccords et intervienne en tant que militant pour les non-initiés, simplement parce qu'ils ne sont pas assez familiers avec Debian pour discuter avec leurs mots propres, et que leurs idées ne devraient pas être écartées juste parce qu'elles semblent contredire la sagesse conventionnelle de Debian. Je pense que faire du responsable du projet Debian cette personne, au moins de temps en temps, est une manière utile pour le projet de montrer son appréciation des nouvelles idées et des nouveaux contributeurs.

Antiréfutation

J'ai décidé qu'elle était trop longue, ainsi l'ai-je postée sur debian-vote à la place.

Merci de m'avoir lu !