+ <sect id="qa-effort">Effort d'assurance qualité
+
+ <sect1 id="qa-daily-work">Travail journalier
+<p>
+Bien qu'il y ait un groupe de personnes dédiées à l'assurance qualité, les
+ devoirs de QA ne leur sont pas exclusivement réservés. Vous pouvez participer à
+ cet effort en conservant vos paquets aussi exempts de bogues que possible et
+ aussi corrects que possible selon <prgn>lintian</prgn> (reportez-vous à <ref
+ id="lintian">). Si cela vous paraît impossible, vous devriez alors envisager
+ d'abandonner certains de vos paquets (reportez-vous à <ref id="orphaning">).
+ Sinon, vous pouvez demander de l'aide à d'autres personnes pour qu'elles
+ puissent rattraper votre retard dans la correction des bogues (vous pouvez
+ demander de l'aide sur &email-debian-qa; ou &email-debian-devel;). En même
+ temps, vous pouvez rechercher des co-responsables (reportez-vous à <ref
+ id="collaborative-maint">).
+
+ <sect1 id="qa-bsp">Les chasses aux bogues
+<p>
+De temps en temps, le groupe d'assurance qualité organise des chasses aux
+ bogues<footnote><em>Bug Squashing Party</em></footnote> pour essayer de
+ supprimer le plus de problèmes possible. Elles sont annoncées sur
+ &email-debian-devel-announce; et l'annonce explique quel domaine sera visé
+ pendant la chasse : habituellement, il s'agit des bogues empêchant
+ l'intégration du paquet dans la distribution (« Release Critical »),
+ mais il peut arriver qu'ils décident d'aider à finir une transition majeure
+ (comme une nouvelle version de Perl qui demande la recompilation de tous les
+ modules binaires).
+<p>
+Les règles pour les mises à jour indépendantes sont différentes au cours de la
+ chasse parce que l'annonce de la chasse est considérée comme une annonce
+ préalable pour les mises à jour indépendantes. Si vous avez des paquets qui
+ peuvent être affectées par la chasse (parce qu'ils ont des bogues critiques par
+ exemple), vous devriez envoyer une mise à jour pour chaque bogue correspondant
+ pour expliquer leur état actuel et ce que vous attendez de la chasse. Si vous
+ ne voulez pas d'une mise à jour indépendante ou si vous n'êtes intéressé que
+ par un correctif ou si vous voulez gérer vous-même le bogue, veuillez l'expliquer
+ dans le BTS.
+<p>
+Les personnes qui participent à la chasse ont des règles spécifiques pour les
+ mises à jour indépendantes, ils peuvent en faire une sans avertissement
+ préalable s'ils envoient leur paquet avec un délai d'au moins 3 jours dans
+ DELAYED/3-day. Toutes les autres règles de mise à jour indépendante
+ s'appliquent comme d'habitude ; ils devraient envoyer le correctif de la
+ mise à jour dans le BTS (pour l'un des bogues ouverts corrigé par la mise à
+ jour ou pour un nouveau bogue marqué comme fixé). Ils devraient également
+ respecter tout souhait du responsable s'il en a exprimé.
+<p>
+Si vous ne vous sentez pas à l'aise avec une mise à jour indépendante, envoyez
+ simplement un correctif au BTS. C'est de loin meilleur qu'une mise à jour
+ défectueuse.
+
+ <sect id="contacting-maintainers">Contacter d'autres responsables
+<p>
+Pendant vos activités dans Debian, vous aurez à contacter d'autres responsables
+ pour différentes raisons. Vous pourrez vouloir discuter d'une nouvelle
+ façon de coopérer au sein d'un ensemble de paquets liés, ou vous pouvez
+ simplement rappeler à quelqu'un qu'une nouvelle version est disponible et
+ que vous en avez besoin.
+<p>
+Chercher l'adresse d'un responsable d'un paquet peut être fastidieux.
+ Heureusement, il existe un alias de courrier simple,
+ <tt><paquet>@&packages-host;</tt>, qui fournit un moyen d'envoyer
+ un courrier à un responsable, quelle que soit son adresse (ou ses
+ adresses). Remplacez <tt><paquet></tt> par le nom du paquet source
+ ou binaire.
+<p>
+Vous pouvez également vouloir contacter les personnes qui sont inscrites à un
+ paquet de source donné par le <ref id="pkg-tracking-system">. Vous pouvez le
+ faire en utilisant l'adresse <tt><nom-paquet>@&pts-host;</tt>.
+
+<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
+
+ <sect id="mia-qa">Gérer les responsables non joignables
+<p>
+Si vous remarquez qu'un paquet manque de maintenance, vous devriez vous assurer
+ que le responsable est toujours actif et qu'il continue à travailler sur
+ ses paquets. Il est possible qu'il ne soit plus actif, mais qu'il ne se
+ soit pas désenregistré du système. D'un autre côté, il est possible qu'il
+ ait simplement besoin d'un rappel.
+<p>
+Il y a un système simple (la base de données MIA) dans laquelle les informations
+sur les responsables supposés Absents En Exercice (« Missing In Action) sont enregistrées. Quand un
+membre du groupe QA contacte un responsable inactif ou trouve plus d'informations
+sur celui-ci, c'est enregistré dans la base de données MIA. Ce système
+est disponible dans /org/qa.debian.org/mia sur l'hôte qa.debian.org et peut être
+interrogé avec un outil de nom <prgn>mia-history</prgn>. Par défaut,
+<prgn>mia-history</prgn> affiche des informations sur toutes les personnes qu'il
+connaît, mais il accepte des expressions rationnelles comme paramètre qu'il
+utilise comme correspondance de noms d'utilisateur. <example>mia-history
+--help</example> affiche quels paramètres sont acceptés. Si vous déterminez
+qu'aucune information n'a encore été enregistrée pour un responsable inactif ou
+que vous voulez ajouter plus d'informations, vous deviez utiliser la procédure
+suivante.
+<p>
+La première étape est de contacter poliment le responsable et d'attendre une
+réponse pendant un temps raisonnable. Il est assez difficile de définir le
+« temps raisonnable », mais il est important de prendre en compte que
+la vraie vie est parfois assez mouvementée. Une façon de gérer cela pourrait
+être d'envoyer un rappel après deux semaines.
+<p>
+Si le responsable ne répond pas après quatre semaines (un mois), on peut
+supposer qu'il n'y aura probablement pas de réponse. Si ceci se produit, vous
+devriez poursuivre vos investigations et essayer de réunir toutes les
+informations utiles sur ce responsable. Ceci inclut :
+ <p>
+ <list>
+ <item>Les informations « echelon » disponibles dans la <url
+ id="&url-debian-db;" name="base de données LDAP des
+ développeurs">, qui indiquent quand le développeur a envoyé un
+ message pour la dernière fois sur une liste de diffusion Debian
+ (cela inclut les envois via les listes debian-*-changes).
+ Rappelez-vous également de vérifier si le responsable est indiqué
+ comme en vacances dans la base de données.
+
+ <item>Le nombre de paquets de ce responsable et les conditions de ces
+ paquets. En particulier, restent-ils des bogues empêchant
+ l'intégration du paquet dans la distribution qui sont ouverts
+ depuis des lustres ? De plus, combien de bogues y a-t-il en
+ général ? Un autre point d'information important est si les
+ paquets ont subi des mises à jour indépendantes et si oui, par
+ qui.
+
+ <item>Est-ce que le responsable est actif en dehors de Debian ? Par
+ exemple, il peut avoir envoyé des messages récemment à des
+ listes de diffusion non-Debian ou des groupes de discussion.
+ </list>
+ <p>
+Un gros problème est représenté par les paquets parrainés — le responsable
+n'est pas un développeur Debian officiel. Les informations « echelon »
+ne sont pas disponibles pour les personnes parrainés, par exemple, vous devez
+donc trouver et contacter le responsable Debian qui a réellement envoyé le
+paquet. Étant donné qu'il a signé le paquet, il est responsable de l'envoi de
+toute façon et il devrait savoir ce qui s'est passé avec la personne qu'il
+parraine.
+<p>
+Il est également permis d'envoyer une demande à &email-debian-devel; demandant
+si quelqu'un est au courant d'information sur le responsable manquant.
+<p>
+Une fois que vous avez réuni toutes ces informations, vous pouvez contacter
+&email-debian-qa;. Les personnes de cet alias utiliseront les informations que
+vous aurez fournies pour décider comment procéder. Par exemple, ils peuvent
+abandonner un ou tous les paquets du responsable. Si un paquet a subi une mise à
+jour indépendante, ils peuvent préférer contacter le responsable ayant fait cette
+mise à jour — il est peut-être intéressé par le paquet.
+<p>
+Un dernier mot : veuillez vous souvenir d'être poli. Nous sommes tous des
+volontaires et nous ne pouvons dédier l'intégralité de notre temps à Debian.
+Vous n'êtes pas non plus au courant des circonstances de la personne impliquée.
+Elle est peut-être sérieusement malade ou pourrait même nous avoir quitté
+— vous ne savez pas qui recevra vos courriers. Imaginez comme un
+proche se sentira s'il lit un courrier pour la personne décédée et trouve un
+message très impoli, en colère et accusateur !)
+<p>
+D'un autre côté, bien que nous soyons tous volontaires, nous avons une
+responsabilité. Vous pouvez donc insister sur l'importance du plus grand intérêt
+— si un responsable n'a plus le temps ou l'envie, il devrait
+« laisser filer » et donner le paquet à quelqu'un ayant plus de temps.
+
+ <sect id="newmaint">
+ <heading>Interagir avec de futurs développeurs Debian
+<p>
+Le succès de Debian dépend de sa capacité à attirer et retenir de nouveaux et
+ talentueux volontaires. Si vous êtes un développeur expérimenté, nous vous
+ recommandons de vous impliquer dans le processus d'apport des nouveaux
+ responsables. Cette section décrit comment aider les futurs développeurs.
+
+
+ <sect1 id="sponsoring">Parrainer des paquets
+<p>
+Parrainer un paquet veut dire envoyer un paquet pour un responsable qui n'est
+ pas encore autorisé à le faire lui-même, un candidat nouveau responsable.
+ Parrainer un paquet veut aussi dire que vous en acceptez la responsabilité.
+<p>
+<!-- FIXME: service down
+Si vous désirez être volontaire pour être parrain, vous pouvez vous inscrire à
+ <url id="&url-sponsors;">.
+<p>
+-->
+Les nouveaux responsables ont habituellement certaines difficultés à créer des
+ paquets Debian — ceci est bien compréhensible. C'est pourquoi le parrain
+ est là pour vérifier que le paquet parrainé est assez bon pour être inclus
+ dans Debian. (Notez que si le paquet parrainé est nouveau, les ftpmasters
+ devront également l'inspecter avant de l'intégrer)
+<p>
+Effectuer un parrainage en signant simplement l'envoi ou en recompilant le
+ paquet <strong>n'est définitivement pas recommandé</strong>. Vous devez
+ construire le paquet source comme si vous vouliez construire l'un de vos
+ paquets. Rappelez-vous que cela ne change rien si vous avez laissé le nom du
+ candidat développeur dans le changelog et dans le fichier de
+ contrôle, il est toujours possible de savoir que c'est vous qui avez fait l'envoi.
+<p>
+Si vous êtes un gestionnaire de candidature pour un futur développeur, vous
+ pouvez également être son parrain. Ainsi, vous pourrez vérifier comment le
+ candidat gère la partie « Tâches et Capacités »<footnote>Tasks and
+ Skills</footnote> de sa candidature.
+
+ <sect1>Gérer les paquets parrainés
+<p>
+En envoyant un paquet sponsorisé vers Debian, vous certifiez que le paquet
+ atteint les standards minimum de Debian. Ceci implique que vous devez
+ construire et tester le paquet sur votre propre système avant l'envoi.
+<p>
+Vous ne pouvez pas simplement envoyer un fichier <file>.deb</file> binaire d'un
+ filleul. En théorie, vous devriez seulement demander le fichier diff et
+ l'emplacement de l'archive source d'origine et ensuite vous devriez récupérer
+ le source et appliquer le diff vous-même. En pratique, vous pouvez vouloir
+ utiliser le paquet source construit par votre filleul. Dans ce cas, vous devez
+ vérifier qu'il n'a pas modifié les fichiers sources du fichier
+ <file>.orig.tar.gz</file> qu'il fournit.
+<p>
+N'ayez pas peur de répondre au filleul et de lui indiquer les changements qu'il
+ doit faire. Cela prend souvent plusieurs échanges de courriers avant que le
+ paquet ne soit dans un état acceptable. Être un parrain veut dire être un
+ mentor.
+<p>
+Une fois que le paquet a atteint les standards Debian, construisez et signez le
+paquet avec
+<example>
+dpkg-buildpackage -k<var>KEY-ID</var>
+</example>
+ avant de l'envoyer dans le répertoire incoming. Bien sûr, vous pouvez également
+utiliser toute partie de votre <var>KEY-ID</var>, tant qu'elle est unique dans
+votre porte-clés secret.
+<p>
+Le champ Maintainer du fichier <file>control</file> et le fichier
+ <file>changelog</file> devraient afficher la personne qui a fait l'empaquetage,
+ c'est-à-dire, le filleul. Celui-ci recevra donc tous les courriers du système
+ de suivi des bogues (BTS) à propos de son paquet.
+<p>
+Si vous préférez laisser une trace plus visible de votre travail de parrainage,
+ vous pouvez ajouter une ligne l'indiquant dans la plus récente entrée du
+ changelog.
+<p>
+Vous êtes encouragé à garder un œil sur le suivi des paquets que vous parrainez
+ en utilisant le <ref id="pkg-tracking-system">.
+
+ <sect1>Recommander un nouveau développeur
+<p>
+Reportez-vous à la page sur les <url id="&url-newmaint-advocate;"
+ name="recommandations pour un développeur prospectif"> sur le site web Debian.
+
+ <sect1>Gérer les candidatures des nouveaux candidats
+<p>
+Veuillez vous reporter à la <url id="&url-newmaint-amchecklist;" name="liste à
+ vérifier pour les responsables de candidatures"> sur le site web Debian.
+
+ <chapt id="l10n">Internationalisation, traduction, être internationalisé et
+ être traduit
+ <p>
+Debian prend en charge un nombre toujours croissant de langues naturelles. Même
+si l'anglais est votre langue maternelle et que vous ne parlez pas d'autre
+langue, il est de votre devoir de responsable d'être conscient des problèmes
+d'internationalisation (abrégé en i18n à cause des 18 lettres entre le i et
+le n dans internationalisation). C'est pourquoi, même si des programmes
+seulement en anglais vous suffisent, vous devriez lire la plupart de ce chapitre.
+ <p>
+Selon l'<url id="http://www.debian.org/doc/manuals/intro-i18n/"
+name="introduction à l'i18n"> de Tomohiro KUBOTA, « I18N
+(internationalisation) veut dire la modification d'un logiciel ou de
+technologies liées pour qu'un logiciel puisse potentiellement gérer des langues
+multiples, des conventions multiples et ainsi de suite dans le monde
+entier » alors que « L10N (localisation) veut dire l'implémentation dans
+une langue spécifique pour un logiciel déjà internationalisé ».
+ <p>
+La l10n et l'i18n sont interconnectées, mais les difficultés liées à chacune sont très
+différentes. Il n'est pas vraiment difficile de permettre à un programme de
+changer la langue dans laquelle sont affichés les textes selon les paramètres de
+l'utilisateur, mais il est très coûteux en temps de traduire réellement ces
+messages. D'un autre côté, définir le codage des caractères est trivial, mais
+adapter le code pour utiliser des codages de caractères différents est un
+problème vraiment difficile.
+ <p>
+En laissant de côté les problèmes d'i18n pour lesquels il n'existe pas de règle
+générale, il n'y a pas actuellement d'infrastructure centralisée pour la l10n
+dans Debian qui puisse être comparée au mécanisme dbuild pour le portage. Le
+plus gros du travail doit donc être réalisé manuellement.
+
+
+ <sect id="l10n-handling">Comment sont gérées les traductions au sein de Debian
+ <p>
+La gestion des traductions des textes contenus dans un paquet est encore une
+tâche manuelle et le processus dépend du type de texte que vous désirez voir traduit.
+ <p>
+Pour les messages des programmes, l'infrastructure gettext est utilisée pour la
+plupart d'entre eux. La plupart du temps, la traduction est gérée en amont dans
+des projets comme le
+<url id="http://www.iro.umontreal.ca/contrib/po/HTML/" name="projet de traduction
+ libre">, le <url id="http://developer.gnome.org/projects/gtp/"
+ name="projet de traduction de Gnome"> ou <url
+ id="http://i18n.kde.org/" name="celui de KDE">.
+La seule ressource centralisée dans Debian est les <url
+id="http://www.debian.org/intl/l10n/" name="statistiques de traduction Debian
+ centralisées"> où vous pouvez trouver des statistiques sur les
+fichiers de traduction trouvés dans les paquets, mais il n'y a aucune
+infrastructure pour faciliter le processus de traduction.
+ <p>
+Un effort pour traduire les descriptions de paquet a démarré il y a longtemps,
+même si les outils fournissent très peu de prise en charge pour les utiliser
+vraiment (i.e., seul APT peut les utiliser quand il est configuré
+convenablement). Les responsables n'ont rien à faire de particulier pour gérer
+les traductions des descriptions de paquets ; les traducteurs devraient
+utiliser le <url id="http://ddtp.debian.org/" name="DDTP">.
+ <p>
+Pour les questionnaires debconf, les responsable devraient utiliser le paquet
+po-debconf pour faciliter le travail des traducteurs, qui peuvent utiliser le
+DDTP pour faire leur travail (mais les équipes française et brésilienne ne le
+font pas). On peut trouver certaines statistiques à la fois sur le site du
+DDTP (à propos de ce qui est vraiment traduit) et sur le site des <url
+id="http://www.debian.org/intl/l10n/" name="statistiques de traduction
+ Debian centralisées"> (à propos de ce qui est intégré dans les paquets).
+ <p>
+Pour les pages web, chaque équipe l10n a accès au CVS correspondant et les
+statistiques sont disponibles sur le site des statistiques de traduction Debian
+centralisées.
+ <p>
+Pour la documentation générale à propos de Debian, le processus est plus ou
+moins le même que pour les pages web (les traducteurs ont accès au CVS), mais
+il n'y a pas de page de statistiques.
+ <p>
+Pour la documentation spécifique aux paquets (pages de manuel, documents info,
+autres formats), presque tout est encore à faire.
+ <p>
+Le plus notablement, le projet KDE gère la traduction de ses documentations de la
+même façon que ses messages de programme.
+ <p>
+Il existe un effort pour gérer les pages de manuel spécifiques Debian au sein
+d'un <url id="http://cvs.debian.org/manpages/?cvsroot=debian-doc" name="dépôt
+ CVS spécifique">.
+
+ <sect id="l10n-faqm">FAQ I18N & L10N pour les responsables
+ <p>
+Voici une liste des problèmes que les responsables peuvent rencontrer concernant
+l'i18n et la l10n. Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
+consensus sur ces points au sein de Debian et que ce ne sont que des conseils.
+Si vous avez une meilleure idée pour un problème donné ou si vous êtes en
+désaccord avec certains points, vous êtes libre de fournir vos impressions pour
+que ce document puisse être amélioré.
+
+ <sect1 id="l10n-faqm-tr">Comment faire en sorte qu'un texte soit traduit
+ <p>
+Pour traduire des descriptions de paquet ou des questionnaires debconf, vous n'avez
+rien à faire, l'infrastructure du DDTP répartira le matériel à traduire aux
+volontaires sans besoin d'interaction de votre part.
+ <p>
+Pour tous les autres matériels (fichiers gettext, pages de manuel ou autre
+documentation), la meilleure solution est de placer votre texte quelque part sur
+l'Internet et de demander sur debian-i18n la traduction dans différentes
+langues. Certains membres des équipes de traduction sont abonnés à cette liste
+et ils prendront soin de la traduction et du processus de relecture. Une fois
+qu'ils ont fini, vous recevrez de leur part votre document traduit dans votre
+boîte aux lettres.
+
+ <sect1 id="l10n-faqm-rev">Comment faire en sorte qu'une traduction
+ donnée soit relue
+ <p>
+De temps en temps, des personnes indépendantes traduiront certains textes
+inclus dans votre paquet et vous demanderont d'inclure la traduction dans le paquet.
+Cela peut devenir problématique si vous n'êtes pas familier avec la langue
+donnée. C'est une bonne idée d'envoyer le document à la liste de diffusion l10n
+correspondante en demandant une relecture. Une fois celle-ci faite, vous devriez
+avoir plus confiance dans la qualité de la traduction et l'inclure sans crainte
+dans votre paquet.
+
+ <sect1 id="l10n-faqm-update">Comment faire en sorte qu'une traduction
+ donnée soit mise à jour
+ <p>
+Si vous avez certaines traductions d'un texte donné qui traînent, chaque fois
+que vous mettez à jour l'original, vous devriez demander au précédent
+traducteur de mettre à jour sa traduction avec vos nouveaux changements. Gardez à
+l'esprit que cette tâche demande du temps ; au moins une semaine pour
+obtenir une mise à jour relue.
+ <p>
+Si votre traducteur ne répond pas, vous pouvez demander de l'aide sur la liste de
+diffusion correspondante. Si tout échoue, n'oubliez pas de mettre un
+avertissement dans le document traduit, indiquant que la traduction est un peu
+obsolète et que le lecteur devrait se référer au document d'origine si possible.
+ <p>
+Évitez de supprimer complètement une traduction à cause de son obsolescence. Un
+vieux document est souvent mieux que pas de documentation du tout pour les
+personnes non anglophones.
+
+ <sect1 id="l10n-faqm-bug">Comment gérer un rapport de bogue concernant
+ une traduction
+ <p>
+La meilleure solution peut être de marquer le bogue comme « suivi au développeur
+amont » (<em>forwarded to upstream</em>) et de faire suivre le bogue à la
+fois au précédent traducteur et à son équipe (en utilisant la liste de diffusion
+debian-l10n-XXX correspondante).
+<!-- TODO: add the i18n tag to the bug? -->
+
+ <sect id="l10n-faqtr">FAQ I18N & L10N pour les traducteurs
+ <p>
+Lorsque vous lirez cela, gardez à l'esprit qu'il n'y a pas de
+procédure générale dans Debian concernant ces points et que, dans tous les cas,
+vous devriez collaborer avec votre équipe et les responsables des paquets.
+
+ <sect1 id="l10n-faqtr-help">Comment aider l'effort de traduction
+ <p>
+Choisissez ce que vous désirez traduire, assurez-vous que personne ne travaille
+déjà dessus (en utilisant votre liste de diffusion debian-l10n-XXX),
+traduisez-le, faites-le relire par d'autres personnes dont c'est également la
+langue maternelle sur votre liste de diffusion l10n et fournissez-le au
+responsable du paquet (voir le point suivant).
+
+ <sect1 id="l10n-faqtr-inc">Comment fournir une traduction pour
+ inclusion dans un paquet
+ <p>
+Assurez-vous que votre traduction est correcte (en demandant une relecture sur
+votre liste de discussion l10n) avant de la fournir pour inclusion. Cela
+gagnera du temps à tout le monde et évitera le chaos qui résulterait d'avoir
+plusieurs versions du même document dans les rapports de bogue.
+ <p>
+La meilleure solution est de remplir un bogue standard contenant la traduction
+sur le paquet. Assurez-vous d'utiliser l'étiquette « patch » et
+n'utilisez pas une gravité supérieure à « wishlist » car l'absence de
+traduction n'empêche jamais un programme de fonctionner.
+
+ <sect id="l10n-best">Meilleures pratiques actuelles concernant la l10n
+ <p>
+<list>
+ <item>
+En tant que responsable, ne modifiez jamais les traductions en aucune façon (même
+pour reformater l'affichage) sans demander à la liste de diffusion l10n
+correspondante. Vous risquez, par exemple, de casser le codage du fichier en
+agissant ainsi. De plus, ce que vous considérez comme une erreur peut être
+correct (ou même nécessaire) pour une langue donnée.
+ <item>
+En tant que traducteur, si vous trouvez une erreur dans le texte d'origine,
+assurez-vous de l'indiquer. Les traducteurs sont souvent les lecteurs les plus
+attentifs d'un texte donné et s'ils ne rendent pas compte des erreurs qu'ils
+trouvent, personne ne le fera.
+ <item>
+Dans tous les cas, rappelez-vous que le problème principal avec la l10n est
+qu'elle demande la coopération de plusieurs personnes et qu'il est très facile
+de démarrer une guerre incendiaire à propos de petits problèmes dûs à des
+incompréhensions. Donc, si vous avez des problèmes avec votre interlocuteur,
+demandez de l'aide sur la liste de diffusion l10n correspondante, sur
+debian-i18n ou même sur debian-devel (attention, cependant, les discussions sur
+la l10n tournent très souvent à l'incendie sur cette liste :)
+ <item>
+Dans tous les cas, la coopération ne peut être atteinte qu'avec un
+<strong>respect mutuel</strong>.
+</list>
+
+
+ <appendix id="tools">Aperçu des outils du responsable Debian
+<p>
+Cette section contient un aperçu rapide des outils dont dispose le responsable.
+ Cette liste n'est ni complète, ni définitive, il s'agit juste d'un guide
+ des outils les plus utilisés.
+<p>
+Les outils du responsable Debian sont destinés à aider les
+ responsables et libérer leur temps pour des tâches plus cruciales. Comme le dit
+ Larry Wall, il y a plus d'une manière de le faire.