[RFR] wml://devel/join/nm-amchecklist.wml
un saludo.
#use wml::debian::template title="Nota para Gestores de solicitud"
#use wml::debian::translation-check translation="1.28" maintainer="Fernando
Cerezal"
<UL>
<LI><A HREF="./nm-amhowto">"Mini-COMO para gestores de solicitud
de nuevos desarroladores de Debian"</A></LI>
<LI><A HREF="#identification">Comprobación de identidad</A></LI>
<LI><A HREF="#skills">Habilidades y Tareas</A></LI>
<LI><A HREF="#finalreport">Informe final de un gestor de solicitud al Comité-NM</A></LI>
<LI><A HREF="#onhold">Cómo dejar pendiente a un candidato</A></LI>
<LI><A HREF="#gpgversion">Dependencia de la versión de GnuPG</A></LI>
<LI><A HREF="#signverify">Verificación de firmas de clave</A></LI>
</UL>
<H2><A NAME="identification">Comprobación de identidad</A></H2>
<P>Si el candidato proporciona una clave pública firmada previamente por
un <A HREF="./newmaint#Member">miembro</A> vigente de Debian, el
proceso de identificación quedará completo. Sólo se necesitará una
identificación fotográfica en caso contrario.
Diríjase por favor a la página <A HREF="./nm-step2">Identificación</A>
en la lista de tareas.
</P>
<P>Hay un problema de compatibilidad con algunas versiones de GnuPG.
Remítase a la sección sobre <A HREF="#gpgversion">compatibilidades de
versión de GnuPG</A>.</P>
<P>Vea también <A HREF="#signverify">estas notas</A> con información
importante referente a la verificación de firmas.</P>
<P>Si su candidato necesita la clave antigua para propósitos de
verificación, puede enviarla junto a la nueva.</P>
<P>De forma similar, si el candidato sólo tiene una clave PGP que ha
sido firmada por un miembro de Debian, puede usarla para la verificación.
</P>
<P>
Se pueden ejercitar otras opciones de verificación en caso de que haya
duda al respecto de alguna información o sobre la persona que la
proporcionó. En los Estados Unidos hay sitios web que pueden hacer
"comprobación inversa" de un número de teléfono y proporcionarle el
abonado, y su dirección.
El uso de estos servicios para comprobar la validez de la información
proporcionada por el candidato, puede acarrear inconsistencias, cuya
existencia no es causa automática de rechazo. Se puede aplicar cierto
grado de negociación en estos casos.
</P>
<P>
Por ejemplo, si la comprobación inversa indica otro nombre para el
candidato, se le puede preguntar a quién pertenece el número que
proporcionó.
Puede contestar: "Es el teléfono de mi compañero/a de piso" o "es el
teléfono de mi padre" o "es el teléfono de la residencia de estudiantes"
lo cual proporciona otro punto de contacto. Si se puede verificar esta
nueva información, entonces queda establecido el contacto.
</P>
<P>
Como último recurso, en el caso de que el candidato sólo falle en un
apartado, y sea debido a falta de conocimiento, en lugar de rechazar su
identidad (por ejemplo, la persona de contacto dice no conocer a esa
persona), podemos usar el PSI (Proveedor de servicios de Internet) del
candidato para resolver el problema. En muchos casos el candidato
deberá dar permiso a su PSI para proporcionar información al respecto de
su dirección y teléfono.
En tal caso, basta contactar con el PSI y preguntar por esta
información.
</P>
<H2><A NAME="skills">Habilidades y Tareas</A></H2>
<P>Si un candidato está uniéndose a Debian <I>como empaquetador</I>,
debe tener un paquete en el archivo. El DAM (Developer Accounts
Manager/Gestor de cuentas de Debian) <strong>no</strong> aceptará
candidatos que <em>quizá</em> vayan a empaquetar algo en algún momento
desconocido en el futuro.
<P>Si un candidato está uniéndose a Debian <em>para escribir
documentación</em>, también es recomendable que tenga una visión clara de
qué tipo de documentos puede escribir o mejorar para Debian. (Es
recomendable examinar documentación escrita previamente por el
candidato, si la hay.)
<H2><A NAME="finalreport">Informe final de un Gestor de solicitud al
Comité-NM:</A></H2>
<P>
Hay dos pasos que debe dar el GS (Gestor de solicitud) en su informe final
de un candidato.
</P>
<OL>
<LI>Un mensaje de correo electrónico al
<A HREF="./newmaint#Committee">Comité-NM</A> explicando cómo han
sido satisfechos los pasos a dar en la lista de tareas.</LI>
<LI>Enviar el mismo informe al
<A HREF="./newmaint#FrontDesk">Recepcionista
<new-maintainer@debian.org></A>
y al
<A HREF="./newmaint#DAM">Gestor de cuentas de desarrolladores
<da-manager@debian.org></A>
adjuntando
<UL>
<LI>La clave pública GPG del candidato <A HREF="#keynote">[1]</A>
(en este momento no se aceptan claves RSA/IDEA generadas por
PGP) para incorporarla al llavero (<I>keyring</I>) de Debian.
<UL>
<LI>Si la clave GPG no está firmada por ningún miembro actual
de Debian, pero el candidato tiene una clave PGP
firmada, se puede usar esa clave PGP para fines de
identificación</LI>
<LI>Si el candidato no tiene una clave firmada por ningún
miembro actual de Debian, se podrá usar una
identificación fotográfica digitalizada y firmada por el
candidato</LI>
</UL>
</LI>
<LI>Registros (logs) de las charlas con el candidato destinadas
a satisfacer los pasos 2 al 4 de la
<A HREF="./nm-checklist">lista de tareas</A>.</LI>
<LI>La indicación del candidato del nombre de su cuenta en
Debian (al estilo <account>@debian.org)
<A HREF="#account">[2]</A></LI>
<LI>La indicación del candidato de la dirección a de correo a
la que reenviarlos mensajes destinados a
<account>@debian.org.</LI>
</UL>
<P><A NAME="keynote">[1] Los candidatos NO (repetimos: NO) deben
proporcionar una clave sólo para firmas.</A>
Puede comprobar esto examinando su clave con
"gpg --list-key <nombre del candidato o ID de la clave>".
Si sólo ve un "<número>D/" (1024, habitualmente) y no un
"<número>E/keyID", "<número>e/keyID", ni
"<número>g/keyID", entonces es una clave DSA sólo para
firmas. En este caso usted, el GS, debe pedir al candidato que
genere una clave adecuada. Esto es esencial para el proceso de
registro.</P>
<P><A NAME="account">[2]</A> Los nombres de cuenta deben ser
>= 2 caracteres, mejor si es de 3 .</P>
</LI>
</OL>
<P>
Esto completa las responsabilidades del GS en el proceso de solicitud. <A
HREF="./newmaint#DAM">El Gestor de cuentas de desarrolladores</A> deberá
decidir entonces si la solicitud ha tenido éxito.
</P>
<H2><A NAME="onhold">Cómo dejar pendiente a un candidato</A></H2>
<P>trasfondo:
Actualmente, la única vía razonable de dejar "pendiente" una solicitud es
rechazarla con comentarios. Cuando el candidato esté más preparado para
trabajar en su solicitud, sólo necesitará enviar una petición a su último
GS.
</P>
<P>Nota:
Todos los rechazos de los GS son procedimentales. En cualquier momento en
que el candidato sienta que puede satisfacer mejor los requerimientos de
la solicitud, es libre de volver a enviarla, e intentarlo de nuevo.
</P>
<DL>
<DT>Primero, ¿cuándo debería un GS dejar pendiente una solicitud?</DT>
<DD>
<UL>
<LI>Siempre que no se consiga satisfacer un elemento de la lista de
tareas.</LI>
<LI>Cuando haya pasado mucho tiempo sin noticias de actividad por
parte del candidato.</LI>
</UL>
</DD>
<DT>Segundo, ¿cómo hace esto un GS?</DT>
<DD>
<UL>
<LI>Primero, marque el campo «AM Confirms Assignment»
con «yes»,
ya que si lo marca como «no», estará indicando que debe ser
asignado otro GS para este candidato, lo cual no es el
caso.</LI>
<LI>Después marque el campo «AM approves»
con «no», e indique los detalles del rechazo en el campo
«Application Manager Comments».</LI>
</UL>
</DD>
</DL>
<P>
A todos los GS:
Siéntanse libres de dejar pendiente a un candidato que no esté
preparado, dispuesto, o no sea capaz de trabajar con ahínco en su
solicitud, así como aquellos que no tengan las habilidades o intenciones
precisadas por la lista de tareas.
</P>
<H2><A NAME="gpgversion">Problemas de compatibilidad de versiones en la
manipulación de claves GnuPG con problemas de incompatibilidades.</A></H2>
<P><Esta es una nota de nuestro DAM (Gestor de cuentas de
desarrolladores) sobre un problema de incompatibilidad con GnuPG.></P>
<BLOCKQUOTE>
<P>
Desafortunadamente, debido a un fallo en GnuPG con la manipulación de
claves ElGamal se ha producido un grave problema de compatibilidad.
</P>
<P>
La versión confusa: las claves ElG creadas usando GnuPG <= 1.1.1 pueden
generar firmas clasificadas como MALAS, en caso de ser
comprobadas con GnuPG >= 1.0.2. Y viceversa, las claves ElG creadas
usando GnuPG >= 1.0.2 pueden generar firmas clasificadas como MALAS, en
caso de ser comprobadas con GnuPG <= 1.0.1.
</P>
<P>
La versión más clara: todo GS debe actualizar su GnuPG a la versión 1.0.4
(está en 2.2 r2 y en woody. Tengan en cuenta que 1.0.3 tenía algunos
fallos y cualquiera que use GnuPG debería actualizar a 1.0.4); y si tiene
problemas verificando firmas de un candidato, pruebe a añadir
"--emulate-md-encode-bug" en la línea de órdenes.
Si esto corrige el fallo, su candidato tiene una clave ElG con falllos.
Indíquele que instale GnuPG 1.0.2 para generar una nueva.
(Si necesita la antigua con fines de identificación, incluya ambas en el
informe enviado a da-manager@)
</P>
</BLOCKQUOTE>
<H2><A NAME="signverify">Notas importantes respecto a la verificación de
firmas</A></H2>
<P>Es <B>esencial</B> que utilice --check-sigs para verificar las firmas
de las claves de los candidatos, y <B>no</B> --list-sigs, ya que esto no
valida las firmas.
<P>Recuerde además que siempre es mejor referirse a la "huella digital"
(fingerprint) de una clave en lugar de a su ID de clave, ya que la
probabilidad de encontrar una coincidencia es mucho menor, debido al mayor
espacio de nombres.
<HR>
<A HREF="./nm-checklist">De vuelta a "Lista de Tareas"</A>
<A HREF="./nm-step5">De vuelta al "Paso 5"</A>
Reply to: