devel/join/nm-amchecklist.wml
Bonjour,
Voici une mise à jour de la version 1.25 vers 1.26.
A+
Jérôme
#use wml::debian::template title="Liste de contrôle pour les responsables de candidature"
#use wml::debian::translation-check translation="1.26" maintainer="Jérôme Schell"
<UL>
<LI><A HREF="#identification">vérification de l'identité</A> ;</LI>
<LI><A HREF="#philosophy">philosophie et procédures</A> ;</LI>
<LI><A HREF="#skills">compétences et tâches</A> ;</LI>
<LI><A HREF="#finalreport">rapport final d'un responsable de candidature
au comité du nouveau responsable</A> ;</LI>
<LI><A HREF="#onhold">comment mettre un candidat en attente</A> ;</LI>
<LI><A HREF="#gpgversion">compatibilité des versions de GnuPG</A> ;</LI>
<LI><A HREF="#signverify">vérification des signatures de clef</A>.</LI>
</UL>
<P>Voir également le <A HREF="nm-amhowto">Mini-HOWTO pour les responsables
de candidature</A>.
<H2><A NAME="identification">Vérification de l'identité</A></H2>
<P>Si le candidat fournit une clef publique signée par un
<A HREF="./newmaint#Member">membre</A> Debian en place,
alors le processus d'identification est accompli. La pièce d'identité
du candidat ne sera nécessaire que si la clef n'est pas signée par un
membre Debian.
Veuillez vous reporter à la page <A HREF="./nm-step2">identification</A>
de la liste de contrôle.
</P>
<P>Il existe un problème de compatibilité avec certaines versions de GnuPG.
Veuillez vous reporter à la section <A HREF="#gpgversion">compatibilité de
version GnuPG</A>.</P>
<P>Veuillez consulter également <A HREF="#signverify">ces notes</A> pour
d'importantes informations concernant la vérification de signatures.</P>
<P>Si votre candidat a besoin de l'ancienne clef pour vérification,
il peut l'envoyer avec la nouvelle clef.</P>
<P>De même, si le candidat possède uniquement une clef PGP signée par
un membre Debian, il peut l'utiliser pour vérification.
</P>
<P>
Des options de vérification supplémentaires peuvent être appliquées
s'il existe des doutes à propos d'une information particulière ou de la
personne l'ayant fournie.
Aux États-Unis certains sites internet font de la
« résolution inverse » à partir d'un numéro de téléphone et
vous fournissent ainsi le nom et l'adresse de l'abonné.
Utiliser ces services pour faire des vérifications croisées sur les
informations fournies par le candidat peut faire émerger des incohérences,
mais l'existence de ces incohérences n'implique pas le rejet automatique
du candidat. Dans ces situations, les négociations devraient trouver leur
place.
</P>
<P>
Par exemple, si la recherche grâce à la résolution inverse fournit un
autre nom que celui du candidat, demandez au candidat quel numéro de
téléphone il vous a donné. Il peut vous répondre :
« C'est le numéro de mon colocataire » ou « C'est le numéro de
mon père » ou encore « C'est le numéro de ma résidence
universitaire » ce qui vous donne alors un autre contact. Si vous pouvez
vérifier l'information fournie par le candidat, le contact nécessaire est
obtenu.
</P>
<P>
Si, du fait d'une incertitude, il ne manque plus qu'un contact au candidat,
(c.-à-d. le contact dit qu'il ne pense pas connaître cette personne),
il est possible, en dernier recours, d'utiliser le FAI du candidat pour résoudre
le problème. La plupart du temps, le candidat devra autoriser son FAI à
donner les informations sur son adresse et son numéro de téléphone.
Contactez ensuite le FAI pour lui demander confirmation des informations.
</P>
<H2><A NAME="philosophy">Philosophie et procédures</A></H2>
<p>Il n'y a pas grand chose à dire sur la vérification de la philosophie
du candidat. Voir le paragraphe du <a href="nm-amhowto#ap3">mini-HOWTO</a>
qui parle de cela.
<p>Pour s'assurer que les candidats connaissent les procédures utilisées dans
Debian, on pourra vérifier qu'ils savent ce que dit la « Référence du
développeur » à propos d'une procédure en particulier, par exemple
comment fermer un bogue, faire des NMU, etc.
<H2><A NAME="skills">Compétences et tâches</A></H2>
<p>Si un candidat rejoint Debian en tant qu'<I>empaqueteur</I>, il
doit avoir un paquet présent dans l'archive Debian, ce qu'il peut accomplir
grâce au programme de parrainage. Le responsable des comptes des
développeurs n'acceptera <strong>pas</strong> les candidats qui ont
<em>peut-être</em> l'intention de mettre quelque chose en paquet à
une date non encore déterminée.
<p>Si un candidat rejoint Debian <em>pour rédiger de la documentation</em>,
il est également recommandé qu'il ait une vision lucide du type de
documents à écrire ou à améliorer dans Debian. (la vérification de
documentation éventuellement rédigée auparavant est envisageable.)
<H2><A NAME="finalreport">Le rapport final d'un responsable de candidature au
comité du nouveau responsable</A></H2>
<P>
Le rapport final d'un responsable de candidature sur un candidat comporte deux
étapes :
</P>
<OL>
<LI>un courrier électronique au
<A HREF="./newmaint#Committee">comité du nouveau responsable</A>
expliquant comment le candidat a passé avec succès les étapes de la
liste de contrôle ;</LI>
<LI>le même rapport envoyé au
<A HREF="./newmaint#FrontDesk">réceptionnaire
<new-maintainer@debian.org></A> et au
<A HREF="./newmaint#DAM">responsable des comptes des développeurs
<da-manager@debian.org></A> en y incluant en sus :
<UL>
<LI>la clef publique GPG du candidat <A HREF="#keynote">[1]</A>
(la clef RSA/IDEA créée avec PGP n'est pas acceptée pour l'instant)
afin de l'intégrer dans le trousseau de clefs Debian,
<UL>
<LI>si la clef GPG ci-dessus n'est signée par aucun membre actuel
de Debian, mais que le candidat possède la clef PGP signée,
alors cette clef publique PGP peut être utilisée pour
identification,</LI>
<LI>si le candidat ne possède pas de clef signée par un membre
actuel de Debian, alors une pièce d'identité numérisée et
signée par ses soins peut être utilisée en guise
d'identification,</LI>
</UL>
</LI>
<LI>les comptes rendus des discussions avec le candidat pour
valider les étapes 2-4 de
<A HREF="./nm-checklist">la liste de contrôle</A>,</LI>
<LI>la demande du candidat pour son nom de compte chez Debian
(utilisé dans <compte>@debian.org)
<A HREF="#account">[2]</A>,</LI>
<LI>la demande du candidat pour une redirection d'une adresse de
courrier sur <compte>@debian.org.</LI>
</UL>
<P><A NAME="keynote">[1] Les candidats ne doivent PAS avoir qu'une clef
signée (absolument PAS).</A>
Vous pouvez le vérifier en effectuant sur leur clef
« gpg --list-key <nom du candidat ou ID clef> ».
Si vous obtenez uniquement « <nombre>D/ »
(généralement 1024) et pas « <nombre>E/IDclef »,
« <nombre>e/IDclef »,
ni « <nombre>g/IDclef », alors c'est une clef signée
DSA. Dans ce cas vous, responsable de candidature, devez demander à
votre candidat de générer une clef correcte. Ceci est indispensable
pour être enregistré.</P>
<P><A NAME="account">[2]</A> Les noms de comptes doivent comporter au
minimum 2 caractères, 3 serait mieux.</P>
</LI>
</OL>
<P>
Ceci achève la liste des obligations du responsable de candidature dans
le processus de candidature.
<A HREF="./newmaint#DAM">Le responsable des comptes des développeurs</A>
doit à présent décider si la candidature s'est terminée correctement.
</P>
<H2><A NAME="onhold">Comment mettre un candidat en attente</A></H2>
<P>Contexte :
actuellement, le meilleur moyen de mettre la candidature
« en attente » est de la rejeter avec commentaires. Lorsque le
candidat est mieux préparé à travailler sur sa candidature, il n'a qu'à
envoyer une demande à son ancien responsable de candidature.
</P>
<P>À noter :
tous les refus des responsables de candidature sont procéduraux. À tout
moment, quand le candidat sent qu'il remplit mieux les conditions pour la
candidature, il est libre de postuler à nouveau, et de réessayer.
</P>
<DL>
<DT>Premièrement, quand une candidature doit-elle être mise en attente
par un responsable de candidature ?</DT>
<DD>
<UL>
<LI>Quand un élément de la liste de contrôle n'est pas
satisfait ;</LI>
<LI>Quand le candidat a été inactif pendant trop longtemps.</LI>
</UL>
</DD>
<DT>Deuxièmement, comment un responsable de candidature peut-il le
faire ?</DT>
<DD>
<UL>
<LI>Tout d'abord laissez le champ « AM Confirms Assignment »
à « yes », ne changez pas ce champ à « no »
ce qui voudrait dire qu'un autre responsable de candidature
doit être affecté à ce candidat, ce qui n'est pas le cas ;</LI>
<LI>Ensuite réglez le champ « AM approves » sur
« no », et donnez des détails sur le refus dans le
champ « Application Manager Comments ».</LI>
</UL>
</DD>
</DL>
<P>
À tous les responsables de candidature :
libre à vous de mettre en attente tout candidat qui ne serait ni prêt,
ni volontaire, ni capable de poursuivre avec ténacité sa candidature, au même
titre qu'un autre qui n'aurait pas les compétences ou les intentions
requises par la liste de contrôle.
</P>
<H2><A NAME="gpgversion">Problème de compatibilité de version de GnuPG avec la
gestion des clefs ElGamal</A></H2>
<P><Voici une note de notre responsable des comptes des développeurs à propos
de problèmes d'incompatibilité avec GnuPG.></P>
<BLOCKQUOTE>
<P>
Malheureusement, du fait d'un bogue dans la gestion des clefs ElGamal de
GnuPG, il existe maintenant un problème déplaisant de compatibilité.
</P>
<P>
La version posant problème : les clefs ElG générées avec
GnuPG <= 1.0.1 peuvent générer anormalement de mauvaises
signatures quand elles sont vérifiées avec GnuPG >= 1.0.2. Et
<em>vice versa</em>, les clefs ElG générées avec GnuPG >= 1.0.2
peuvent générer anormalement de mauvaises signatures quand elles sont vérifiées
avec GnuPG <= 1.0.1.
</P>
<P>
La version sans problème : tous les responsables de candidature doivent
mettre à jour leur version de GnuPG à la version 1.0.4 (elle se trouve
dans Debian 2.2 r2 et dans Woody. À noter que la
version 1.0.3 comporte également des bogues, et quiconque utilise GnuPG
devrait mettre à jour à la version 1.0.4) ; si vous rencontrez des
problèmes pour vérifier les signatures d'un candidat, essayez d'ajouter
« --emulate-md-encode-bug » à la ligne de commande. Si cela résout
le problème, c'est que votre candidat possède une clef ElG boguée. Faites-lui
installer GnuPG 1.0.4 et générer une nouvelle clef. (S'il a besoin de
l'ancienne pour vérification, joignez simplement les deux dans le rapport à
da-manager@)
</P>
</BLOCKQUOTE>
<H2><A NAME="signverify">Notes importantes concernant la vérification de signatures</A></H2>
<P>Il est <B>essentiel</B> que vous utilisiez --check-sigs pour vérifier
les signatures de clefs des candidats et <B>non pas</B> --list-sigs, ceci
ne validant pas les signatures.
<P>Rappelez-vous également qu'il est toujours mieux de faire référence
à « l'empreinte digitale » (<em>fingerprint</em>) d'une clef
plutôt qu'à l'identifiant court, la probabilité d'une collision étant
nettement plus faible du fait du plus grand univers.
<HR>
<A HREF="newmaint">Retour au coin du nouveau responsable</A>
Reply to: