(fr) vote_002.wml, sync

1 files changed, 314 insertions, 107 deletions

diff --git a/french/vote/2019/vote_002.wml b/french/vote/2019/vote_002.wml
index 6fe0bcdf49e..0f37cbe600b 100644
--- a/french/vote/2019/vote_002.wml
+++ b/french/vote/2019/vote_002.wml
@@ -48,8 +48,8 @@
       </tr>
       <tr>
         <th>Période de scrutin :</th>
-            <td></td>
-            <td></td>
+            <td>samedi 7 décembre 2019 00:00:00 UTC</td>
+            <td>Vendredi 27 décembre 2019 23:59:59 UTC</td>
       </tr>
     </table>
 
@@ -249,172 +249,379 @@ autres systèmes de démarrage.
         <li>Jonathan Dowland [<email jmtd@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00289.html'>message</a>] </li>
     </ol>
     <vtextd />
-	<h3>Choix 4 : prise en charge des systèmes non systemd, sans bloquer l'évolution</h3>
-
-<h4>Titre : prise en charge des systèmes non systemd, sans bloquer l'évolution</h4>
+	<h3>Choix 4 : prise en charge des systèmes non systemd, sans bloquer l'évolution</h3>
 
 <h4>PRINCIPES</h4>
 
-<p>1. Nous souhaitons continuer à prendre en charge plusieurs systèmes
-   de démarrage dans un avenir proche. Et nous voulons améliorer la prise
-   en charge de systemd.
+<p>1. Nous souhaitons continuer à prendre en charge plusieurs systèmes de
+démarrage dans un avenir proche. Et nous voulons améliorer la prise en
+charge de systemd.
 </p>
 
 <p>2. Il appartient essentiellement aux communautés dans chaque écosystème
-   logiciel d'entretenir et de développer ses programmes respectifs
-   – mais avec le soutien actif des autres responsables et contrôleurs
-   lorsque cela s'avère nécessaire.
+logiciel d'entretenir et de développer ses programmes respectifs – mais
+avec le soutien actif des autres responsables et contrôleurs    lorsque
+cela s'avère nécessaire.
 </p>
 
 <h4>DÉPENDANCES DE SYSTEMD</h4>
 
 <p>3. Dans l'idéal, les paquets devraient être pleinement fonctionnels
-   avec tous les systèmes de démarrage. Cela signifie (par exemple) que les
-   démons devraient fournir des scripts de démarrage traditionnels ou utiliser
-   d'autres mécanismes pour assurer qu'ils sont démarrés, sans systemd.
-   Cela signifie aussi que les logiciels de bureau devraient être
-   installables, et idéalement pleinement fonctionnels sans systemd.
+avec tous les systèmes de démarrage. Cela signifie (par exemple) que les
+démons devraient fournir des scripts de démarrage traditionnels ou utiliser
+d'autres mécanismes pour assurer qu'ils sont démarrés, sans systemd.
+Cela signifie aussi que les logiciels de bureau devraient être
+installables, et idéalement pleinement fonctionnels sans systemd.
 </p>
 
 <p>4. Aussi échouer à prendre en charge des systèmes non systemd,
-   lorsque cette prise en charge n'existe pas, est un bogue. Mais ce
-   n'est <b>pas</b> un bogue critique pour la publication. Il appartient au
-   responsable de paquet de déterminer si la nécessité de systemd est
-   enregistrée comme un bogue officiel dans le système de bogue de Debian,
-   lorsqu'il n'y a pas de correctif disponible.
+lorsque cette prise en charge n'existe pas, est un bogue. Mais ce
+n'est <b>pas</b> un bogue critique pour la publication. Il appartient au
+responsable de paquet de déterminer si la nécessité de systemd est
+enregistrée comme un bogue officiel dans le système de bogue de Debian,
+lorsqu'il n'y a pas de correctif disponible.
 </p>
 
 <p>5. Lorsqu'un paquet voit ses fonctionnalités réduites en l'absence de
-   systemd, cela ne devrait pas en général être en utilisant une dépendance
-   (<q>Depends</q>) ou une recommandation (<q>Recommends</q>) de systemd-sysv
-   (de façon directe ou indirecte). Cela parce que avec une telle dépendance,
-   l'installation de ce type de paquet peut tenter de changer de système de
-   démarrage, ce qui n'est pas ce que souhaite l'utilisateur. Par exemple, un
-   démon possédant seulement un script de fichier d'unité de systemd devrait
-   encore être installable sur un système non systemd, dans la mesure où il
-   pourrait être lancé manuellement.
+systemd, cela ne devrait pas en général être en utilisant une dépendance
+(<q>Depends</q>) ou une recommandation (<q>Recommends</q>) de systemd-sysv
+(de façon directe ou indirecte). Cela parce que avec une telle dépendance,
+l'installation de ce type de paquet peut tenter de changer de système de
+démarrage, ce qui n'est pas ce que souhaite l'utilisateur. Par exemple, un
+démon possédant seulement un script de fichier d'unité de systemd devrait
+encore être installable sur un système non systemd, dans la mesure où il
+pourrait être lancé manuellement.
 </p>
 
 <p>Une des conséquences de cela est que sur les systèmes non systemd, il
-   est possible d'installer un logiciel qui ne fonctionne pas, ou qui ne
-   fonctionne pas correctement, à cause d'une dépendance non déclarée à
-   systemd. C'est regrettable, mais essayer de changer le système de démarrage de
-   l'utilisateur est pire. Nous espérons que de meilleures approches
-   techniques pourront être développées pour corriger cela.
+est possible d'installer un logiciel qui ne fonctionne pas, ou qui ne
+fonctionne pas correctement, à cause d'une dépendance non déclarée à
+systemd. C'est regrettable, mais essayer de changer le système de démarrage de
+l'utilisateur est pire. Nous espérons que de meilleures approches
+techniques pourront être développées pour corriger cela.
 </p>
 
 <p>6. Nous reconnaissons que certains responsables de paquet considèrent
-   les scripts de démarrage comme un fardeau et nous espérons que la communauté
-   pourra trouver des solutions pour faciliter l'ajout de la
-   prise en charge de systèmes de démarrage différents de celui par défaut. Des
-   discussions sur la conception de tels systèmes devraient être amicales
-   et concertées, et si des arrangements appropriés sont développés, ils
-   devraient bénéficier de la prise en charge habituelle dans Debian.
+les scripts de démarrage comme un fardeau et nous espérons que la communauté
+pourra trouver des solutions pour faciliter l'ajout de la
+prise en charge de systèmes de démarrage différents de celui par défaut. Des
+discussions sur la conception de tels systèmes devraient être amicales
+et concertées, et si des arrangements appropriés sont développés, ils
+devraient bénéficier de la prise en charge habituelle dans Debian.
 </p>
 
 <h4>LES CONTRIBUTIONS DE PRISE EN CHARGE NON SYSTEMD SERONT ACCEPTÉES</h4>
 
 <p>7. L'échec de la prise en charge de systèmes non systemd alors que
-   cette prise en charge est disponible ou offerte sous la forme de
-   correctifs (ou de paquets), <b>devrait</b> être traité comme un bogue
-   critique pour la publication. Par exemple, les scripts de démarrage <b>ne
-   doivent</b> pas être supprimés simplement parce qu'une unité de systemd est
-   fournie à la place ; les correctifs qui contribuent à la prise en charge
-   d'autres systèmes de démarrage (sans effet important sur les installations de
-   systemd) devraient être classés comme des bogues de sévérité
-   &ldquo;serious&rdquo;.
+cette prise en charge est disponible ou offerte sous la forme de
+correctifs (ou de paquets), <b>devrait</b> être traité comme un bogue
+critique pour la publication. Par exemple, les scripts de démarrage <b>ne
+doivent</b> pas être supprimés simplement parce qu'une unité de systemd est
+fournie à la place ; les correctifs qui contribuent à la prise en charge
+d'autres systèmes de démarrage (sans effet important sur les installations de
+systemd) devraient être classés comme des bogues de sévérité
+&ldquo;serious&rdquo;.
 </p>
 
 <p>Cela est destiné à fournir un moyen léger mais efficace pour assurer
-   qu'une prise en charge satisfaisante peut être fournie aux
-   utilisateurs de Debian même quand les priorités du responsable du
-   paquet sont ailleurs. (Faire appel au comité technique pour des
-   correctifs individuels n'est pas raisonnable.)
+qu'une prise en charge satisfaisante peut être fournie aux
+utilisateurs de Debian même quand les priorités du responsable du
+paquet sont ailleurs. (Faire appel au comité technique pour des
+correctifs individuels n'est pas raisonnable.)
 </p>
 
 <p>Si les correctifs contiennent aussi un bogue critique pour la
-   publication (initialement selon l'avis du responsable du paquet, et
-   en fin compte de celui de l'équipe de publication) alors, bien sûr, le
-   rapport de bogue pourra être déclassé ou fermé.
+publication (initialement selon l'avis du responsable du paquet, et
+en fin compte de celui de l'équipe de publication) alors, bien sûr, le
+rapport de bogue pourra être déclassé ou fermé.
 </p>
 
 <p>8. Les responsables des composants de systemd, ou d'autres contrôleurs
-   (y compris d'autres responsables ou l'équipe de publication) ont
-   parfois à évaluer les contributions techniques visant à prendre en
-   charge les utilisateurs d'autres systèmes que systemd.
-   L'acceptabilité, pour les utilisateurs de systèmes de démarrage autres
-   que celui par défaut, des risques de défaillance est un sujet qui importe
-   aux responsables de ces systèmes et de la communauté avoisinante. Mais ces
-   contributions ne devraient pas exposer à des risques non négligeables
-   les utilisateurs de la configuration par défaut (systemd avec les
-   paquets recommandés installés).
+(y compris d'autres responsables ou l'équipe de publication) ont
+parfois à évaluer les contributions techniques visant à prendre en
+charge les utilisateurs d'autres systèmes que systemd.
+L'acceptabilité, pour les utilisateurs de systèmes de démarrage autres
+que celui par défaut, des risques de défaillance est un sujet qui importe
+aux responsables de ces systèmes et de la communauté avoisinante. Mais ces
+contributions ne devraient pas exposer à des risques non négligeables
+les utilisateurs de la configuration par défaut (systemd avec les
+paquets recommandés installés).
 </p>
 
 <h4>OUTILS DÉCLARATIFS DE SYSTEMD NON LIÉS AU DÉMARRAGE</h4>
 
 <p>9. Systemd fournit une diversité d'outils en plus du lancement de
-   démons. Par exemple, la création d'utilisateurs système ou de
-   répertoires temporaires. L'approche actuelle de Debian est souvent
-   basée sur des scripts de debhelper.
+démons. Par exemple, la création d'utilisateurs système ou de
+répertoires temporaires. L'approche actuelle de Debian est souvent
+basée sur des scripts de debhelper.
 </p>
 
 <p>
-   En général des approches plus déclaratives sont meilleures. Lorsque :</p>
-    <ul>
-     <li>systemd fournit un outil de ce type,
-     <li>il existe une spécification de l'outil (ou d'un sous-ensemble
-       adapté),
-     <li>l'outil est meilleur que d'autres approches disponibles
-       dans Debian, par exemple en étant plus déclaratif,
-     <li>il est acceptable de demander aux développeurs de systèmes non
-       systemd, y compris non Linux, de l'implémenter,
-     <li>y compris en tenant compte de la quantité du travail impliquée,
-    </ul>
+En général des approches plus déclaratives sont meilleures. Lorsque :</p>
+<ul>
+  <li>systemd fournit un outil de ce type,
+  <li>il existe une spécification de l'outil (ou d'un sous-ensemble
+    adapté),
+  <li>l'outil est meilleur que d'autres approches disponibles
+    dans Debian, par exemple en étant plus déclaratif,
+  <li>il est acceptable de demander aux développeurs de systèmes non
+    systemd, y compris non Linux, de l'implémenter,
+  <li>y compris en tenant compte de la quantité du travail impliquée,
+ </ul>
 <p>l'outil devrait être documenté dans la charte Debian (par un texte
-   incorporé et non par une référence à un document externe). La
-   transition devrait se faire sans problème pour tous les utilisateurs.
-   La communauté non systemd devrait se voir accorder au moins six mois,
-   douze mois si possible, pour développer son implémentation. (Il en va
-   de même pour toute amélioration future.)
+incorporé et non par une référence à un document externe). La
+transition devrait se faire sans problème pour tous les utilisateurs.
+La communauté non systemd devrait se voir accorder au moins six mois,
+douze mois si possible, pour développer son implémentation. (Il en va
+de même pour toute amélioration future.)
 </p>
 
 <p>
-   Si un consensus politique ne peut être atteint sur un outil, le comité
-   technique, pourrait prendre une décision en se basant sur les souhaits
-   du projet tels qu'exprimés dans cette résolution générale.
+Si un consensus politique ne peut être atteint sur un outil, le comité
+technique, pourrait prendre une décision en se basant sur les souhaits
+du projet tels qu'exprimés dans cette résolution générale.
 </p>
 
 <h4>ÊTRE CONCILIANTS LES UNS AVEC LES AUTRES</h4>
 
 <p>10. En général, les responsables de logiciels concurrents, y compris
-   les responsables des divers systèmes de démarrage concurrents, devraient être
-   conciliants sur les besoins de chacun des autres systèmes. Cela comprend
-   les besoins et le confort des utilisateurs des configurations
-   raisonnables autres que celle par défaut.
+les responsables des divers systèmes de démarrage concurrents, devraient être
+conciliants sur les besoins de chacun des autres systèmes. Cela comprend
+les besoins et le confort des utilisateurs des configurations
+raisonnables autres que celle par défaut.
 </p>
 
 <p>11. Les commentaires généraux négatifs sur les logiciels et leur
-   communauté, y compris aussi bien sur systemd lui-même que sur les
-   systèmes de démarrage non systemd, sont fortement déconseillés. Ni les
-   messages exprimant une aversion globale envers systemd ou ceux
-   prédisant la disparition des systèmes non systemd n'ont leur place
-   dans les forums de communication de Debian, de même que les références à
-   des bogues qui n'ont pas de pertinence par rapport au sujet en cours.
+communauté, y compris aussi bien sur systemd lui-même que sur les
+systèmes de démarrage non systemd, sont fortement déconseillés. Ni les
+messages exprimant une aversion globale envers systemd ou ceux
+prédisant la disparition des systèmes non systemd n'ont leur place
+dans les forums de communication de Debian, de même que les références à
+des bogues qui n'ont pas de pertinence par rapport au sujet en cours.
 </p>
 
 <p>Les communications sur les forums Debian sur ces sujets devront toutes
-   être stimulantes et conviviales, même lorsqu'il s'agit de discussions
-   sur des problèmes techniques. Nous demandons que tous les responsables
-   de forum de communication appliquent strictement ce principe.
+être stimulantes et conviviales, même lorsqu'il s'agit de discussions
+sur des problèmes techniques. Nous demandons que tous les responsables
+de forum de communication appliquent strictement ce principe.
 </p>
 
 <p>12. Nous demandons respectueusement à tous les contributeurs de
-   Debian, y compris les responsables de paquets, les éditeurs de la
-   charte Debian, l'équipe de publication, le comité technique et le
-   chef du projet Debian, de suivre ces objectifs et ces principes dans
-   leur travail et de les intégrer dans leurs documents, etc., d'une
-   manière appropriée. (Cette résolution est une déclaration de position,
-   paragraphe section 4.1 (5).)
+Debian, y compris les responsables de paquets, les éditeurs de la
+charte Debian, l'équipe de publication, le comité technique et le
+chef du projet Debian, de suivre ces objectifs et ces principes dans
+leur travail et de les intégrer dans leurs documents, etc., d'une
+manière appropriée. (Cette résolution est une déclaration de position,
+paragraphe section 4.1 (5).)
+</p>
+
+    <vproposerh />
+        <p>Ian Jackson [<email iwj@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00142.html'>texte la proposition</a>]
+    </p>
+    <vsecondsh />
+    <ol>
+        <li>Jonas Smedegaard [<email js@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00129.html'>message</a>] </li>
+        <li>Holger Levsen [<email holger@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00131.html'>message</a>] </li>
+        <li>Michael Lustfield [<email mtecknology@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00132.html'>message</a>] </li>
+        <li>Guilhem Moulin [<email guilhem@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00134.html'>message</a>] </li>
+        <li>Matthew Vernon [<email matthew@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00137.html'>message</a>] </li>
+        <li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00139.html'>message</a>] </li>
+        <li>gregor herrmann [<email gregoa@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00156.html'>message</a>] </li>
+        <li>Sean Whitton [<email spwhitton@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00163.html'>message</a>] </li>
+    </ol>
+    <vtexth />
+	<h3>Choix 5 : Prendre en charge la portabilité sans bloquer les progrès</h3>
+
+<h4>PRINCIPES</h4>
+
+<p>1. Le projet Debian réaffirme son engagement à être la colle qui relie
+et intègre différents logiciels qui fournissent des fonctionnalités
+similaires ou équivalentes à leurs divers utilisateurs qu'ils soient
+humains ou d'autres logiciels, ce qui est un des traits principaux
+définissant une distribution.
+</p>
+
+<p>2. Nous considérons que la portabilité de différentes plateformes
+matérielles et piles logicielles est un aspect important du travail que
+nous menons comme distribution, ce qui rend meilleurs les logiciels
+d'un point de vue architectural, plus robustes et plus évolutifs.
+</p>
+
+<p>3. Nous reconnaissons que différents projets amont ont des vues
+différentes sur le développement logiciel, les cas d'utilisation, la
+portabilité et la technologie en général. Nous reconnaissons également
+que les utilisateurs de ces projets évaluent différemment les
+concessions et ont en même temps des exigences diverses et valables et
+des besoins satisfaits par ces diverses vues.
+</p>
+
+<p>4. Suivant notre tradition, nous accepterons l'intégration de
+ces diverses technologies qui pourraient avoir parfois des visions
+divergentes, pour leur permettre de coexister en harmonie dans notre
+distribution, en réconciliant ces conflits grâce à des moyens
+techniques, aussi longtemps qu'il y aura des gens souhaitant fournir
+un effort.
+</p>
+
+<p>5. Cela nous permet de continuer à offrir un large éventail d'usages de
+notre distribution (dont certains pourraient ne pas même avoir été
+envisagés par nous). Ces usages vont des serveurs aux ordinateurs de
+bureau ou extrêmement embarqués ; cela va d'usages généralistes à des
+usages très spécifiques taillés sur mesure ; que ces projets soient liés
+au matériel ou basés sur des logiciels, des bibliothèques, des démons,
+des environnements de bureau complets ou d'autres parties de la pile
+logicielle.
+</p>
+
+<h4>DÉPENDANCES DE SYSTEMD</h4>
+
+<p>6. Dans l'idéal, les paquets devraient être pleinement fonctionnels
+avec tous les systèmes de démarrage. Cela signifie (par exemple) que les
+démons devraient fournir des scripts de démarrage traditionnels ou utiliser
+d'autres mécanismes pour assurer qu'ils sont démarrés, sans systemd.
+Cela signifie aussi que les logiciels de bureau devraient être
+installables, et idéalement pleinement fonctionnels sans systemd.
+</p>
+
+<p>7. Aussi échouer à prendre en charge des systèmes non systemd,
+lorsque cette prise en charge n'existe pas, est un bogue. Mais ce
+n'est <b>pas</b> un bogue critique pour la publication. Il appartient au
+responsable de paquet de déterminer si la nécessité de systemd est
+enregistrée comme un bogue officiel dans le système de bogue de Debian,
+lorsqu'il n'y a pas de correctif disponible.
+</p>
+
+<p>8. Lorsqu'un paquet voit ses fonctionnalités réduites en l'absence de
+systemd, cela ne devrait pas en général être en utilisant une dépendance
+(<q>Depends</q>) ou une recommandation (<q>Recommends</q>) de systemd-sysv
+(de façon directe ou indirecte). Cela parce que avec une telle dépendance,
+l'installation de ce type de paquet peut tenter de changer de système de
+démarrage, ce qui n'est pas ce que souhaite l'utilisateur. Par exemple, un
+démon possédant seulement un script de fichier d'unité de systemd devrait
+encore être installable sur un système non systemd, dans la mesure où il
+pourrait être lancé manuellement.
+</p>
+
+<p>Une des conséquences de cela est que sur les systèmes non systemd, il
+est possible d'installer un logiciel qui ne fonctionne pas, ou qui ne
+fonctionne pas correctement, à cause d'une dépendance non déclarée à
+systemd. C'est regrettable, mais essayer de changer le système de démarrage de
+l'utilisateur est pire. Nous espérons que de meilleures approches
+techniques pourront être développées pour corriger cela.
+</p>
+
+<p>9. Nous reconnaissons que certains responsables de paquet considèrent
+les scripts de démarrage comme un fardeau et nous espérons que la communauté
+pourra trouver des solutions pour faciliter l'ajout de la
+prise en charge de systèmes de démarrage différents de celui par défaut. Des
+discussions sur la conception de tels systèmes devraient être amicales
+et concertées, et si des arrangements appropriés sont développés, ils
+devraient bénéficier de la prise en charge habituelle dans Debian.
+</p>
+
+<h4>LES CONTRIBUTIONS DE PRISE EN CHARGE NON SYSTEMD SERONT ACCEPTÉES</h4>
+
+<p>10. L'échec de la prise en charge de systèmes non systemd alors que
+cette prise en charge est disponible ou offerte sous la forme de
+correctifs (ou de paquets), <b>devrait</b> être traité comme un bogue
+critique pour la publication. Par exemple, les scripts de démarrage <b>ne
+doivent</b> pas être supprimés simplement parce qu'une unité de systemd est
+fournie à la place ; les correctifs qui contribuent à la prise en charge
+d'autres systèmes de démarrage (sans effet important sur les installations de
+systemd) devraient être classés comme des bogues de sévérité
+&ldquo;serious&rdquo;.
+</p>
+
+<p>Cela est destiné à fournir un moyen léger mais efficace pour assurer
+qu'une prise en charge satisfaisante peut être fournie aux
+utilisateurs de Debian même quand les priorités du responsable du
+paquet sont ailleurs. (Faire appel au comité technique pour des
+correctifs individuels n'est pas raisonnable.)
+</p>
+
+<p>Si les correctifs contiennent aussi un bogue critique pour la
+publication (initialement selon l'avis du responsable du paquet, et
+en fin compte de celui de l'équipe de publication) alors, bien sûr, le
+rapport de bogue pourra être déclassé ou fermé.
+</p>
+
+<p>11. Les responsables des composants de systemd, ou d'autres contrôleurs
+(y compris d'autres responsables ou l'équipe de publication) ont
+parfois à évaluer les contributions techniques visant à prendre en
+charge les utilisateurs d'autres systèmes que systemd.
+L'acceptabilité, pour les utilisateurs de systèmes de démarrage autres
+que celui par défaut, des risques de défaillance est un sujet qui importe
+aux responsables de ces systèmes et de la communauté avoisinante. Mais ces
+contributions ne devraient pas exposer à des risques non négligeables
+les utilisateurs de la configuration par défaut (systemd avec les
+paquets recommandés installés).
+</p>
+
+<h4>OUTILS DÉCLARATIFS DE SYSTEMD NON LIÉS AU DÉMARRAGE</h4>
+
+<p>12. Systemd fournit une diversité d'outils en plus du lancement de
+démons. Par exemple, la création d'utilisateurs système ou de
+répertoires temporaires. L'approche actuelle de Debian est souvent
+basée sur des scripts de debhelper.
+</p>
+
+<p>
+En général des approches plus déclaratives sont meilleures. Lorsque :</p>
+<ul>
+  <li>systemd fournit un outil de ce type,
+  <li>il existe une spécification de l'outil (ou d'un sous-ensemble
+    adapté),
+  <li>l'outil est meilleur que d'autres approches disponibles
+    dans Debian, par exemple en étant plus déclaratif,
+  <li>il est acceptable de demander aux développeurs de systèmes non
+    systemd, y compris non Linux, de l'implémenter,
+  <li>y compris en tenant compte de la quantité du travail impliquée,
+ </ul>
+<p>l'outil devrait être documenté dans la charte Debian (par un texte
+incorporé et non par une référence à un document externe). La
+transition devrait se faire sans problème pour tous les utilisateurs.
+La communauté non systemd devrait se voir accorder au moins six mois,
+douze mois si possible, pour développer son implémentation. (Il en va
+de même pour toute amélioration future.)
+</p>
+
+<p>
+Si un consensus politique ne peut être atteint sur un outil, le comité
+technique, pourrait prendre une décision en se basant sur les souhaits
+du projet tels qu'exprimés dans cette résolution générale.
+</p>
+
+<h4>ÊTRE CONCILIANTS LES UNS AVEC LES AUTRES</h4>
+
+<p>13. En général, les responsables de logiciels concurrents, y compris
+les responsables des divers systèmes de démarrage concurrents, devraient être
+conciliants sur les besoins de chacun des autres systèmes. Cela comprend
+les besoins et le confort des utilisateurs des configurations
+raisonnables autres que celle par défaut.
+</p>
+
+<p>14. Les commentaires généraux négatifs sur les logiciels et leur
+communauté, y compris aussi bien sur systemd lui-même que sur les
+systèmes de démarrage non systemd, sont fortement déconseillés. Ni les
+messages exprimant une aversion globale envers systemd ou ceux
+prédisant la disparition des systèmes non systemd n'ont leur place
+dans les forums de communication de Debian, de même que les références à
+des bogues qui n'ont pas de pertinence par rapport au sujet en cours.
+</p>
+
+<p>Les communications sur les forums Debian sur ces sujets devront toutes
+être stimulantes et conviviales, même lorsqu'il s'agit de discussions
+sur des problèmes techniques. Nous demandons que tous les responsables
+de forum de communication appliquent strictement ce principe.
+</p>
+
+<p>15. Nous demandons respectueusement à tous les contributeurs de
+Debian, y compris les responsables de paquets, les éditeurs de la
+charte Debian, l'équipe de publication, le comité technique et le
+chef du projet Debian, de suivre ces objectifs et ces principes dans
+leur travail et de les intégrer dans leurs documents, etc., d'une
+manière appropriée. (Cette résolution est une déclaration de position,
+paragraphe section 4.1 (5).)
 </p>
 
     <vproposere />
@@ -432,7 +639,7 @@ autres systèmes de démarrage.
         <li>Simon Richter [<email sjr@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00238.html'>message</a>] </li>
     </ol>
     <vtexte />
-	<h3>Choix 5 : la prise en charge de plusieurs systèmes de démarrage est requise</h3>
+	<h3>Choix 6 : la prise en charge de plusieurs systèmes de démarrage est requise</h3>
 
 <p>Pouvoir exécuter des systèmes Debian avec des systèmes de démarrage
 différents de systemd continue à être utile au projet. Chaque paquet DOIT
@@ -462,7 +669,7 @@ fournit pas ou n'acceptera pas un script de démarrage.
         <li>Alberto Gonzalez Iniesta [<email agi@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00375.html'>message</a>] </li>
     </ol>
     <vtextg />
-	<h3>Choix 6 : prise en charge de la portabilité et de multiples implémentations</h3>
+	<h3>Choix 7 : prise en charge de la portabilité et de multiples implémentations</h3>
 
 <h4>Titre : réaffirmer notre engagement à prendre en charge la portabilité et de multiples implémentations</h4>