[RFR3] wml://vote/2009/platforms/zack.wml
Bonjour,
Le 24/11/2015 14:21, Baptiste Jammet a écrit :
> Bonjour,
> Dixit jean-pierre giraud, le 24/11/2015 :
>> Voici une version qui intègre les modifications de Philippe et Marc.
>> Mercie d'avance pour vos nouvelles relectures.
> Juste une espace manquante au début.
> Baptiste
Corrections et suggestions de Baptiste et de Jean-Paul presque toutes
appliquées. merci d'avance pour vos nouvelles relectures.
Amicalement,
jipege
#use wml::debian::template title="Programme de Stefano Zacchiroli" BARETITLE="true" NOHEADER="true"
#include "$(ENGLISHDIR)/vote/style.inc" #use wml::debian::translation-check translation="1.13" maintainer="Jean-Pierre Giraud"
{#style#:
<STYLE type="text/css">
.li-itemize{margin:1ex 0ex;}
.li-enumerate{margin:1ex 0ex;}
.dd-description{margin:0ex 0ex 1ex 4ex;}
.dt-description{margin:0ex;}
.toc{list-style:none;}
.thefootnotes{text-align:left;margin:0ex;}
.dt-thefootnotes{margin:0em;}
.dd-thefootnotes{margin:0em 0em 0em 2em;}
.footnoterule{margin:1em auto 1em 0px;width:50%;}
.caption{padding-left:2ex; padding-right:2ex; margin-left:auto; margin-right:auto}
.title{margin:2ex auto;text-align:center}
.center{text-align:center;margin-left:auto;margin-right:auto;}
.flushleft{text-align:left;margin-left:0ex;margin-right:auto;}
.flushright{text-align:right;margin-left:auto;margin-right:0ex;}
DIV TABLE{margin-left:inherit;margin-right:inherit;}
PRE{text-align:left;margin-left:0ex;margin-right:auto;}
BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left;}
TD P{margin:0px;}
.boxed{border:1px solid black}
.textboxed{border:1px solid black}
.vbar{border:none;width:2px;background-color:black;}
.hbar{border:none;height:2px;width:100%;background-color:black;}
.hfill{border:none;height:1px;width:200%;background-color:black;}
.vdisplay{border-collapse:separate;border-spacing:2px;width:auto; empty-cells:show; border:2px solid red;}
.vdcell{white-space:nowrap;padding:0px;width:auto; border:2px solid green;}
.display{border-collapse:separate;border-spacing:2px;width:auto; border:none;}
.dcell{white-space:nowrap;padding:0px;width:auto; border:none;}
.dcenter{margin:0ex auto;}
.vdcenter{border:solid #FF8000 2px; margin:0ex auto;}
.minipage{text-align:left; margin-left:0em; margin-right:auto;}
.marginpar{border:solid thin black; width:20%; text-align:left;}
.marginparleft{float:left; margin-left:0ex; margin-right:1ex;}
.marginparright{float:right; margin-left:1ex; margin-right:0ex;}
.theorem{text-align:left;margin:1ex auto 1ex 0ex;}
.part{margin:2ex auto;text-align:center}
.rfloat{float:right;}
body{font-family: sans-serif;
font-size: medium;
}
h1, h2, h3, h4{font-weight: normal;
}
h1{font-size: 140%;}
h2{font-size: 130%;
border-bottom: solid 1pt;
}
h3{font-size: 115%;}
h4{font-size: 105%;}
.paragraph{font-size: 105%;
font-weight: normal;
/* text-decoration: underline; */
}
.alphaenum ol{list-style-type: lower-alpha;
}
.mantra{border: solid;
border-width: 1px;
border-color: #aaa;
background: #eee;
margin: 2pt;
margin-left: 8%;
margin-right: 8%;
padding: 2pt;
}
.summary{border: solid;
border-width: 1px;
border-color: #aaa;
background: #eee;
margin: 2pt;
padding: 2pt;
}
a{text-decoration: none;}
a:hover{text-decoration: underline;}
.mini {font-size:.6em}
</STYLE>
:##}
<!--HEVEA command line is: /usr/bin/hevea -fix platform.tex -->
<!--CUT DEF section 1 --><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">Programme de chef du projet Debian</H1><H3 CLASS="titlerest">Stefano Zacchiroli<BR>
<A HREF="mailto:zack@debian.org";><TT>zack@debian.org</TT></A><BR>
<A HREF="http://upsilon.cc/~zack";><TT>http://upsilon.cc/~zack</TT></A></H3></TD></TR>
</TABLE>
<DIV CLASS="center">
version <TT>1.0</TT>
</DIV>
<p class="mini">[ Autres formats disponibles :
<A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.html";>.html</A>,
<A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.pdf";>.pdf</A>,
<A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.txt";>.txt</A>. ]</p>
<!--TOC section Executive summary-->
<H2 CLASS="section"><!--SEC ANCHOR -->Résumé</H2><!--SEC END -->
<P>
Salut, je m'appelle <A HREF="http://upsilon.cc/~zack";>Stefano Zacchiroli</A> â?? surtout
connu sous le pseudonyme <EM>Zack</EM> â?? et me présente pour devenir chef du projet Debian.
</P>
<DIV CLASS="summary">
Les <B>principaux points</B> de mon programme sont les suivants :
<UL CLASS="itemize"><LI CLASS="li-itemize"> <I>J'ai l'intention d'être un chef du projet </I><I><EM>présent</EM></I>
<I>, Ã la fois dans les discussions et en tant que responsable du programme du
projet.</I></LI><LI CLASS="li-itemize"><I>Je fournirai un flux régulier de
nouvelles de mes activités de chef du projet, à geler et envoyer </I>
<I><EM>tous les mois</EM></I><I> Ã
</I><I><TT>d-d-a</TT></I><I>.</I></LI>
<LI CLASS="li-itemize"><I>Pour sortir de l'impasse des minorités bruyantes,
j'appliquerai des mécanismes qui font émerger un </I><I><EM>consensus
approximatif</EM></I><I> s'il existe.</I></LI>
<LI CLASS="li-itemize"><I>J'agirai en faveur de voies d'accès à Debian plus </I><I><EM>progressives</EM></I><I> et
</I><I><EM>gratifiantes</EM></I><I>.</I></LI>
<LI CLASS="li-itemize"><I>Je me battrai contre </I><I><EM>l'excès d'appropriation des paquets</EM></I><I> s'il entre en conflit avec la qualité.</I></LI>
<LI CLASS="li-itemize"><I>Je ferai de mon mieux pour soutenir, avec de l'argent
et d'autres ressources, les rencontres de contributeurs.</I></LI></UL></DIV>
<P>Le reste de ce programme présente des renseignements personnels d'ordre général
(Section <A HREF="#sec:intro">1</A>), décrit les points précédents avec plus de précision
(Section <A HREF="#sec:goals">2</A>), et met en valeur des projets plus spécifiques pour mon
mandat (Section <A HREF="#sec:itches">2.3</A>).
</P>
<!--TOC section Introduction-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc1">1</A>Â Â Introduction</H2>
<!--SEC END -->
<P>
<A NAME="sec:intro"></A></P>
<!--TOC subsection Who am I-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc2">1.1</A>Â Â Qui suis-je</H3>
<!--SEC END -->
<P>
<A NAME="sec:aboutme"></A></P>
<P>
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 à <TT>-devel</TT>, etc. Puis, lors du LinuxTag 2004, j'ai
découvert Debian en tant que <EM>communauté</EM>, ce qui m'a fasciné, et j'ai
augmenté petit à petit mon implication dans le projet.
</P>
<P>
Sur le plan technique, mes activités les plus remarquables pendant ces années
ont été :
</P>
<DL CLASS="description">
<DT CLASS="dt-description"><B>PTS</B></DT>
<DD CLASS="dd-description">Système de suivi des paquets. J'ai comaintenu le
<A HREF="https://packages.qa.debian.org";>système de suivi des paquets (PTS)</A>
pendant les trois ou quatre dernières années, participant à la maintenance
quotidienne ainsi qu'Ã des
<A HREF="http://upsilon.cc/~zack/blog/posts/2008/11/PTS_SOAP_interface/";>modifications</A>
<A HREF="http://upsilon.cc/~zack/blog/posts/2008/08/improved_integration_among_PTS_and_Lintian/";>plus</A>
<A HREF="http://upsilon.cc/~zack/blog/posts/2008/01/pts_dehs_integration/";>significatives</A>. Plus de
précisions sont disponibles sur <A HREF="http://upsilon.cc/~zack/tags/qa/";>mon blog</A>.</DD>
<DT CLASS="dt-description"><B>Champs Vcs-*</B></DT>
<DD CLASS="dd-description"> J'ai
<A HREF="http://upsilon.cc/~zack/blog/posts/2006/09/xs-x-vcs-XXX/";>rendu</A>
<A HREF="http://upsilon.cc/~zack/blog/posts/2006/10/xs-vcs-XXX_almost_there/";>plus populaire</A>
la notion de champ VCS (Version Control System) dans <TT>debian/control</TT>,
et j'ai écrit
<A HREF="http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/";><TT>debcheckout</TT></A>.</DD>
<DT CLASS="dt-description"><B>QA</B></DT>
<DD CLASS="dd-description"> Assurance qualité� De façon plus générale, j'ai rejoint l'équipe
<A HREF="https://qa.debian.org/";>assurance qualité</A> parce que j'aime penser au
projet comme à un tout et chercher de nouvelles solutions (par exemple
<A HREF="https://wiki.debian.org/UltimateDebianDatabase";>UDD</A>) aux
problèmes persistants.</DD>
<DT CLASS="dt-description"><B>OCaml</B></DT>
<DD CLASS="dd-description"> Une prise en charge correcte du langage
<A HREF="http://caml.inria.fr";>OCaml</A> a été ma motivation pour
rejoindre le projet. J'ai participé à la formation de l'
<A HREF="https://wiki.debian.org/Teams/OCamlTaskForce";>équipe en charge d'OCaml
</A> où j'ai commencé en tant que débutant pour finir en tant que coordinateur.
L'équipe gère maintenant plus de
<A HREF="https://pkg-ocaml-maint.alioth.debian.org/debian-ocaml-status.html";>120Â paquets source</A>
avec des <A HREF="http://upsilon.cc/~zack/stuff/ocaml-debian-deps.pdf";>
interdépendances incroyablement complexes</A> et des besoins de
<A HREF="http://glondu.net/debian/ocaml_transition_monitor.html";>transition</A>
compliqués.</DD>
<DT CLASS="dt-description"><B>Empaquetage</B></DT>
<DD CLASS="dd-description">�videmment, j'ai maintenu (et continue à maintenir)
<A HREF="https://qa.debian.org/developer.php?login=zack@debian.org";>plusieurs
paquets</A>. En plus des paquets relatifs à OCaml, je suis fier de plusieurs
contributions Ã
<A HREF="https://packages.debian.org/sid/devscripts";><TT>devscripts</TT></A>,
<A HREF="https://packages.debian.org/sid/vim";><TT>vim</TT></A> (en dépit de
ma récente
<A HREF="http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/";>trahison</A>
<TT>:-)</TT>, et
<A HREF="https://packages.debian.org/sid/python-debian";><TT>python-debian</TT></A>.</DD></DL>
<P>
Considérant la communauté comme la véritable force de Debian, j'ai régulièrement
participé aux <A HREF="https://www.debconf.org/";>DebConf</A> et, quand
mon temps le permettait, Ã d'autres rencontres comme les
<A HREF="https://wiki.debian.org/DebianQAExtremadura2008?action=fullsearch&context=180&value=debian+extremadura&titlesearch=Titles";>rencontres de travail d'Estrémadure
</A>.</P>
<P>
Dans la vie, je suis <A HREF="http://upsilon.cc/~zack/research/";>chercheur
en informatique</A>, et travaille actuellement en tant que chercheur postdoctoral
au laboratoire <A HREF="http://www.pps.jussieu.fr";>PPS</A> Ã
l'<A HREF="http://www.univ-paris-diderot.fr";>Université Paris
Diderot</A>. Ce laboratoire ressemble à un repaire de contributeurs Debian
de la communauté française de Debian ; nos pauses-café se transforment souvent
en discussions passionnantes autour de Debian. Je travaille surtout sur le
projet <A HREF="http://www.mancoosi.org";>Mancoosi</A>, où nous appliquons des
techniques telles que les méthodes formelles pour étudier les distributions
libres, y compris â?? mais pas seulement â?? Debian, et pour améliorer les
algorithmes de planification de mise à niveau. Mancoosi est le
successeur de <A HREF="http://www.edos-project.org";>EDOS</A>, qui était la
source de divers utilitaires d'assurance qualité de Debian, comme
<A HREF="https://packages.debian.org/sid/edos-debcheck";><TT>edos-debcheck</TT></A>,
exécuté régulièrement sur
<A HREF="http://edos.debian.net";><TT>edos.debian.net</TT></A>.
</P>
<!--TOC subsection Why I am running for DPL-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc3">1.2</A>  Pourquoi je me présente au poste de chef du projet</H3><!--SEC END -->
<P>
<A NAME="sec:whyrunning"></A></P>
<P>
�tre chef du projet présente deux facettes différentes : un rôle
institutionnel et une série d'objectifs supplémentaires que le
futur chef de projet a l'intention d'atteindre pendant le mandat. Cette
distinction a du sens.
</P>
<P>
Le rôle institutionnel est <A HREF="$(DEVEL)/constitution#5">décrit dans notre
constitution</A> et concerne trois tâches : les prises de décisions ordinaires
et extraordinaires, les relations publiques avec le monde extérieur et
l'aiguillage des discussions au sein du projet.
</P>
<P>
Mon point de vue sur les raisons qui nous incitent à avoir un chef du projet
est basé sur le fait que nous fonctionnons comme une <q>do-ocracy</q> :
n'importe qui ayant l'intention de faire quelque chose peut décider de la façon
de le faire et personne ne peut être obligé de faire quoi que ce soit. �tant
donné notre nombre, nous avons une tendance irrésistible aux modifications
pour devenir une <q>do-ocracy imparfaite</q>Â :
</P>
<DIV CLASS="alphaenum">
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
des restrictions d'accès sont ajoutées pour empêcher les gens de réaliser des
actions potentiellement dangereuses ;
</LI>
<LI CLASS="li-enumerate">
les tâches peu passionnantes risquent de moisir parce que personne n'est motivé
pour s'en charger ;
</LI>
<LI CLASS="li-enumerate">
ceux qui obtiennent certains postes pourraient négliger leurs autres
devoirs et diminuer la qualité du service qu'ils offrent, parce qu'ils
n'admettent pas de ne plus être aptes pour ces tâches.
</LI>
</OL>
</DIV>
<P>
Le chef du projet a le devoir, pour <EM>un temps limité</EM>, d'atténuer les
imperfections de notre <q>do-ocracy</q>Â :
</P>
<DIV CLASS="alphaenum">
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
remarquer les restrictions d'accès trop contraignantes qui empêchent les
gens capables de travailler, en induisant de l'inefficacité et des
frustrations ;
</LI>
<LI CLASS="li-enumerate">
trouver des gens volontaires pour les tâches peu passionnantes pour le
bien général du projet (en s'assurant qu'on reconnaisse leur mérite) ;
</LI>
<LI CLASS="li-enumerate">
assigner des gens aux postes clefs pour améliorer la qualité du service
à l'intérieur et à l'extérieur du projet.
</LI>
</OL>
</DIV>
<P>
La récompense est l'opportunité de peser pour des améliorations Ã
l'échelle du projet par le seul mérite d'occuper le poste de chef du projet.
</P>
<P>
J'ai l'intention de relever le défi d'être un chef de projet transparent et
présent, et d'améliorer les mécanismes de notre projet. C'est pourquoi je me
présente au poste de chef du projet. (En fait, certains d'entre vous m'ont
<EM>demandé</EM> de me présenter, et donc la responsabilité de vous embêter Ã
lire tout ceci ne me revient pas entièrement <TT>:-)</TT>
</P>
<!--TOC section My goals-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc4">2</A>Â Â Mes objectifs</H2>
<!--SEC END -->
<P>
<A NAME="sec:goals"></A>
</P>
<P>
Les tâches institutionnelles du chef du projet Debian traitent de situations
qui sont en général inconnues <i>a priori</i>. Par conséquent, je présente mes
objectifs comme suit.
</P>
<UL CLASS="itemize">
<LI CLASS="li-itemize">
Je commence par donner ma <EM>vision</EM> globale des thèmes clefs de la
<q>politique</q> Debian. C'est, je crois, la seule façon de donner une idée
générale de la façon dont je peux réagir face à des scénarios imprévisibles.
</LI>
<LI CLASS="li-itemize">
Ensuite, je présente l'<EM>approche</EM> que j'ai l'intention de mettre en Å?uvre
dans les tâches institutionnelles du chef de projet Debian.
</LI>
</UL>
<!--TOC subsection Vision-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc5">2.1</A>Â Â Vision</H3>
<!--SEC END -->
<P>
<A NAME="sec:vision"></A></P><!--TOC paragraph Non-DD contributors-->
<H5 CLASS="paragraph"><!--SEC ANCHOR -->Contributeurs non empaqueteurs</H5>
<!--SEC END -->
<P>
L'introduction des <A HREF="https://wiki.debian.org/DebianMaintainer";>\
DM</A> (responsables Debian) a été un événement heureux pour Debian. Certaines
personnes critiquent le fait que cela a ouvert notre archive à des paquets de
qualité inférieure. Cela pourrait être vrai, mais nous avons aussi des (tas de)
paquets de qualité inférieure maintenus par des responsables à part entière
qui ont perdu l'intérêt qu'ils portaient à Debian. La solution aux deux problèmes est
<EM>plus d'assurance qualité</EM>.
</P>
<P>
Par l'intermédiaire du processus de DM, de nombreuses personnes enthousiastes
ont réussi à rejoindre Debian, augmentant notre force de travail. De plus, le
processus de DM a induit un <em>processus plus contrôlé</em> pour devenir
développeur Debian à part entière, avec une meilleure garantie d'engagement
sérieux dans Debian et un meilleur niveau d'expérience. Dans l'ensemble, le processus
de DM est une voie d'accès à Debian moins abrupte que celle qui existait
jusqu'alors, ce qui nous permet de rendre <EM>progressivement</EM> Ã nos
contributeurs une reconnaissance. Cela contribue à gommer l'aspect
<q>tout ou rien</q> de Debian et c'est une voie moins frustrante pour les
empaqueteurs qui auparavant étaient tentés de faire porter leurs efforts sur
d'autres projets.</P>
<P>
Nous devons tirer les leçons du processus de DM. Nous avons beaucoup de
précieux contributeurs potentiels autour de nous. Ils ont simplement besoin
d'une meilleure documentation sur la <em>façon</em> de nous rejoindre. Ils ont
juste besoin de quelque chose en échange, de quoi être fiers, qui reconnaisse
leurs efforts. Je n'ai pas d'idée préconçue sur les différents moyens de
réussir cela (par exemple des listes de contrôle d'accès par opposition aux
augmentations de droits linéaires), mais nous avons besoin d'aller dans cette
direction. Ce faisant, nous devrions relâcher notre hypothèse implicite que
<EM>seules</EM> les qualités techniques comptent dans Debian. Le véritable
<q>Système d'exploitation universel</q> est <EM>surtout</EM>, mais pas
seulement, fait de logiciels ; il est aussi fait de traductions,
d'illustrations, de musiques, etc.
</P>
<DIV CLASS="mantra">
<DIV CLASS="center"><I>J'agirai en faveur de voies d'accès à Debian plus
<EM>progressives</EM> et <EM>gratifiantes</EM>.
</I></DIV></DIV>
<!--TOC paragraph Collaborative maintenance-->
<H5 CLASS="paragraph"><!--SEC ANCHOR -->Maintenance collaborative</H5>
<!--SEC END -->
<P>
L'introduction du champ <TT>Uploaders</TT> est un autre exemple de
développement heureux au sein de Debian. Même si cela peut, en principe,
permettre de former des équipes de personnes sans responsabilité claire pour
certaines tâches, cela fonctionne très bien en général. Cela crée des espaces
techniques efficaces pour la collaboration sur des sujets particuliers et
cela s'adapte aussi pour (re)créer des structures organisationnelles avec une
position particulière et des partages de tâches.
</P>
<P>
La maintenance collaborative ne devrait pas être obligatoire (nous avons
plusieurs développeurs en solo très efficaces), mais devrait l'être par
défaut. Les débutants en empaquetage devraient commencer dans des équipes de
maintenance collaborative et y gagner en expérience. Les retours des membres
de l'équipe peuvent être alors utiles pour alléger la charge qui pèse sur les épaules des
responsables de candidature (Application Managers â?? AM). De même, nous ne devrions pas accepter la
maintenance en solo lorsque cela entraîne des paquets qui, de fait, ne sont pas
maintenus (Ã identifier convenablement d'un point de vue de
<A HREF="https://wiki.debian.org/qa.debian.org/bapase";>l'assurance qualité</A>).
Dans ces cas, nous devrions suggérer â?? ou même forcer si besoin â?? la
maintenance collaborative. Cela peut offrir une porte de sortie plus acceptable
qu'une humiliation publique et inutile.
</P>
<DIV CLASS="mantra">
<DIV CLASS="center"><I>Je me battrai </I><I><EM>contre l'excès d'appropriation
des paquets</EM></I><I> s'il entre en conflit avec la qualité.
</I></DIV></DIV>
<!--TOC paragraph Vocal minorities-->
<H5 CLASS="paragraph"><!--SEC ANCHOR -->Minorités bruyantes</H5>
<!--SEC END -->
<P>
Nos listes de diffusion se sont sensiblement améliorées ces cinq dernières années.
De temps en temps, cependant, elles sont polluées par des minorités
(apparemment) très bruyantes capables de polariser les débats, ce qui n'est
ni productif, ni agréable. Vu comme nous sommes attachés à notre communauté,
nous devons parfois prendre part à des discussions comme celles-là , qui
explosent inévitablement (combien de messages de vacances temporaires â?? avec
l'étiquette VAC â?? avons-nous à cause de cela ? Trop). Mon point de vue est
le suivant :
</P>
<BLOCKQUOTE CLASS="quote">
<p>
<I>Liberté d'expression : d'accord.<BR>
Prise d'otage de la majorité silencieuse par des minorités bruyantes : pas
d'accord.</I>
</p>
</BLOCKQUOTE>
<P>
Bien que nous devions envisager â?? et l'avons déjà appliqué par le passé â??
des mesures de modération à l'encontre des comportements portant préjudice
de façon répétée à la communauté, nous ne pouvons pas prendre le risque de
les appliquer seulement dans l'<em>hypothèse</em> où les expéditeurs feraient
vraiment partie d'une minorité bruyante.
Même en absence de solution optimale pour ce genre de problème, les artifices
techniques peuvent aider. Un de ces artifices que j'aimerais utiliser est le
<A HREF="http://master.debian.org/~jeroen/polls/";>sondage</A>, comme cela a
été proposé par Jeroen van Wolffelaar et d'autres il y a des années. Le but
est de permettre à tous les développeurs Debian de lancer un sondage avec
authentification <EM>à la</EM> <TT>devotee</TT> â?? <q>DEbian VOTe EnginE</q>.
</P>
<P>
Les sondages permettent d'obtenir un point de vue raisonnable de l'avis de la
communauté, sans avoir à lancer la grosse machinerie d'une résolution générale.
Un sondage peut soit permettre clairement aux participants d'une discussion
(ou d'une foire d'empoigne) de se rendre compte qu'ils sont en désaccord
avec le reste du projet et qu'ils feraient mieux d'arrêter d'enfoncer
des portes ouvertes, soit d'indiquer qu'ils sont sur la bonne voie.
</P>
<DIV CLASS="mantra">
<DIV CLASS="center"><I>Pour sortir de l'impasse des minorités bruyantes,
j'appliquerai des mécanismes qui font émerger un </I><I><EM>consensus
approximatif</EM></I><I> s'il existe.</I>
</DIV>
</DIV>
<!--TOC paragraph Face-to-face meetings-->
<H5 CLASS="paragraph"><!--SEC ANCHOR -->Rencontres en personne</H5><!--SEC END -->
<P>
Les rencontres sont nécessaires pour améliorer la qualité de la collaboration
au sein du projet, qu'importe l'efficacité dont nous faisons preuve dans la
communication numérique. Se rencontrer en personne, programmer pendant des
heures, faire des choses ensemble et rentrer chez soi. Le jour suivant, notre
collaboration à distance sera bien meilleure.
</P>
<P>
Permettre l'organisation de rencontres est un merveilleux moyen d'utiliser
l'argent de Debian et d'autre ressources, comme des gens spécialement nommés pour
cela. Heureusement que nous avons les <A HREF="http://www.debconf.org";>\
DebConf</A>, organisées par une équipe très efficace. Cependant la DebConf ne
devrait pas être le seul rassemblement, et nous devrions faire pression pour
mettre en place des rencontres locales, et utiliser nos ressources pour cela.
Je pense qu'il est tout à fait raisonnable de prendre en charge les voyages
des contributeurs actifs, si cela peut leur permettre de se joindre à d'autres
et de travailler à des objectifs précis.
</P>
<P>
Une façon simple de décider quand le faire ou ne pas le faire, au-delà de la
somme d'argent nécessaire, pourrait être le nombre d'autres développeurs qui le
demandent. Si et <em>quand</em> l'argent devient un problème, je ne vois rien
qui puisse nous empêcher d'organiser une campagne de dons spécifique.
</P>
<DIV CLASS="mantra">
<DIV CLASS="center"><I>Je ferai de mon mieux pour soutenir, avec de l'argent et
d'autres ressources, les rencontres de contributeurs.</I>
</DIV>
</DIV>
<!--TOC paragraph Derivatives-->
<H5 CLASS="paragraph"><!--SEC ANCHOR -->Distributions dérivées</H5><!--SEC END -->
<P>
Nous faisons partie d'un écosystème du logiciel libre, dans lequel les
correctifs circulent à la fois depuis l'amont et l'aval. Nous
<A HREF="$(HOME)/social_contract">avons promis</A> de donner nos travaux à la
communauté du logiciel libre, même si nous ne réussissons pas toujours à le faire.
Des initiatives, comme le récent
<A HREF="http://patch-tracking.debian.net";>suivi de correctifs</A> organisé par
Sean Finney, nous permettent de rendre visibles nos modifications à la fois en
amont et en aval.
</P>
<P>
Nos distributions dérivées nous ont comme développeurs amont, et sont dans une situation
semblable. Nous ne pouvons pas les <em>obliger</em> Ã nous donner quoi que ce
soit, car nos engagements ne sont pas forcément les leurs, mais nous devrions
tout de même :
</P>
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
être exemplaires dans nos pratiques de restitution, par exemple en suivant
publiquement nos efforts pour l'envoi de correctifs en amont ;
</LI>
<LI CLASS="li-enumerate">
faciliter autant que possible la restitution vers nous, par exemple en
participant aux initiatives interdistributions qui permettent aux mainteneurs
de se connaître et de partager leurs VCS.
</LI></OL>
<P>
Faire les deux renforcera nos <EM>requêtes</EM> de restitution aux
distributions dérivées que ne devraient pas connaître de répit.
</P>
<!--TOC subsection DPL <-> project interaction-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc6">2.2</A>Â Â Interaction chef du projet <-> projet</H3><!--SEC END -->
<P>
<A NAME="sec:dpl-project"></A></P><!--TOC subsubsection Being present-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc7">2.2.1</A>  �tre présent</H4><!--SEC END --><P>
<A NAME="sec:presence"></A></P><P>En tant que développeur Debian, j'ai souvent
souffert d'une <q>absence</q> apparente du chef de projet. Peut-être que cela
venait de moi, que je n'anticipais pas suffisamment au point de solliciter le
chef du projet sur IRC ou par courrier électronique et de demander, mais je
considère qu'il est du devoir du chef de projet de communiquer sa présence.
Cela se concrétise de deux façons : l'une est de <B>mener les débats</B> entre
les développeurs, conformément à ce qui est <A HREF="$(DEVEL)/constitution#5">\
prévu dans la constitution</A>, quelque chose que j'ai rarement vue. Même si
nous n'en voulons pas par défaut (pas besoin d'un chef de projet qui <q>écrit
dans tous les fils</q>), j'aimerais essayer d'être présent dans les discussions
<q>chaudes</q> (définition volontairement vague) qui concernent l'organisation
et le projet à grande échelle. J'encouragerai aussi la consultation du chef de
projet pour partager son avis sur certains sujets, en me sollicitant
explicitement.
</P>
<P>
L'avis du chef de projet peut aussi être une première tentative raisonnable de
résolution de conflit ; si cela échoue, nous avons d'autres mécanismes pour le
régler. � cet égard, je pense que mes qualités personnelles peuvent être
utiles au projet : je suis réfléchi, à l'écoute des autres et capable de
changer d'avis face à de bons arguments.</P>
<P>Plus généralement, gérer le <B>programme du projet</B> est quelque chose
que l'on devrait attendre du chef du projet. La gestion du programme signifie
avoir des objectifs sur les sujets que le projet devrait <EM>envisager</EM>
pendant un certain laps de temps. La page
<A HREF="https://wiki.debian.org/DiscussionsAfterLenny";>DiscussionsAfterLenny</A>
est un exemple de ce besoin. Le chef de projet devrait s'assurer que le projet
a des programmes de ce genre, pour éviter d'oublier des points importants pour
ne s'en rappeler que plus tard au moment, par exemple, de la publication.
</P>
<P>
La gestion signifie aussi garder une trace de ce qui s'est passé. La <A
HREF="http://dep.debian.net/deps/dep0/";>proposition de DEP</A> (Debian Enhancement Proposal) â?? que j'ai
initiée avec <A HREF="http://chistera.yi.org/~adeodato/blog/";>Adeodato Simó</A>,
et <A HREF="http://liw.iki.fi/liw/";>Lars Wirzenius</A> â?? était une tentative de
fournir un outil pour y arriver : aucune grande charge de travail
supplémentaire n'a été introduite, juste une organisation du travail pour se
rappeler l'état des propositions de modification du projet à <q>grande</q>
échelle.
</P>
<P>
On pourrait s'attendre à ce que le chef du projet s'occupe des DEP
<q>abandonnées</q> en les réassignant, les fermant ou les pilotant lui-même.
Les DEP n'ont pas pu décoller à cause de l'absence de quelques procédés techniques
et d'exemples représentatifs. Je m'assurerai que nous donnerons une chance aux
DEP, ou à des artifices du même genre, pour vérifier si nous pouvons enfin avoir
un choix raisonnable entre des décisions très formelles de type résolution générale et des
décisions un peu folkloriques qui trop souvent ressemblent plus à pas de
décision du tout.
</P>
<DIV CLASS="mantra">
<DIV CLASS="center"><I>J'ai l'intention d'être un chef du projet </I><I>
<EM>présent</EM></I><I>, à la fois
dans les discussions et en tant que responsable du programme du projet.</I>
</DIV>
</DIV>
<!--TOC subsubsection Transparency-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc8">2.2.2</A>Â Â Transparence</H4><!--SEC END -->
<P>
<A NAME="sec:transparency"></A></P>
<P>
Une autre façon d'être présent pour le chef de projet est de publier
<EM>régulièrement</EM> ce qu'elle ou il est en train de faire ; appelons ça
la <q>transparence</q>. Nous nous sommes améliorés récemment, mais seulement
quatre ou cinq messages de <q>brèves de ...</q> pendant un mandat de chef du
projet sont encore trop peu pour un rôle qui est censé représenter un projet
aussi gros et varié.
</P>
<P>
Je suis sûr qu'un certain nombre d'activités du chef de projet ne sont pas
destinées à être publiées, qu'elles soient d'ordre personnel pour certaines,
totalement inintéressantes pour d'autres, ou encore qu'elles ne soient pas sensées
être archivées sur Internet pour toujours. Je sais aussi qu'écrire en partant de
rien des <q>brèves du chef de projet</q> peut demander beaucoup de
temps et éventuellement être intimidant.
</P>
<P>
La solution que je mettrai en place est d'avoir constamment un <b>flux de
nouvelles des activités du chef de projet</b>. <q>Flux</q> est un concept,
la mise en Å?uvre peut varier : un canal IRC, un blog ou microblog, une page
de wiki <TT>BitsFromTheDPL</TT> traitée <EM>à la</EM> <A
HREF="https://wiki.debian.org/DeveloperNews";><TT>DeveloperNews</TT></A>, des
envois à <TT>-private</TT> pour les données sensibles, etc. L'absence de flux
d'activités signifiera l'absence d'activité de chef du projet et le droit de
se plaindre pour les développeurs Debian et de demander des comptes. Je pense
que les activités qui ne sont pas encore prêtes à être dévoilées <EM>du tout</EM>,
pas même en censurant ou en reformulant les précisions, sont suffisamment rares
pour ne <em>pas</em> provoquer l'absence de flux.
</P>
<P>
Le flux résultant sera alors figé tous les mois et envoyé à <TT>d-d-a</TT>.
Si j'échoue deux fois à envoyer ces nouvelles, j'admettrai mon échec et en
expliquerai les raisons en demandant des avis pour trouver des moyens pour la
poursuite du mandat (par exemple, avec un vote, qui devra contenir aussi l'option
<q>démissionnez, vous ne communiquez pas assez</q>).
</P>
<DIV CLASS="mantra">
<DIV CLASS="center"><I>Je fournirai un flux régulier de nouvelles de mes
activités de chef du projet, à figer et envoyer </I><I><EM>tous les mois</EM></I>
<I> Ã </I><I><TT>d-d-a</TT></I><I>.
</I>
</DIV>
</DIV><!--TOC subsubsection (no) DPL board-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc9">2.2.3</A>  (Pas d')équipe de direction du projet Debian</H4><!--SEC END -->
<P>
<A NAME="sec:dpl-board"></A></P>
<P>
D'après les chefs du projet précédents, supporter les charges de chef de projet
tout seul <EM>est</EM> décourageant. Pour contrer cela, je serai toujours à la
recherche de conseils auprès des autres en fonction de leur domaine d'expertise
dans le projet. Je ne crois pas néanmoins en l'utilité d'une <b>équipe de
direction du projet</b>Â : le mandat du chef du projet est trop court pour
consacrer du temps à des réunions de coordinations supplémentire, donc je n'en
aurai pas. Pour les affectations de tâches plus spécifiques, nous avons les
délégations qui sont bien plus que suffisantes.
</P>
<P>
Cependant, la vie étant ce qu'elle est, le chef du projet Debian est, pour cette
raison, un point unique de défaillance et je rechercherai un <B>2IC</B> (second
in charge, vice-leader). Les missions du 2IC seront : assistance du chef du
projet (en cas d'absence imprévue) et aide à la communication extérieure ou
interne au projet (par exemple pour le fil de nouvelles). Le 2IC sera désigné par
une délégation ordinaire, à durée limitée. En tant que chef du projet, je prendrai
l'entière responsabilité des actes du 2IC.</P><DIV CLASS="mantra">
<DIV CLASS="center"><I>Je n'aurai pas d'équipe de direction du projet ; je chercherai
plutôt un 2IC comme assistant et pour la communication.</I>
</DIV>
</DIV>
<!--TOC subsection Specific plans-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc10">2.3</A>Â Â Projets particuliers</H3><!--SEC END -->
<P>
<A NAME="sec:itches"></A>
</P>
<!--TOC subsubsection Clarify delegates-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc11">2.3.1</A>  Clarification des délégations</H4><!--SEC END -->
<P>
<A NAME="sec:delegates"></A>
</P>
<P>Rappelez-vous : il n'y a pas de cabale. Bien. Alors :
</P>
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
tous les <A HREF="$(DEVEL)/constitution#8">délégués</A> actuels devraient
être clairement identifiés sur <A HREF="$(INTRO)/organization">notre page
d'organisation</A> avec une référence au message de délégation ;
</LI>
<LI CLASS="li-enumerate">
tous les membres des équipes principales qui étaient en place avant la
généralisation des délégations devraient être officiellement délégués. Cela
éviterait les disparités entre les <q>nouveaux</q> membres d'équipe qui sont
délégués et les <q>anciens</q> membres d'équipe qui sont toujours dans une
situation peu claire.
</LI>
</OL>
<!--TOC subsubsection The website issue-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc12">2.3.2</A>Â Â La question du site web</H4><!--SEC END -->
<P>
<A NAME="sec:website"></A>
</P>
<P>
Nous voulons tous un
<A HREF="$(VOTE)/2007/platforms/sho">site web plus attirant</A>, c'est-Ã -dire
un site web où les gens peuvent trouver ce qu'ils cherchent et qui ne donne
pas de nous l'image d'un système d'exploitation des années 80. Même si du travail
<A HREF="https://wiki.debian.org/DebianWebsiteDiscussion";>a déjà été fait</A> sur ce
problème au sein de l'équipe en charge du site, aucune amélioration visible
n'a encore été faite.
</P>
<P>
J'ai l'intention d'aider l'équipe en charge du site à résoudre les problèmes
principaux pendant le mandat. Même s'il est inutile de définir précisément
les objectifs techniques dans un programme, mon plan d'action sera le
suivant. Toutes les étapes sont supposées être réalisées
en accord avec l'équipe en charge du site.
</P>
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
�tablir les exigences minimales pour un site amélioré en matière d'accessibilité,
de structure du site et d'organisation du travail. Rendre ces
exigences <EM>publiques</EM> avec un plan détaillé du travail à accomplir pour
y parvenir : nous ne dissimulerons pas les problèmes.
</LI>
<LI CLASS="li-enumerate">
Envoyer un appel à l'aide dans notre communauté, à la recherche de volontaires
pour se charger du travail et le livrer dans un intervalle de temps donné
(oui, je sais que nous sommes tous volontaires, mais nous assumons nos
responsabilités et respectons des délais, ce problème est suffisamment
important pour le demander).
<SUP><A NAME="text1" HREF="#note1">1</A></SUP>
</LI>
<LI CLASS="li-enumerate">
S'assurer que les preneurs, s'il y en a, ont accès aux ressources nécessaires,
qu'ils soient correctement remerciés pour leur tentative et, espérons-le, leur
réussite.
</LI>
</OL>
<P>
Si tout cela échoue, nous déclencherons un plan d'urgence. Par exemple, nous
pouvons envisager de rechercher de l'aide extérieure (c'est-à -dire si personne
engagé dans Debian ne veut s'en occuper) pour se rendre compte de ce qui
manque, sous le contrôle de l'équipe en charge du site web. Nous achetons
régulièrement des services que nous ne pouvons pas réaliser nous-mêmes, le site
web ne devrait pas faire de différence.
</P>
<!--TOC subsubsection Core teams-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc13">2.3.3</A>Â Â Ã?quipes principales</H4><!--SEC END -->
<P>
<A NAME="sec:core-teams"></A>
</P>
<P>
Nos équipes principales se sont beaucoup améliorées récemment, à la fois en
matière de main-d'Å?uvre et de communication. Félicitations pour ces
améliorations à Steve McIntyre et Sam Hocevar (les deux précédents chefs de
projet) et bien sûr aux équipes elles-mêmes. Néanmoins, certaines équipes sont
encore un peu limite, ou tout du moins c'est ce qu'il semble vu de l'extérieur.
Ajouter des membres à une équipe la rend plus tolérante aux absences et permet
aussi de préparer la génération suivante de contributeurs. La distinction entre
assistant et membre dans plusieurs équipes semble fonctionner
vraiment bien pour cela.
</P>
<P>
Mon intention naïve serait d'amener toutes les équipes principales à au moins
trois membres et les pousser à faire campagne pour avoir des assistants quand
aucune procédure bien établie n'existe pour rejoindre l'équipe. Aussi, en
regardant notre <A HREF="$(INTRO)/organization">page
d'organisation</A>, il semble que plusieurs équipes sont soit inactives, soit
très mauvaises pour communiquer sur ce qu'elles font.
Pour leur propre bien, les personnes impliquées devraient être incitées à se
faire remplacer et à travailler sur quelque chose qui leur ferait plus
plaisir.
</P>
<P>
Toutes ces modifications devraient cependant être d'abord essayées avec
l'accord de l'équipe, pour ne pas embêter des équipes éventuellement en
sous-effectif mais pourtant très efficaces. Je partirai de la précieuse
<A HREF="https://lists.debian.org/debian-devel-announce/2008/04/msg00014.html";>revue
des équipes</A> rassemblée par Steve McIntyre l'an dernier<SUP><A NAME="text2" HREF="#note2">2</A></SUP>
pour mener les renforcements d'équipe et les changements de procédure
de manière à ne pas embêter les équipes qui travaillent correctement.
</P>
<!--TOC section Additional info-->
<H2 CLASS="section"><!--SEC ANCHOR -->Informations supplémentaires</H2><!--SEC END -->
<P>
<A NAME="sec:extra"></A>
</P>
<!--TOC subsection Time commitment-->
<H3 CLASS="subsection"><!--SEC ANCHOR -->Temps consacré</H3><!--SEC END -->
<P>
<A NAME="sec:time-commit"></A>
</P>
<P>�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 donc en pause mes
autres engagements dans Debian : c'est un devoir envers les anciens
collaborateurs et un compromis honnête pour éviter l'explosion. Je ne suis
pas le seul responsable dans la plupart de mes devoirs côté Debian et je
abandonnerai des équipes efficaces, j'ai donc confiance sur le fait que les tâches
ne seront pas laissées sans surveillance. Le reste est une poignée de paquets
qui auront besoin de nouveaux responsables.
</P>
<P>
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 détourné au profit
du travail de chef du projet Debian. Cependant, heureusement, je travaille dans
une université où j'ai un patron très réceptif au logiciel libre. J'ai la
liberté de réorganiser mon agenda aussi bien lors d'urgence ou de prolongement
d'activité, comme des voyages pour parler de Debian. Comme la plupart d'entre nous,
je suis en général disponible sur IRC, par téléphone, etc.
</P>
<!--TOC subsection Live platform-->
<H3 CLASS="subsection"><!--SEC ANCHOR -->Un programme vivant</H3><!--SEC END -->
<P>
<A NAME="sec:live-platform"></A></P>
<P>En dehors des réfutations, le programme du chef du projet est fixé une fois
pour toute à la fin de la période de dépôt des candidatures. Même si c'est
parfaitement justifié dans le contexte d'une élection, cela complique la tâche
des candidats pour faire connaître leur position sur des questions importantes
à cause du volume d'informations que génère le processus électoral. Donc, pour
le cas où des sujets importants surgiraient pendant la campagne, je me propose
de résumer mes positions à leur sujet sur
<A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/";><TT>http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/</TT></A>.
</P>
<H2 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc30">3</A> Réfutation</H2><!--SEC END -->
<P>
<A NAME="sec:Rebuttal"></A>
</P>
<P>
Je connais Steve et Luk depuis un certain temps déjà et j'ai un profond respect
pour ce qu'ils ont fait tous les deux pour Debian toutes ces dernières années.
Je reconnais tous les problèmes qu'ils (oui, je dis <q>ils</q>, parce que de
fait, ils fonctionnent en tandem) mentionnent dans leur programme :
communication, humilité et demande d'aide� En fait pour l'essentiel ce
sont des problèmes que rencontrent tous les projets de logiciel libre.
</P>
<P>
Malgré cela, leur programme manque d'indications et de stratégies qui expliquent
<I>comment</I> ils vont s'attaquer à ces problèmes : ce n'est pas suffisant de
dire, par exemple, <q>je veux des améliorations portées là où on en a
réellement besoin</q> pour réellement mettre en Å?uvre ces améliorations. Il me
manque aussi la vision de ces deux candidats sur des sujets qui le méritent
comme l'appartenance à Debian, la qualité des discussions sur les listes de
diffusion, les distributions dérivées�
</P>
<P>
Dans l'ensemble, je trouve que le principal argument pour décider de voter pour
Steve et Luk est l'exemple donné par le mandat actuel de Steve. Le programme,
qui est ce sur quoi est censé porté la réfutation, n'a pas grand-chose d'autre
à offrir.
</P>
<p>
Je dois reconnaître que Steve a fait un travail admirable durant son mandat
actuel de chef du projet, mais la plupart de ses tâches pratiques sont en cours
d'achèvement. Il aurait été bien de savoir ce qu'il projetait de faire
<I>en plus</I>, s'il était réélu. Présenter un tel <q>diff</q> est, à mon avis
ce que doit faire le chef du projet en fonction quand il se représente.
</P>
<!--BEGIN NOTES document-->
<HR CLASS="footnoterule"><DL CLASS="thefootnotes"><DT CLASS="dt-thefootnotes">
<A NAME="note1" HREF="#text1">1</A></DT><DD CLASS="dd-thefootnotes">Pour ce
que ça vaut, même si cela était autrement plus simple, mon expérience avec la
<A HREF="http://upsilon.cc/~zack/blog/posts/2007/12/pts_face_lifted/";>mise à jour du système de gestion de paquets (PTS)</A> montre que
notre communauté est réactive face à nos faiblesses en présence web. J'ai
demandé de nouvelles feuilles de style pour l'apparence du PTS, eu plusieurs
réponses, et choisi l'une d'entre elles. Cela demande quelques échanges
dans les deux sens, mais ce n'est pas différent du mode de fonctionnement
habituel avec des correctifs.
</DD>
<DT CLASS="dt-thefootnotes"><A NAME="note2" HREF="#text2">2</A></DT>
<DD CLASS="dd-thefootnotes">avec des exceptions particulières, si les gens
qui ont été interrogés ne partagent pas avec moi le contenu même de l'enquête.
</DD>
</DL>
<!--END NOTES-->
<!--CUT END -->
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
<HR><BLOCKQUOTE CLASS="quote"><p><EM>Ce document a été converti du L<sup>A</sup>T<sub>E</sub>X par
</EM><A HREF="http://hevea.inria.fr/index.html";><EM>H</EM><EM><sup class="mini">E</sup></EM><EM>V</EM><EM><sup class="mini">E</sup></EM><EM>A</EM></A><EM>.</EM></p></BLOCKQUOTE>
Reply to: