Le 02/04/2012 08:05, Thomas Vincent a écrit : > Des suggestions. Merci beaucoup, j'ai tout intégré. Par avance merci pour vos autres relectures. Amicalement David
#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.6" maintainer="David Prévot"
{#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;}
.floatright{float: right;
}
.mini {font-size:.6em}
</STYLE>
:##}
<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><H3 CLASS="titlerest">12 mars 2010</H3></TD></TR>
</TABLE><DIV CLASS="flushright"><p class="mini">
Version : <TT>2.1</TT><BR>
Autres formats :
<A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2010/platform.html";>HTML</A>,
<A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2010/platform.pdf";>PDF</A>.<BR>
Plus de renseignements <A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2010/";>\
sur mon site</A>.
</DIV>
<H2 CLASS="section">Résumé</H2>
<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 <EM>présent</EM>, à 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, Ã figer et envoyer <EM>tous les mois</EM> Ã <TT>d-d-a</TT>.
</I></LI>
<LI CLASS="li-itemize"><I>
J'appliquerai des mécanismes conformes au <EM>consensus</EM> s'il existe.
</I></LI>
<LI CLASS="li-itemize"><I>
J'agirai en faveur de voies d'accès à Debian plus
<EM>progressives</EM> et <EM>gratifiantes</EM>.
</I></LI>
<LI CLASS="li-itemize"><I>
Je me battrai contre l'excès de propriété des paquets
<EM>s'il entre en conflit avec la qualité</EM>.
</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>).
La réfutation est disponible en Annexe <A HREF="#sec:rebuttals">A</A>.
Si vous avez lu mon programme de 2009, vous pourriez être intéressé par
le journal des modifications (Annexe <A HREF="#sec:changelog">B</A>).
</P>
<H2 CLASS="section"><A NAME="htoc1">1</A>Â Â Introduction</H2>
<P><A NAME="sec:intro"></A></P>
<H3 CLASS="subsection"><A NAME="htoc2">1.1</A>Â Â Qui suis-je</H3>
<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>
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é :
</p>
<DL CLASS="description">
<DT CLASS="dt-description">
<B>PTS</B> : système de suivi des paquets
</DT>
<DD CLASS="dd-description">
J'ai comaintenu le <A HREF="http://packages.qa.debian.org";>\
système de suivi des paquets (PTS)</A>
pendant les quatre ou cinq 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/pts/";>mon
blog</A> (mon intérêt initial dans le PTS est né de l'envie de
<A HREF="http://upsilon.cc/~zack/blog/posts/2006/09/xs-x-vcs-XXX/";>rendre</A>
les champs <TT>Vcs-*</TT>
<A HREF="http://upsilon.cc/~zack/blog/posts/2006/10/xs-vcs-XXX_almost_there/";>populaires</A>,
ce qui m'a conduit à écrire
<A HREF="http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/";><TT>debcheckout</TT></A>).
</DD>
<DT CLASS="dt-description">
<B>QA</B> : assurance qualité
</DT>
<DD CLASS="dd-description">
De façon plus générale, je fait partie depuis longtemps de l'équipe d'<A
HREF="http://qa.debian.org/";>assurance qualité</A> : j'aime penser au
projet comme un tout et chercher de nouvelles solutions (par exemple
<A HREF="http://wiki.debian.org/UltimateDebianDatabase";>UDD</A>, <A
HREF="http://lists.debian.org/debian-project/2009/07/msg00067.html";>\
expiration de droits des développeurs Debian portés disparus</A>, etc.)
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="http://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 coordonnateur.
L'équipe gère maintenant environ <A
HREF="http://pkg-ocaml-maint.alioth.debian.org/debian-ocaml-status.html";>\
150Â paquets source</A> avec des <A
HREF="http://upsilon.cc/~zack/research/publications/jfla10-dh-ocaml.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>RCBW</B>Â : bogues critiques pour la publication (<q>RC bug</q>) de la semaine
</DT>
<DD CLASS="dd-description">
Depuis septembre 2009, j'ai participé à la correction
d'un bogue critique pour la publication par jour en initiant les <EM>bogues
critiques pour la publication de la semaine</EM>, consultez la <A
HREF="http://upsilon.cc/~zack/hacking/debian/rcbw/";>page des
bogues critiques pour la publication de la semaine</A> pour les
motivations et plus de précisions.
</DD>
<DT CLASS="dt-description">
<B>AM</B>Â : responsable de candidature
</DT>
<DD CLASS="dd-description">
J'ai rejoint le <A HREF="https://nm.debian.org/whoisam.php";>comité de
nouveau responsable</A> en 2009, en devenant responsable de candidature.
Je me suis occupé de quatre nouveaux responsables,
dont deux sont devenus développeurs Debian depuis.
</DD>
<DT CLASS="dt-description">
<B>Empaquetage</B>
</DT>
<DD CLASS="dd-description">
Je maintiens aussi <A
HREF="http://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="http://packages.debian.org/sid/devscripts";><TT>devscripts</TT></A>,
<A HREF="http://packages.debian.org/sid/vim";><TT>vim</TT></A>, <A
HREF="http://packages.debian.org/sid/python-debian";><TT>python-debian</TT></A>
et <A HREF="http://packages.debian.org/sid/python-turbogears2";><TT>\
turbogears2</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="http://www.debconf.org/";>DebConf</A>
et, quand mon temps le permettait, Ã d'autres rencontres en personne comme
des <A HREF="http://wiki.debian.org/BSP2010/Moenchengladbach";>chasses aux
bogues</A> et des <A
HREF="http://wiki.debian.org/DebianQAExtremadura2008?action=fullsearch&context=180&value=debian+extremadura&titlesearch=Titles";>\
rencontres en Estrémadure</A>.
</P>
<P>
Dans la vie, je suis <A HREF="http://upsilon.cc/~zack/research/";>\
chercheur en informatique</A>, et travaille 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>.
Le laboratoire ressemble à un repaire de développeurs Debian, où les 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 les méthodes formelles pour étudier les distributions libres.
Le projet contribue régulièrement en retour sous la forme d'outils
pour la communauté comme <A
HREF="http://packages.debian.org/sid/edos-distcheck";>\
<TT>edos-distcheck</TT></A>, <A HREF="http://edos.debian.net";>\
<TT>edos.debian.net</TT></A> et d'autres services d'assurance qualité
utilisés quotidiennement par Debian et d'autres distributions.
</P>
<H3 CLASS="subsection"><A NAME="htoc3">1.2</A>  Pourquoi je me présente au poste de chef du projet</H3>
<P><A NAME="sec:whyrunning"></A></P>
<P>
�tre chef du projet représente deux facettes différentes : le
rôle institutionnel et quelques objectifs supplémentaires que le
futur chef de projet a l'intention d'atteindre pendant le mandat.
Le rôle institutionnel est <A HREF="$(DEVEL)/constitution#5">décrit dans
notre constitution</A> et est à propos de trois tâches : les prises de
décisions ordinaire et extraordinaire, 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 des choses 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 tendance Ã
la modifier en 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 certaines positions pourraient négliger leurs
autres devoirs et diminuer la qualité du service qu'ils offrent,
parce qu'ils n'admettent pas ne plus être aptes pour ces tâches.
</LI>
</OL>
</DIV>
<P>
Le chef du projet a le devoir, pour un temps limité,
d'atténuer les imperfections de notre <q>do-ocracy</q> :
</P>
<DIV CLASS="alphaenum">
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
de 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">
de trouver des gens volontaires pour les tâches peu passionnantes
pour le bien général du projet (en échange du mérite adéquat) ;
</LI>
<LI CLASS="li-enumerate">
(ré)assigner des gens aux positions 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'occasion de faire pression 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.
</P>
<H2 CLASS="section"><A NAME="htoc4">2</A>Â Â Mes objectifs</H2>
<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>
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
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 de
comment je peux réagir face à des scénarios imprévisibles.
</LI>
<LI CLASS="li-enumerate">
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>
<LI CLASS="li-enumerate">
Enfin je présente quelques projets spécifiques que j'ai
l'intention de poursuivre si je suis élu chef du projet Debian.
</LI>
</OL>
<H3 CLASS="subsection"><A NAME="htoc5">2.1</A>Â Â Vision</H3>
<P><A NAME="sec:vision"></A></P>
<H5 CLASS="paragraph">Contributeurs non empaqueteurs</H5>
<P>
L'introduction des <A HREF="http://wiki.debian.org/DebianMaintainer";>\
DM</A> (mainteneurs 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 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 incité 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 des niveaux 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 à nos contributeurs une reconnaissance <EM>progressivement</EM>.
</P>
<P>
Nous devons tirer les leçons du processus de DM.
Nous avons beaucoup de précieux contributeurs potentiels dans les environs.
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 fier, qui reconnaît 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 <q>meilleur système d'exploitation</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>
<H5 CLASS="paragraph">Maintenance collaborative</H5>
<P>
L'introduction du champ <TT>Uploaders</TT> a
été un 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 ce devrait ê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 sont utiles pour
partager le poids sur les épaules du processus de NM.
De même, nous ne devrions pas accepter la maintenance en solo quand elle vient
de paquets qui ne sont de fait pas maintenus (Ã identifier convenablement
de façon quantifiable d'un point de vue de l'assurance qualité, avec
par exemple des vérifications croisées de MIA, WAT, bapase, etc.)
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 contre l'excès de propriété des paquets
<EM>s'il entre en conflit avec la qualité</EM>.
</I></DIV></DIV>
<H5 CLASS="paragraph">Minorités bruyantes</H5>
<P>
Nos listes de diffusion se sont sensiblement améliorées ces 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
(les messages VAC à cause de cela sont bien trop fréquents).
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 devrions 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>
que les expéditeurs font 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 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>.
</P>
<P>
Les sondages permettent d'obtenir un point de vue raisonnable de l'avis de la
communauté, sans avoir à lancer la grosse machinerie de 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>
J'appliquerai des mécanismes conformes au <EM>consensus</EM> s'il existe.
</I></DIV></DIV>
<H5 CLASS="paragraph">Rencontres en personne</H5>
<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 rassembler en personne, programmer pendant des
heures, faire des choses ensemble, et rentrer chez soi.
Le jour suivant, votre collaboration à distance sera meilleure.
</P>
<P>
Permettre l'organisation de rencontres est un des meilleurs
moyens d'utiliser l'argent de Debian et d'autre ressources,
comme les gens justement nommés pour les gérer.
Heureusement que nous avons <A HREF="http://www.debconf.org";>\
DebConf</A>, organisée par une équipe très efficace.
Cependant 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 pour travailler à des objectifs précis.
</P>
<P>
Une simple façon de décider quand le faire ou ne pas le
faire, au delà de la somme d'argent nécessaire, peut
ê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>
<H5 CLASS="paragraph">Distributions dérivées</H5>
<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 échouons parfois à le faire.
Des initiatives comme le <A HREF="http://patch-tracker.debian.org";>\
suivi de correctifs</A> nous permettent de rendre
visibles nos modifications à la fois en amont et en aval.
</P>
<P>
Nos distributions dérivées nous ont en
amont, et sont dans une situation semblable.
Nous ne pouvons pas les <em>obliger</em> Ã nous donner
quoi que ce soit, car nos promesses ne sont pas
forcément les leurs, mais nous devrions tout de même :
</P>
<OL CLASS="enumerate">
<LI CLASS="li-enumerate">
<EM>être exemplaires dans nos pratiques de restitution</EM>, par exemple
en suivant publiquement nos efforts à l'envoi de correctifs en amont ;
</LI>
<LI CLASS="li-enumerate">
<EM>faciliter autant que possible la restitution vers nous</EM>,
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.
</LI>
</OL>
<P>
Faire les deux renforcera nos <EM>requêtes</EM> de restitution aux
distributions dérivées que nous ne devrions pas arrêter de présenter.
</P>
<P>
En particulier, nous ne devrions pas ignorer le fait
qu'<B>Ubuntu</B> est la plus populaire de nos distributions
dérivées et semble avoir une communauté plus grande que la nôtre.
(i) <EM>Techniquement</EM>, nous devrions exploiter
cela au bénéfice de nos utilisateurs, en intégrant les
modifications intéressantes et en jetant le reste.
Dans ce but, j'accueillerai les mécanismes techniques qui permettent
aux développeurs Debian de mieux interagir avec la communauté
Ubuntu (bogues, correctifs, etc.) à propos de leurs paquets.
(ii) <EM>Politiquement</EM>, nous avons l'avantage que les
publications d'Ubuntu contiennent 70 % de paquets Debian non modifiés.
<SUP><A NAME="text1" HREF="#note1">1</A></SUP>
Cet avantage devrait être utilisé pour communiquer de façon plus
incisive notre vÅ?u de voir Ubuntu se comporter comme un aval de
logiciel libre convenable : en remerciant et en donnant ses travaux.
(iii) Enfin nous devrions <em>communiquer</em> sur les raisons qui
nous rendent meilleurs (consultez la Section <A HREF="#sec:website">\
2.3.1</A>) et ne pas oublier que nous <EM>sommes</EM> meilleurs.
</P>
<H3 CLASS="subsection"><A NAME="htoc6">2.2</A>Â Â Interaction avec le projet</H3>
<P><A NAME="sec:dpl-project"></A></P>
<H4 CLASS="subsubsection"><A NAME="htoc7">2.2.1</A>  �tre présent</H4>
<P><A NAME="sec:presence"></A></P>
<P>
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 lui 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çon : 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 vu.
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>
La deuxième expression de présence qui devrait être attendue du
chef de projet est dans la gestion du <b>programme du projet</b>,
ainsi que dans la communication de <b>notre vision</b>.
La gestion du programme signifie avoir des objectifs sur les sujets que
le projet devrait <EM>considérer</EM> pendant un certain laps de temps.
La page <A HREF="http://wiki.debian.org/DiscussionsAfterLenny";>\
DiscussionsAfterLenny</A> â?? et la façon dont nous (ne)
l'avons (pas) utilisé â?? 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>,
à laquelle j'ai contribué au début, est une tentative dans ce sens :
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.
Le chef du projet devrait prendre soin des DEP <q>abandonnées</q>
en les réassignant, les fermant ou les pilotant lui-même.
Je m'assurerai que nous essayions les artifices du même genre, pour
vérifier si nous pouvons enfin avoir des choix 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 <EM>présent</EM>, à la fois
dans les discussions et en tant que responsable du programme du projet.
</I></DIV></DIV>
<H4 CLASS="subsubsection"><A NAME="htoc8">2.2.2</A>Â Â Transparence</H4>
<P><A NAME="sec:transparency"></A></P>
<P>
Une autre façon d'être présent pour le chef de projet est de dévoiler
<EM>régulièrement</EM> ce qu'elle ou il est en train de faire ;
appelons ça la <q>transparence</q>.
� cet égard, les habituels trop peu nombreuses <q>brèves du chef
de projet</q> pendant un mandat ne sont pas acceptables pour un
rôle qui est censé représenter un projet aussi gros et varié.
Si je dois faire face au dilemme, je préférerai laisser tomber quelques tâches
de chef de projet pour communiquer sur les autres, plutôt que l'inverse.
</P>
<P>
Probablement qu'un certain nombre d'activités du chef de projet ne sont
pas adaptées à être dévoilées, qu'elles soient d'ordre personnel pour
certaines personnes, totalement inintéressantes, ou encore qu'elles
ne soient pas sensées être archivées sur Internet pour toujours.
Je sais aussi qu'écrire à partir de rien un message de <q>brèves du chef de
projet</q> peut demander beaucoup de temps et éventuellement être intimidant.
</P>
<P>
La solution que je mettrais 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, l'implémentation peut varier : un canal
IRC, un blog ou microblog, une page de wiki <TT>BitsFromTheDPL</TT>
traitée <EM>à la</EM> <A HREF="http://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.
Le flux sera alors figé tous les mois et envoyé à <TT>d-d-a</TT>.
Si j'échoue deux fois à envoyer et figer, j'admettrai
mon échec et en expliquerai les raisons en demandant des
avis pour trouver des moyens de continuer le mandat.
</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 <EM>tous les mois</EM> Ã <TT>d-d-a</TT>.
</I></DIV></DIV>
<H5 CLASS="paragraph">Argent</H5>
<P>
Je crois que nous devons améliorer aussi la transparence sur
la <EM>gestion de l'argent</EM> : à la fois les développeurs
Debian et les contributeurs devraient pourvoir connaître les
flux d'argent entrant et sortant de nos comptes en banque.
Je rechercherai avec les trésoriers respectifs le moyen
de mettre en place ce type de compte-rendu public.
Nous avons pas mal d'argent (plus de 60Â 000Â $ rien que sur le compte de SPI),
avoir une idée de la façon dont il est utilisé pourrait motiver tout le projet
à l'utiliser de façon plus profitable (par exemple des machines dédiées
ou d'autres ressources pour les besoins spécifiques de l'empaquetage).
</P>
<H4 CLASS="subsubsection"><A NAME="htoc9">2.2.3</A>  Pas d'équipe de direction du projet Debian</H4>
<P><A NAME="sec:dpl-board"></A></P>
<P>
D'après les chefs du projet précédents, supporter les
tâches de chef de projet tout seul peut être 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 en l'utilité d'une <b>équipe de direction du projet</b>,
donc je n'en aurai pas ; je n'aurai pas non plus de responsable adjoint.
Dans l'ensemble, je n'ai pas trouvé de preuve qu'un de ces deux artifices peut
influencer de façon significative le déroulement du mandat de chef de projet.
</P>
<P>
Pour les affectations aux tâches plus spécifiques, nous
avons les délégations qui sont bien plus qu'assez.
J'aimerais étudier l'utilisation de <em>délégations limitées dans le
temps</em> pour s'occuper de tâches spécifiques qui sont considérées
fondamentales pour réaliser des points du programme du projet.
Une délégation limitée dans le temps â?? mise en place comme une délégation
normale en déclarant qu'elle sera défaite, par exemple, à la fin du
mandat de chef du projet â?? évite l'accumulation de pouvoirs et donnera
au responsable un laps de temps pendant lequel concentrer ses efforts.
J'aimerais que des développeurs Debian se proposent d'eux-mêmes
pour être responsables de tâches qui leur tiennent à cÅ?ur (tant
que la <q>casquette de responsable</q> est vraiment nécessaire).
</P>
<DIV CLASS="mantra"><DIV CLASS="center"><I>
Je n'aurai pas d'équipe de direction du projet ;
j'utiliserai plutôt les délégations éventuellement limitées dans le temps.
</I></DIV></DIV>
<H3 CLASS="subsection"><A NAME="htoc10">2.3</A>Â Â Plans particuliers</H3>
<P><A NAME="sec:itches"></A></P>
<H4 CLASS="subsubsection"><A NAME="htoc11">2.3.1</A>Â Â Le site web</H4>
<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="http://wiki.debian.org/DebianWebsiteDiscussion";>a
avancé</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>
Plus le temps passe, plus les inconvénients du <EM>statu
quo</EM> sur le site web deviennent significatifs.
En particulier nous devons maintenant clairement expliquer
à notre communauté (potentielle) pourquoi nous sommes
meilleurs que les autres distributions basées sur Debian.
Nous devons expliquer que nous sommes <EM>libres du début à la
fin</EM> (y compris tous les éléments de notre infrastructure)
et que nous sommes un <em>projet vraiment démocratique</em> où
les décisions sont prises par les bénévoles et non par l'argent.
Autrement dit, nous devons promouvoir <B>notre vision</B> au monde du logiciel
libre et le site web devrait être le premier support pour le communiquer.
</P>
<P>
J'ai l'intention d'aider l'équipe en charge du site pour
résoudre les problèmes principaux pendant le mandat.
Même s'il serait inutile de définir précisément les objectifs
techniques dans un programme, ma conduite prévue sera la suivante.
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 termes de :
message, structure, accessibilité et 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 délivrer en 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="text2" HREF="#note2">2</A></SUP>
</LI>
<LI CLASS="li-enumerate">
S'assurer que les preneurs ont accès aux ressources nécessaires, qu'ils
soient correctement remerciés pour leur tentative et, espérons le, y arrivent.
</LI>
</OL>
<P>
Si tout cela échoue, nous déclencherons un plan d'urgence.
Par exemple, nous pouvons envisager de rechercher de l'aide
<EM>extérieure</EM> (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>
<H4 CLASS="subsubsection"><A NAME="htoc12">2.3.2</A>  Clarification des délégations</H4>
<P><A NAME="sec:delegates"></A></P>
<P>
Rappelez vous : TINC (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">
toutes les personnes des équipes principales qui étaient en place avant
la généralisation des délégations devraient être officiellement déléguées.
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>
<H4 CLASS="subsubsection"><A NAME="htoc13">2.3.3</A>Â Â Ã?quipes principales</H4>
<P><A NAME="sec:core-teams"></A></P>
<P>
Nos équipes principales se sont beaucoup améliorées récemment, Ã
la fois en termes de main-d'Å?uvre et en termes de communication.
Félicitations pour ces améliorations aux 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 rend une équipe plus tolérante aux absences, et
permet aussi de préparer la génération suivante de contributeurs.
La distinction entre les assistants et les membres 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>, on dirait que plusieurs équipes sont soit
inactives, soit très mauvaises pour communiquer ce qu'elles font.
Pour leur propre bien, les personnes impliquées devraient être incitées
soit à passer la main pour s'occuper de choses qui les intéressent
plus, soit à communiquer régulièrement sur ce qu'elles font.
</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.
L'initiative de <A
HREF="http://lists.debian.org/debian-devel-announce/2008/04/msg00014.html";>\
contrôle des équipes</A> lancée par Steve McIntyre il y a deux
ans allait dans la bonne direction, même si elle devra de toute
évidence être réorganisée car le temps passe pour tout le monde.
</P>
<H2 CLASS="section">Informations supplémentaires</H2>
<P><A NAME="sec:extra"></A></P>
<H5 CLASS="paragraph">Temps consacré</H5>
<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.
La plupart de mes devoirs côté Debian se font avec des équipes
très 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, j'ai un <A
HREF="http://en.wikipedia.org/wiki/Roberto_Di_Cosmo";>patron
très réceptif au logiciel libre</A> : j'ai 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.
Comme la plupart d'entre nous, je suis en général disponible
sur IRC, par téléphone, etc.
</P>
<H2 CLASS="section"><A NAME="htoc14">A</A>  Réfutation</H2>
<P><A NAME="sec:rebuttals"></A></P>
<H5 CLASS="paragraph">Wouter Verhelst</H5>
<P>
Je suis d'accord avec plusieurs parties de la <q>vision</q> de Wouter sur
Debian et, en particulier, avec le fait que nous avons un grand besoin
d'attirer plus de développeurs pour conserver notre excellence technique.
</P>
<P>
Ce qui ne me semble pas clair en lisant son programme
est la façon de la mettre vraiment en place.
D'un côté, l'idée de parler plus avec des <q>gens Debian</q> autres
que des développeurs et mainteneurs Debian est merveilleuse â?? si tant
est que Wouter imagine que le chef du projet va participer à plus
d'événements que nos <q>habituels</q> événements orientés développeurs.
Cela n'est cependant pas suffisant, parce que le grand public
de nos éventuels contributeurs n'est pas (seulement) là .
De ce côté, je pense que miser sur notre présence sur le
web n'est pas mentionné dans le programme comme un domaine
stratégique important pour attirer plus de développeurs.
</P>
<P>
Enfin, je pense que pour réaliser notre excellence technique,
attirer plus de développeurs est nécessaire, mais pas suffisant.
Dans l'écosystème Debian actuel, avec le succès de quelques unes de
nos distributions dérivées, l'excellence technique passe aussi par
l'exploitation des synergies parmi toutes nos distributions dérivées.
De ce point de vue, je ne vois pas dans le programme de Wouter sa vision Ã
propos de sujets comme nos relations avec les distributions dérivées.
</P>
<H5 CLASS="paragraph">Charles Plessy</H5>
<P>
Dans l'ensemble, je ne pense pas partager le présupposé
de Charles sur la <EM>crise de croissance</EM> de Debian.
Actuellement, je ne perçois pas Debian comme ayant un problème
d'échelle par rapport au nombre de paquets, de contributeurs, etc.
Au contraire : j'ai plutôt l'impression que la main-d'Å?uvre (relative)
disponible est en diminution et que notre qualité en souffre par conséquent.
Pour contrer cela, nous devons <EM>croître plus</EM>,
en particulier le nombre de développeurs Debian.
</P>
<P>
Je suis parfois d'accord ou non de façon mitigée
avec les autres propositions avancées par Charles.
Par exemple j'aime bien l'idée de sollicitation des délégués, mais je n'aime
pas l'idée de publications flexibles qui â?? pour reprendre les mots de
Charles â?? semble faire peser la balance trop loin de la <EM>coordination</EM>.
De plus, j'aime l'idée d'avoir le chef du projet qui s'occupe des
discussions <q>en surplus</q> (en fait cela fait partie de mon programme
où je déclare que le chef du projet doit s'occuper du programme du
projet, consultez la Section <A HREF="#sec:presence">2.2.1</A>).
</P>
<P>
Un dernier détail pour finir, je ne suis pas particulièrement
à l'aise avec l'idée d'un chef de projet qui ne pourra pas
voyager pour se rendre à des rencontres dans le monde entier,
car c'est un des devoirs les plus typiques du chef de projet.
</P>
<H5 CLASS="paragraph">Margarita Manterola</H5>
<P>
Le programme de Margarita est motivant sur la façon dont nous
devrions nous comporter au sein de la communauté Debian.
Cependant, je ne suis pas certain que le simple fait de dire comment
nous devrions nous comporter â?? ou d'avoir un chef de projet qui se
comporte de cette façon, comme cela a été soulevé sur <TT>-vote</TT> â??
suffise à modifier les comportements de façon significative.
La <q>journée de remerciement à Debian</q> est aussi une bonne
idée, mais il ne me semble pas qu'il soit nécessaire que le
chef de projet s'en occupe pour que cela devienne une réalité.
</P>
<P>
J'aime aussi l'idée de promouvoir Debian avec une campagne web, etc. mais
j'ai aussi noté en réponse au programme de Wouter, que j'ai trouvé frappant
de mettre en valeurs ces aspects que j'estime être des défauts mineurs dans
le contexte global de notre capacité à attirer plus de monde (y compris
notre présence web, la communication des valeurs qui nous distinguent, etc.)
</P>
<H5 CLASS="paragraph">Merci et bonne chance !</H5>
<P>
Jusqu'à présent, faire campagne cette année à été
vraiment <EM>sympathique et enthousiasmant</EM> pour moi.
Le mérite revient non seulement aux contributeurs pour les
questions intéressantes sur <TT>-vote</TT>, mais aussi au
fait qu'il y avait plusieurs candidats actifs en compétition.
Merci aux candidats, et bonne chance pour les élections !
</P>
<H2 CLASS="section"><A NAME="htoc15">B</A>Â Â Journal de modifications</H2>
<P><A NAME="sec:changelog"></A></P>
<P>
<A HREF="$(VOTE)/2009/platforms/zack">Mon programme
de 2009</A> et celui-ci se ressemblent beaucoup.
Pour ceux qui ont lu le premier, voici un
rapide résumé des modifications significatives.
</P>
<UL CLASS="itemize">
<LI CLASS="li-itemize">
Réorganisation de la section sur les distributions dérivées, précision des
relations avec Ubuntu (consultez la Section <A HREF="#sec:vision">2.1</A>).
</LI>
<LI CLASS="li-itemize">
Je ne rechercherai pas de responsable adjoint, je prévois plutôt
d'utiliser des délégations normales, éventuellement limitées dans
le temps (consultez la Section <A HREF="#sec:dpl-board">2.2.3</A>).
</LI>
<LI CLASS="li-itemize">
Prise de conscience du rôle du site web pour communiquer notre
vision (consultez la Section <A HREF="#sec:website">2.3.1</A>).
</LI>
<LI CLASS="li-itemize">
Petites modifications un peu partout <TT>:-)</TT>.
</LI>
</UL>
<HR CLASS="footnoterule">
<DL CLASS="thefootnotes">
<DT CLASS="dt-thefootnotes"><A NAME="note1" HREF="#text1">1</A></DT>
<DD CLASS="dd-thefootnotes">
Y compris universe, mais universe est néanmoins
un argument de vente important pour eux
</DD>
<DT CLASS="dt-thefootnotes"><A NAME="note2" HREF="#text2">2</A></DT>
<DD CLASS="dd-thefootnotes">
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 ai 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>
</DL>
<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>
Attachment:
signature.asc
Description: OpenPGP digital signature