(fr) proofread Jean-Paul Guillonneau

CVS version numbers

french/vote/2009/platforms/zack.wml: 1.2 -> 1.3

1 files changed, 79 insertions, 77 deletions

diff --git a/french/vote/2009/platforms/zack.wml b/french/vote/2009/platforms/zack.wml
index ef0c1510f6d..385da913402 100644
--- a/french/vote/2009/platforms/zack.wml
+++ b/french/vote/2009/platforms/zack.wml
@@ -93,7 +93,7 @@ version <TT>1.0</TT>
 <!--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
+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">
@@ -109,7 +109,7 @@ 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 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
@@ -132,8 +132,8 @@ Je suis devenu développeur Debian (DD) en mars 2001, peu de temps après la mi
 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
+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>
@@ -142,7 +142,7 @@ 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
+<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
@@ -150,27 +150,27 @@ quotidienne ainsi qu'à des
 <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>Les champs Vcs-*</B></DT>
+<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 champs VCS (Version Control System) dans <TT>debian/control</TT>,
+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
+<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
-aux problèmes persistants.</DD>
+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 coordinnateur.
+</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>
+<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>
@@ -202,7 +202,7 @@ de la communauté française de Debian ; nos pauses-café se transforment souve
 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
+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
@@ -215,7 +215,7 @@ exécuté régulièrement sur
 <P>
 <A NAME="sec:whyrunning"></A></P>
 <P>
-Être chef du projet représente deux facettes différentes : le rôle
+Ê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.
@@ -229,10 +229,10 @@ l'aiguillage des discussions au sein du projet.
 <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
+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 à la modifier en une
-<q>do-ocracy imparfaite</q> :
+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">
@@ -247,7 +247,7 @@ pour s'en charger ;
 <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 ne plus être aptes pour ces tâches.
+n'admettent pas de ne plus être aptes pour ces tâches.
 </LI>
 </OL>
 </DIV>
@@ -258,16 +258,16 @@ imperfections de notre <q>do-ocracy</q> :
 <DIV CLASS="alphaenum">
 <OL CLASS="enumerate">
 <LI CLASS="li-enumerate"> 
-de remarquer les restrictions d'accès trop contraignantes qui empêchent les
+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
+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">
-d'assigner des gens aux postes clefs pour améliorer la qualité du service
+assigner des gens aux postes clefs pour améliorer la qualité du service
 à l'intérieur et à l'extérieur du projet.
 </LI>
 </OL>
@@ -314,7 +314,7 @@ dans les tâches institutionnelles du chef de projet Debian.
 <!--SEC END -->
 <P>
 L'introduction des <A HREF="https://wiki.debian.org/DebianMaintainer">\
-DM</A> (mainteneurs Debian) a été un événement heureux pour Debian. Certaines
+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
@@ -326,7 +326,7 @@ 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 des niveaux d'expérience. Dans l'ensemble, le processus
+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
@@ -337,7 +337,7 @@ d'autres projets.</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 fier, qui reconnaît
+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
@@ -365,11 +365,11 @@ 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
+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
+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>).
@@ -385,13 +385,14 @@ des paquets</EM></I><I> s'il entre en conflit avec la qualité.
 <H5 CLASS="paragraph"><!--SEC ANCHOR -->Minorités bruyantes</H5>
 <!--SEC END -->
 <P>
-Nos listes de diffusion se sont sensiblement améliorées ces 5 dernières années.
+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 message de vacances temporaires  - avec l'étiquette VAC - avons-nous à
-cause de cela ? Trop). Mon point de vue est le suivant :
+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>
@@ -404,14 +405,14 @@ d'accord.</I>
 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 font
+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>.
+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
@@ -433,7 +434,7 @@ approximatif</EM></I><I> s'il existe.</I>
 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, votre
+heures, faire des choses ensemble et rentrer chez soi. Le jour suivant, notre
 collaboration à distance sera bien meilleure.
 </P>
 <P>
@@ -445,7 +446,7 @@ 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 travailler à des objectifs précis.
+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
@@ -463,8 +464,8 @@ d'autres ressources, les rencontres de contributeurs.</I>
 <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 parfois à le faire.
+<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
@@ -479,7 +480,7 @@ tout de même :
 <OL CLASS="enumerate">
 <LI CLASS="li-enumerate">
 être exemplaires dans nos pratiques de restitution, par exemple en suivant
-publiquement nos efforts à l'envoi de correctifs en amont ;
+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
@@ -488,7 +489,7 @@ 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 nous ne devraient pas connaître de répit.
+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 -->
@@ -498,11 +499,11 @@ distributions dérivées que nous ne devraient pas connaître de répit.
 <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 lui demander, mais je
+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 vu. Même si
+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
@@ -528,7 +529,7 @@ ne s'en rappeler que plus tard au moment, par exemple, de la publication.
 <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é avec <A HREF="http://chistera.yi.org/~adeodato/blog/">Adeodato Simó</A>,
+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
@@ -540,7 +541,7 @@ 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
+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.
@@ -558,10 +559,10 @@ dans les discussions et en tant que responsable du programme du projet.</I>
 <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 4 ou 5
-messages de <q>brèves de ...</q> pendant un mandat de chef du projet est encore
-trop peu pour un rôle qui est censé représenter un projet aussi gros et
-varié.
+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
@@ -607,18 +608,20 @@ 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
-consacré 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 qu'assez.
-</P>
-<P>
-Cependant, la vie est ce qu'elle est, le chef du projet Debian est, en ce
-sens, 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 aider à 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">
+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 la communication.</I>
+plutôt un 2IC comme assistant et pour la communication.</I>
 </DIV>
 </DIV>
 <!--TOC subsection Specific plans-->
@@ -631,7 +634,7 @@ plutôt un 2IC comme assistant et la communication.</I>
 <P>
 <A NAME="sec:delegates"></A>
 </P>
-<P>Rappelez-vous : TINC (il n'y a pas de cabale). Bien. Alors :
+<P>Rappelez-vous : il n'y a pas de cabale. Bien. Alors :
 </P>
 <OL CLASS="enumerate">
 <LI CLASS="li-enumerate">
@@ -664,8 +667,8 @@ n'a encore été faite.
 <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, ma conduite prévue sera la
-suivante. Toutes les étapes sont supposées être réalisées
+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">
@@ -677,7 +680,7 @@ 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 en un intervalle de temps donné
+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).
@@ -685,8 +688,8 @@ important pour le demander).
 </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, y
-arrivent.
+qu'ils soient correctement remerciés pour leur tentative et, espérons-le, leur
+réussite.
 </LI>
 </OL>
 <P>
@@ -710,7 +713,7 @@ projet) et bien sûr aux équipes elles-mêmes. Néanmoins, certaines équipes s
 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
-les assistants et les membres dans plusieurs équipes semble fonctionner
+assistant et membre dans plusieurs équipes semble fonctionner
 vraiment bien pour cela.
 </P>
 <P>
@@ -721,7 +724,7 @@ 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 fait plus
+faire remplacer et à travailler sur quelque chose qui leur ferait plus
 plaisir.
 </P>
 <P>
@@ -748,7 +751,7 @@ 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
-laisserai des équipes efficaces, j'ai donc confiance sur le fait que les tâches
+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>
@@ -759,8 +762,8 @@ 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'urgences ou de prolongement
-d'activités, comme des voyages pour parler de Debian. Comme la plupart d'entre nous,
+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-->
@@ -771,8 +774,8 @@ je suis en général disponible sur IRC, par téléphone, etc.
 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'information que génère le processus électoral. Donc, pour
-le cas où des sujets important surgiraient pendant la campagne, je me propose
+à 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>
@@ -785,8 +788,8 @@ Je connais Steve et Luk depuis un certain temps déjà et j'ai un profond respec
 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 logiciels libres.
+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
@@ -795,7 +798,7 @@ 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, ...
+diffusion, les distributions dérivées…
 </P>
 <P>
 Dans l'ensemble, je trouve que le principal argument pour décider de voter pour
@@ -807,9 +810,8 @@ qui est ce sur quoi est censé porté la réfutation, n'a pas grand-chose d'autr
 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 é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 aux
-élections.
+<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-->
@@ -819,7 +821,7 @@ que ça vaut, même si cela était autrement plus simple, mon expérience avec l
 <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
+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>