Programme de chef du projet DebianStefano Zacchiroli |
Version : 3.0
Autres formats :
HTML,
PDF.
Plus de renseignements sur mon site.
Je m'appelle Stefano Zacchiroli — surtout connu sous le pseudonyme Zack. J'exerce le rôle de chef du projet Debian pour l'année 2010-2011 et me présente pour renouveler ce mandat l'an prochain. Ce programme présente des renseignements personnels d'ordre général (section 1), décrit mes objectifs principaux en tant que chef du projet Debian (section 2) et met en valeur des projets plus spécifiques pour mon mandat (section 2.3).
1 Introduction
1.1 Qui suis-je
Je suis devenu développeur Debian (DD) en mars 2001, peu de temps après la mise en place du processus de nouveau responsable. Mon implication dans Debian s'est réalisée en deux périodes différentes. Je me suis d'abord exclusivement intéressé à mes paquets, sans porter attention à la communauté : pas d'IRC, ni d'inscription à -devel, etc. Puis, lors du LinuxTag 2004, j'ai découvert Debian en tant que communauté qui m'a fascinée, et j'ai augmenté petit à petit mon implication dans le projet. Mes activités les plus remarquables pendant ces années ont été :
- DPL : chef du projet Debian
-
J'exerce actuellement le rôle de chef du projet Debian depuis avril 2010.
Des comptes-rendus de mes activités en tant que chef du projet Debian sont
accessibles dans diverses incarnations des
brèves du chef de projet Debian
ainsi que sur mon blog. - PTS : système de suivi des paquets
- J'ai comaintenu le système de suivi des paquets (PTS) de 2006 à 2010, participant à la maintenance quotidienne ainsi qu'à des modifications plus significatives ; plus de précisions sont disponibles sur mon blog (mon intérêt initial dans le PTS est né de l'envie de rendre les champs Vcs-* populaires, ce qui m'a conduit à écrire debcheckout).
- QA : assurance qualité
- De façon plus générale, j'ai longtemps fait partie de l'équipe d'assurance qualité : j'aime penser au projet comme un tout et chercher de nouvelles solutions (par exemple UDD, expiration de droits des développeurs Debian portés disparus, etc.) aux problèmes persistants.
- OCaml
- Une prise en charge correcte du langage OCaml a été ma motivation pour rejoindre le projet. J'ai participé à la formation de l'équipe en charge d'OCaml où j'ai commencé en tant que débutant pour finir en tant que coordonnateur. L'équipe gère maintenant environ 150 paquets source avec des interdépendances incroyablement complexes, et des besoins de transition compliqués.
-
RCBW : bogues critiques pour la publication (
RC bug
) de la semaine - De septembre 2009 à avril 2010, j'ai participé à la correction d'un bogue critique pour la publication par jour en initiant les bogues critiques pour la publication de la semaine, consultez la page des bogues critiques pour la publication de la semaine pour les motivations et plus de précisions.
- AM : responsable de candidature
- J'ai rejoint le comité de nouveau responsable en 2009, en devenant responsable de candidature. J'ai été le mentor de cinq nouveaux responsables, qui sont tous devenus développeurs Debian.
- Empaquetage
- J'ai maintenu plusieurs douzaines de paquets pour Debian. En plus des paquets relatifs à OCaml, je suis fier de plusieurs contributions à devscripts, vim et python-debian.
Considérant la communauté comme la véritable force de Debian, j'ai régulièrement participé aux DebConf et, quand mon temps le permettait, à d'autres rencontres en personne comme des chasses aux bogues et des sprints.
Dans la vie, je suis chercheur en informatique, et travaille en tant que chercheur postdoctoral au laboratoire PPS et au centre de recherche IRILL. Ces deux lieux sont des repaires de développeurs Debian, où les pauses-café se transforment souvent en discussions passionnantes autour de Debian. Je travaille surtout sur le projet Mancoosi, où nous appliquons les méthodes formelles pour étudier les systèmes basés sur des composants comme les distributions libres. Le projet contribue régulièrement en retour sous la forme d'outils pour la communauté comme edos-distcheck, edos.debian.net et d'autres services d'assurance qualité utilisés quotidiennement par Debian et d'autres distributions.
1.2 Pourquoi je demande à être réélu
Mes motivations générales pour devenir chef du projet Debian sont bien expliquées dans mon programme de l'an passé. Elles sont toujours d'actualité et sont des raisons qui me motivent pour exercer en tant que chef du projet Debian une nouvelle année.
De plus, j'ai par expérience remarqué que le rôle de chef du projet Debian
est une tâche qui demande un temps de chauffe plutôt long.
Au début du mandat, il faut trouver l'équilibre entre de nombreuses
tâches, comme suivre l'activité de la communauté, décrire et communiquer
sur les allées et venues du chef du projet Debian, choisir quand
intervenir et quand rester en retrait, ainsi qu'apprendre à connaître et
se faire connaître d'un grand nombre de personnes extérieures
(représentants d'autres distributions et entreprises, organisations à
but non lucratif, avocats, administrations publiques, journalistes, etc.)
Ce temps de chauffe permet d'apprendre le
boulot
mais peut durer plusieurs mois.
Pour le prochain mandat, j'aimerais profiter de l'expérience accumulée pour
être plus efficace à aider la communauté Debian dès le premier jour.
Je demande aussi à être réélu parce que même si je suis content de plusieurs modifications survenues dans Debian l'an passé (pas grâce à moi, mais à bien plus de gens que je ne pourrais nommer ici), j'ai aussi accumulé plus de points à traiter en tant que chef du projet Debian qu'il n'est possible de gérer avant la fin de ce mandat.
2 Mes objectifs
Les tâches institutionnelles du chef du projet Debian traitent de situations qui sont en général inconnues a priori. Par conséquent, je présente mes objectifs comme suit.
-
Je commence par donner ma vision globale
des thèmes clefs de la
politique
Debian. C'est je crois la seule façon de donner une idée de comment je peux réagir face à des scénarios imprévisibles. - Ensuite je présente l'approche que j'ai l'intention de mettre en œuvre dans les tâches institutionnelles du chef de projet Debian.
- Enfin je présente quelques projets spécifiques que j'ai l'intention de poursuivre si je suis élu chef du projet Debian.
2.1 Vision
Le rôle de Debian
L'écosystème du logiciel libre est vaste et en expansion.
Toutes les distributions actives ici devraient être bien
au fait de leurs buts propres et caractères distinctifs.
Lors de ce présent mandat, j'ai communiqué sur le rôle de Debian
en remarquant que nous offrons un jeu plutôt rare, sinon unique,
de fonctionnalités parmi les principales distributions libres.
Ces fonctionnalités sont composées d'un mélange
d'aspects techniques et politiques
:
(1)
une attention particulière à la qualité des paquets, sans
distinction entre une première et une seconde classe de paquets ;
(2)
une culture forte du logiciel libre, qui refuse de proposer des
logiciels non libres par défaut aux utilisateurs et aux développeurs
de la distribution (dans l'infrastructure utilisée pour faire Debian) ;
(3)
une indépendance des intérêts commerciaux, sans aucune
entreprise ou entité qui pourrait prétendre entretenir Debian ;
et (4)
un modèle de prise de décision fondé sur un équilibre de
do-ocracy
et de démocratie, ce qui signifie qu'en faisant
(plutôt qu'en parlant), tout le monde peut avoir un impact sur Debian.
Je crois que ce qui précède fait de Debian une contributrice
plutôt unique et fondamentale au logiciel libre et j'ai
l'intention de continuer à présenter le projet de cette façon,
à la fois à la communauté Debian et aux acteurs extérieurs.
Pour plus de renseignements à ce sujet, vous pouvez consulter l'article Qui diable se soucie de Debian ?
sur mon site et ma présentation au FOSDEM 2011, qui porte le même nom.
Contribuer à Debian
L'an passé, j'ai fait campagne sur le thème de voies
d'accès plus progressives et gratifiantes à Debian.
Pendant l'année, nous avons franchi une étape significative
dans cette direction avec l'accueil de contributeurs non empaqueteurs dans notre projet.
Je suis convaincu qu'à long terme, cette modification s'avérera
plus importante que ce dont nous pouvons apprécier pour
l'instant ; elle a le potentiel de rendre la monoculture que nous
connaissons en culture extrêmement diversifiée dont nous avons
besoin pour être fidèles à notre vocation d'universalité.
Même si techniquement, les développeurs Debian non empaqueteurs ont déjà
existé, en votant cette modification, nous avons non seulement communiqué
au monde entier que Debian apprécie de la même façon toutes sortes de
contributions, mais nous avons aussi invité tous les contributeurs
potentiels à rejoindre notre do-ocracy
avec leurs contributions.
J'ai été ravi de réaliser que plusieurs
candidats ont déjà répondu à cette invitation.
De façon plus générale, nous devons faciliter les contributions à
Debian qui ne concernent pas l'empaquetage, comme la documentation,
le tri des bogues, les essais, les traductions, etc.
À propos de contributions possibles, j'ai toujours l'impression
que notre capacité à garder ou non un éventuel contributeur dépend
trop de la chance qu'il aura de parler à la bonne personne
.
Si c'est la règle, un tel scénario est sérieusement sous-optimal.
Une manière de faciliter les contributions est d'apprendre les trucs
des autres distributions qui, par exemple, ont depuis longtemps
décidé de présenter une documentation sur comment contribuer
en fonction du profil (consultez le bogue nº 608400).
Maintenance collaborative et NMU
J'ai été un enthousiaste des équipes et de la maintenance collaborative dès le début. Soyez certains que je n'ai pas changé d'avis à ce sujet depuis l'an dernier. En fait, je suis en train de devenir un peu plus radical et j'ai fait campagne pour encore plus de NMU (faits correctement !), comme expliqué dans les motivations de l'initiative des bogues critiques pour la publication de la semaine. Je crois que les NMU (faits correctement !) sont les meilleurs outils à notre disposition pour combattre l'inertie et contrer les effets négatifs de propriété du code à l'extrême. Nos conseils actuels pour les NMU sont en fait plutôt tolérants et permettent de protéger des responsables négligents ou non joignables, à condition de les placer dans les meilleures conditions pour pouvoir rattraper plus tard le travail réalisé dans le NMU. Je continuerai de promouvoir la pratique des NMU à chaque fois que ce sera nécessaire.
Minorités bruyantes
L'an passé j'ai fait campagne pour des sondages comme moyens de résolution de problèmes avec les minorités bruyantes sur les listes de diffusion Debian. Je crois toujours que les sondages peuvent être des outils éventuellement utiles, mais je n'ai pas vu le besoin de les utiliser l'an passé. À la place, plusieurs personnes — y compris moi — se sont insérées dans les discussions pertinentes pour faire remarquer que les commentaires non constructifs de la part de personnes qui ne sont pas en charge de parties spécifiques du projet sont inutiles conformément à notre constitution (consultez le bogue nº 610262).
Rencontres en personne
L'an passé j'ai aussi fait campagne pour des rencontres en personne. Je suis content de signaler que nous avons maintenant un processus informel et une documentation pour les sprints et qu'il y en a eu dix pendant mon mandat, et que deux de plus sont prévus avant sa fin.
Distributions dérivées
Nous avons plutôt bien travaillé avec les distributions dérivées
pendant l'année, avec des initiatives comme le secrétariat
des distributions dérivées et le recensement.
J'ai également représenté Debian lors de
plusieurs rencontres de distributions dérivées.
Sur place, j'ai fait la promotion d'un partenariat amont-aval qui n'est
plus composé par seulement deux acteurs (un en amont et un en aval),
mais plutôt par une longue chaîne de fournisseurs de logiciels où chaque
fournisseur a : des utilisateurs directs, des avantages par rapport à
l'amont, et agit comme une plate-forme pour plusieurs projets aval.
Afin de défendre les intérêts du logiciel libre — pour ceux qui comme nous s'en
préoccupent — chaque acteur devrait reconnaître ses projets amont et
s'efforcer de leur renvoyer (restituer
) les correctifs pour intégration.
Dans le cas particulier de Debian, nous devrions :
- être exemplaires dans nos pratiques de restitution, par exemple en suivant publiquement nos efforts à l'envoi de correctifs en amont ;
- faciliter autant que possible la restitution vers nous, par exemple en participant aux initiatives interdistributions et en réalisant des NMU pour les paquets où d'importants correctifs aval sont laissés sans attention dans le BTS.
Faire les deux renforcera nos requêtes de restitution aux distributions dérivées que nous ne devrions pas arrêter de présenter.
2.2 Interaction avec le projet
2.2.1 Être présent
Comme promis, j'ai fait de mon mieux pour être un chef du projet Debian présent sur les listes de diffusion, m'insérant dans les discussions quand je l'estimais nécessaire (pour résoudre un conflit, porter une discussion vers sa conclusion, surveiller le programme du projet, etc.) Je réitère par la présente mon intention de faire de même lors du prochain mandat.
2.2.2 Transparence
L'an passé, je me suis aussi engagé
à informer régulièrement de mes activités de chef du projet Debian.
Pendant le mandat, j'ai fini par mettre en place un programme spécifique pour
ce faire ; ça fonctionnait pour moi, et j'ai l'intention de recommencer.
Pour faire court, des notes quotidiennes prises à propos de mes activités
de chef du projet Debian sont mises à la disposition des développeurs
Debian sur une machine du projet, en général toutes les semaines.
Tous les mois, ces notes sont résumées dans des brèves
du chef de projet Debian
envoyées sur d-d-a.
Pour les choses plus formelles comme les délégations ou autres activités
dignes d'intérêt, des messages à part sont aussi envoyés sur d-d-a.
Le travail décrit précédemment prend du temps sur mes autres activités de chef du projet Debian. Quand j'ai été confronté au problème, j'ai préféré laisser tomber quelques tâches de chef du projet Debian et communiquer ou prendre des notes sur les autres, plutôt que l'inverse. J'ai l'intention de pratiquer de la même façon lors du prochain mandat.
2.2.3 Argent
Depuis l'an dernier nous avons une meilleure transparence de la gestion de l'argent (par exemple nous avons maintenant un index des organismes auxquels Debian fait confiance avec des liens vers leurs rapports), mais il reste encore beaucoup de chemin à parcourir pour rendre correctement des comptes à nos donateurs. Idéalement, nous devrions viser des rapports trimestriels pour nos finances, qui comprennent les actifs de tous les organismes auxquels Debian fait confiance et tous les échanges d'argent depuis le dernier rapport. Je me suis également rendu compte que pour le chef du projet Debian, faire face à la comptabilité de l’argent comptant est pénible, car une multitude d'organismes sont à surveiller en même temps. Basculer en comptabilité d’accroissement entre organisations est une fonctionnalité indispensable pour faciliter les prévisions de dépenses et les transitions d'un chef du projet Debian vers son successeur.
Des deux points de vue — rapports trimestriels et comptabilité d’accroissement — j'ai été informé de progrès de la part des commissaires aux comptes et je ferais de mon mieux pour les aider à tenir ces engagements.
2.3 Plans particuliers
2.3.1 Clarification des délégations
L'an dernier, j'ai aussi fait campagne pour la clarification des délégations. Il y a eu pas mal de progrès sur ce plan : toutes les délégations que j'ai faites et clarifiées ont des pages correspondantes sur https://wiki.debian.org/Teams/ qui contient des liens vers le texte de délégation en cours. Il reste d'autres délégations à clarifier et elles devraient être documentées correctement sur la page d'organisation de notre site web.
2.3.2 Équipes principales
L'an dernier, j'ai aussi fait campagne pour trouver de nouveaux participants pour les équipes principales afin qu'il y ait au moins trois membres et des assistants dans chacune (à ceci près que nous n'avons pas de définition précise de ce qu'est une équipe principale...) Il y a aussi eu des progrès sur ce plan et j'espère en voir plus avant la fin de ce mandat.
2.3.3 Entreprises
Lors de ce mandat, j'ai trop souvent entendu des petites et
moyennes entreprises se plaindre de l'expertise Debian, employant
souvent des développeurs Debian qui ne peuvent proposer Debian à
leurs clients pour des raisons (stupides) comme : l'application
(propriétaire) $truc n'est pas certifiée pour Debian
ou nous ne pouvons pas compter sur vous car vous êtes trop
petite, nous voulons un label assistance réseau
.
J'ai l'intention de chercher des moyens pour aider ces entreprises à se rencontrer et évaluer la possibilité d'unir leurs forces pour aborder certains de ces problèmes. Dans le même thème, j'aimerais examiner la possibilité — sans compromettre l'indépendance de Debian — d'inciter ces entreprises à contribuer à Debian encore plus qu'elles ne le font déjà.
2.3.4 Enquêtes auprès des utilisateurs
Nous tombons souvent sur des questions auxquelles nous ne
pouvons pas répondre nous-mêmes, comme par exemple est-ce que
les utilisateurs préféreraient une distribution plus fiable,
plus jolie, avec un suivi plus long, plus avant-gardiste...?
J'ai recueilli quelques-unes de ces questions le mois dernier et je
prévois de les synthétiser dans un sondage pour les utilisateurs Debian
à renouveler chaque année, comme bien d'autres projets de logiciels
libres le font pour rassembler des retours de leurs utilisateurs.
Des initiatives spontanées similaires ont été proposées par le passé, mais
elles ont été soit plutôt restreintes (par exemple sans coordination avec
les canaux de communication Debian officiels qui peuvent atteindre un large
public), soit mal adaptées pour une analyse complètement automatisée (et par
conséquent condamnées à l'échec lors de l'expansion de l'échantillon cible).
2.3.5 Communication et publicité
À mon humble avis, la communication du projet a fonctionné vraiment bien cette année, principalement grâce au travail des équipes en charge de la publicité et de la presse. Nous avons envoyé plus d'annonces en 2010 que lors des dernières années, nous avons commencé à utiliser un compte @debian sur identi.ca qui est plutôt suivi, et plusieurs flux RSS de nos nouvelles sont maintenant disponibles, sans parler de la réussite stupéfiante de l'équipe en charge du site web avec la nouvelle mise en page du site web de Debian lors de la publication de Squeeze.
Nous devons continuer dans ce sens et utiliser la communication sociale, lorsqu'elle est compatible avec nos principes du logiciel libre, pour entrer en contact avec notre public potentiel. Par exemple, il manque encore à Debian un blog officiel à utiliser comme canal de communication vers notre communauté dans des termes moins formels que les articles de presse. Dernièrement ce que nous avions qui y ressemblait le plus — http://news.debian.net — a été fermé. Du point de vue de la communication c'est dommage, puisque les autres canaux de communication à notre disposition ne permettent pas aux utilisateurs de commenter facilement l'actualité avec des outils tels que les commentaires ou les rétroliens. J'ai l'intention de m'efforcer à corriger cela et, plus généralement, rester impliqué dans l'équipe en charge de la publicité comme je l'ai été cette année.
2.3.6 Équipes locales
Debian manque d'un réseau structuré d'équipes
locales et groupes d'utilisateurs Debian.
Je me suis rendu compte de cela lors du présent mandat assez vite, dès que
des gens ont commencé à me poser des questions comme qui puis-je contacter
pour un événement à $ville ?
ou connaissez-vous des rencontres
régulières au sujet de Debian à $ville où nous pourrions venir ?
Nous avons quelques réponses à apporter, comme les listes de diffusion
debian-events-* et les équipes d'événements
récemment renouvelées, mais ça ne remplace pas un réseau d'équipes locales.
D'autres distributions ont mis en place de tels réseaux et leur expérience semble montrer qu'ils sont utiles non seulement comme points de contact locaux pour les événements, mais aussi comme cercles de départ pour aider les utilisateurs à devenir progressivement de plus en plus impliqués dans la distribution. Je pense que nous devrions envisager quelque chose d'analogue pour Debian. J'ai signalé l'idée de temps en temps aux communautés locales que j'ai rencontrées lors de présentations et le retour a été très favorable en général.
Informations supplémentaires
Temps consacré
Être chef du projet Debian est un défi ; pour réussir, le travail doit être pris au sérieux. Pendant la durée du mandat, je mettrai en pause mes autres engagements dans Debian, comme je l'ai fait lors du présent mandat : c'est un devoir envers les anciens collaborateurs et un compromis honnête pour éviter l'explosion.
Sur le même thème et dans un souci de transparence : certains candidats au poste de chef du projet Debian ont par le passé déclaré être capables d'être chef du projet Debian à plein temps. Je ne peux pas me le permettre. Je propose que tout mon temps Debian en tant que bénévole soit consacré au travail de chef du projet Debian. Heureusement, j'ai pour l'instant un patron très réceptif au logiciel libre qui a beaucoup soutenu mes activités de chef du projet Debian lors de ce mandat. J'ai pu profiter de la liberté de réorganiser mon agenda lors d'urgences ou de rallongement d'activités, comme les voyages pour des raisons liées à Debian.
Je peux compter sur des arrangements analogues pour les six premiers mois du mandat à venir. Pour les six mois restant, je ne sais pas encore, car je ne sais pas encore qui sera mon employeur à ce moment-là. Néanmoins, quelque soit le scénario d'emploi que je puisse imaginer au moment où j'écris ces mots, je suis convaincu de pouvoir trouver le temps nécessaire à mes engagements de chef du projet Debian. Si à un moment donné je me rends compte que ce n'est plus le cas, je démissionnerai immédiatement du poste de chef du projet Debian.
Comme la plupart d'entre nous, je suis en général disponible non seulement par courrier électronique, mais aussi sur IRC, par téléphone, etc.
Ce document a été converti du LATEX par HEVEA.