[RFR] wml://devel/join/{nm-amhowto.wml,nm-amchecklist.wml}
#use wml::debian::template title="Mini-CÓMO para Gestores de solicitud de Nuevos Desarrolladores de Debian"
#use wml::debian::translation-check translation="1.30" maintainer="Fernando
Cerezal"
<UL>
<LI>Copyright Julian Gilbey <jdg@debian.org>, Septiembre de 2000</LI>
<LI>Este documento está cedido al dominio público.</LI>
</UL>
<P>
La fuente de todo conocimiento son las páginas del Nuevo Desarrollador.
Empiece en
<A HREF="newmaint">http://www.debian.org/devel/join/newmaint</A>
y eche un vistazo hasta que se familiarice con los conceptos. Ahí se
describen sus responsabilidades como GS (Gestor de Solicitud).</P>
<P>
Como GS, debería estar suscrito a la lista de correo de Nuevos
Desarrolladores: debian-newmaint@lists.debian.org. Siéntase libre de pedir
ayuda allí; ¡somos una lista amigable e intentamos ayudar a los voluntarios
a entrar en el proyecto! Tenga en cuenta que ésta es una lista archivada de
forma pública, de manera que las preguntas de naturaleza estrictamente
personal deberían ser dirigidas al Recepcionista (<I>Front Desk</I>)
de forma privada. Además, evite por favor enviar cosas como
identificaciones fotográficas a esta lista.</P>
<P>
Las otras páginas web cruciales son la base de datos:
<A HREF="http://nm.debian.org/";>http://nm.debian.org/</A>.
Recibirá una cuenta de acceso ahí (y no está cifrada, de manera que no use
una clave delicada); vea el final de la página. Esta base de datos se usa
para registrar el progreso de sus candidatos. Además podrá especificar
la cantidad de candidatos que desea controlar al mismo tiempo (vaya al
enlace "Your Profile"
que hay al lado para hacerlo). Si alguna vez le falta tiempo para tomar
a su cargo más candidatos, basta con cambiar este número a cero.</P>
<P>
El resto de las páginas de la base de datos son bastante autoexplicativas.
Si alguna vez tiene un candidato que tarda mucho en responder o que
necesita esperar un par de meses (vacaciones o lo que sea), siempre puede
dejarlo "pendiente" de manera que pueda pasar a otro candidato. Hay un
campo de texto "AM Comments"
para anotar las razones para esta acción, o para indicar cualquier
información significativa de interés para el recepcionista
y el DAM (Gestor de cuentas de desarrolladores).</P>
<P>Las tres direcciones de correo de interés son:</P>
<DL>
<DT>Lista de NM: debian-newmaint@lists.debian.org</DT>
<DD>Esta lista de correo cubre todos los aspectos del proceso de
Nuevos Desarrolladores, y la utiliza el grupo de NM (recepcionista,
Gestores de Solicitud, Gestor de Cuentas de Desarrolladores,
etc.) y otros para discutir asuntos de administración,
solicitantes y el proceso de Nuevos Desarrolladores. Esta lista de
correo es pública y se archiva, así que, por favor, no envíe
información muy personal a ella.</DD>
<DT>Recepcionista: new-maintainer@debian.org</DT>
<DD>Es donde se envían las solicitudes al principio, y donde se
envían los informes finales. Se debe dirigir aquí cualquier pregunta
personal sobre solicitudes individuales que sea inapropiada para un
foro público.</DD>
<DT>Gestores de Cuentas de Debian (DAMs): da-manager@debian.org</DT>
<DD>Lugar donde se envía también el informe final. Los DAM son
responsables de crear las cuentas en las máquinas de Debian y de
añadir las claves GPG al llavero (<I>keyring</I>). También toman las
decisiones finales sobre cada solicitud, como delegados oficiales
del Líder del Proyecto Debian para el proceso
de Nuevos Desarrolladores. ¡No moleste innecesariamente a los DAM, ya
que suelen estar muy ocupados!</DD>
</DL>
<P>
Por último, para facilitarle la vida, encontré útil crear algunas cartas
modelo, que adjunto más adelante como sigue:</P>
<P>
Tenga en cuenta que esto se mantiene sólo por su valor histórico.
Realmente debería usar los nuevos <A HREF =
"http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/templates/?cvsroot=nm-templates";>nm-templates</A>.
Sepa también de algunos comentarios útiles sobre producir buenos informes para AM (lea el <a href =
"http://lists.debian.org/debian-newmaint/2003/debian-newmaint-200303/msg00018.html";>primer</a>
y <a href =
"http://lists.debian.org/debian-newmaint/2004/debian-newmaint-200402/msg00010.html";>segundo</a>
correo con comentarios).</P>
<UL>
<LI><A HREF="#ap1">Apéndice 1: Ejemplo de mensaje inicial</A></LI>
<LI><A HREF="#ap2">Apéndice 2: Ejemplo de mensaje sobre tareas,
procedimientos y una introducción a la filosofía</A></LI>
<LI><A HREF="#ap3">Apéndice 3: Ejemplos de preguntas sobre filosofía</A></LI>
<LI><A HREF="#ap4">Apéndice 4: Ejemplo de informe para la lista de GS
(posiblemente firmada con GPG y enviada también a
debian-newmaint-admin@lists.debian.org); debería ser adjunta
en el informe final al
Recepcionista/DAM</A></LI>
<LI><A HREF="#ap5">Apéndice 5: Ejemplo de informe para el
Recepcionista y el DAM (firmada con GPG y enviada a
new-maintainer@debian.org y da-manager@debian.org)</A></LI>
</UL>
<strong>Nota del traductor</strong>: Se han mantenido los apéndices en el
inglés original, ya que será el idioma en que sean enviados.
<HR>
<H3><A NAME="ap1">APENDICE 1: EJEMPLO DE MENSAJE INICIAL</A></H3>
<PRE>
Hello *****!
I have just been appointed Application Manager for your Debian
maintainership application.
As a first step, have you checked out the New Maintainer corner of the
website? Have a look at http://www.debian.org/devel/join/newmaint,
and especially at the checklist referred to from there. That's what
we'll have to work through together.
So, if you can start by letting me have the following, we should be
able to progress fairly quickly:
- GPG key (preferably signed by a current developer or certification
authority)
- If your GPG is not signed by a current developer, you will need to
also provide a piece of GPG-signed digitally photo ID (let me know
if this is a problem; there are other ways to handle this step, but
this is the easiest)
- your preferred account name for the Debian machines
- the email address you would like to be subscribed to debian-private
Finally, please tell me about yourself and what you intend to do
for Debian (and how this fits in with The Social Contract). Also, how
you came to Linux and free software, and why you want to volunteer your
time. It would be nice if I could post some biographical information about
you to a public mailing list, so other developers can get to know you.
Please indicate which parts I may publish, and which not.
If you have packaged an application for Debian already, please give
me a URL where I can get the sources (the .diff and .orig) and the
package itself (the .deb).
Looking forward to helping you through the process. The next step is
"Philosophy and Procedures" -- I will ask you a few questions by e-mail
which you have to answer.
</PRE>
<HR>
<H3><A NAME="ap2">APÉNDICE 2: EJEMPLO DE MENSAJE SOBRE HABILIDADES,
TAREAS E INTRODUCCIÓN A LA FILOSOFÍA</A></H3>
<PRE>
"Skills" and "Philosophy".
The next thing we have to figure is whether you yet know enough to
maintain a Debian package, and if not, let me help you! You've said
what you intend to package; have you attempted to do so yet? It's
often easiest if you take over an existing package at first: then you
get to see how someone else has done it. You should also read how the
Bug Tracking System (BTS) works: see /usr/share/doc/debian/bug* or
http://bugs.debian.org/.
A word on mailing lists: there are quite a lot of Debian mailing lists
now and packaging-related packages, and I'd just like to check with
you whether you know about the key ones. I think all of the packages
are listed as dependencies of task-debian-devel, but you may not be
aware of what you have got.
Packages:
dpkg-dev All of the primary tools needed to put a Debian package
together: dpkg-buildpackage, dpkg-source, etc.
debhelper A very useful set of scripts designed to make
debian/rules files more readable and uniform.
debian-policy
Describe the policy relating to packages and details of
the packaging mechanism. Cover everything from
required gcc options to the way the maintainer scripts
(postinst etc.) work, package sections and priorities,
etc. An absolute must-read. Also useful is the file
/usr/share/doc/debian-policy/upgrading-checklist.txt,
which lists changes between versions of policy.
doc-debian Lots of useful Debian-specific documentation: the
constitution and DFSG, explanation of the Bug Tracking
System (BTS), etc.
maint-guide
The New Maintainer's Guide to making Debian packages.
devscripts Lots of useful (and not-so-useful) scripts to help build
packages.
developers-reference
Lots of information on procedures and the like.
dupload Automatically upload packages to the archive once they
or dput are built.
fakeroot Build packages without having to be root.
It's not half as bad as it seems at first, but the long-term
advantages to the maintainer and user of having such detailed
descriptions of package building should be clear ;-)
And as for mailing lists, you do not really need to read lots, but the
most significant ones are probably:
debian-announce: Major public announcements
debian-devel-announce: Major announcements to the developer community
These two lists are must-subscribes. Everything else is optional. I
abbreviate 'debian-' to '-' from now on!
-security-announce:
security updates to stable
-private: you'll be subscribed automatically when your new-maintainer
application is accepted; sensitive discussions, flamewars
etc. You can unsubscribe if you wish.
-devel: general mailing list for developer issues
-policy: where possible changes to debian-policy are discussed
There are many others; check the mailing list page on the web site
for details.
The other thing we have to discuss is "philosophy".
Have you read the Debian Social Contract
(/usr/share/doc/debian/social-contract.txt)? Do you agree to follow
it in your Debian-related work? We'll ask some more detailed
questions next time around.
</PRE>
<HR>
<H3><A NAME="ap3">APENDICE 3: EJEMPLO DE PREGUNTAS SOBRE FILOSOFIA</A></H3>
<PRE>
Philosophy
----------
We have to check that you understand the Social Contract and the Debian
Free Software Guidelines (DFSG). Have you read them? If not, please
do so. You can find them in /usr/share/doc/debian or on
http://www.debian.org
First, please explain the key points of the Social Contract and the
DFSG _in your own words_ (15-20 lines).
Secondly, a few questions, based on them:
- Donald Knuth, author of TeX, insists that no-one has the right to
modify the source code of TeX, and that any changes must be made using
"change files" (a sort of patch file). Is this allowed for a program
for the main section of Debian?
- What is Debian's (current) approach to non-free software? Why? Is
non-free part of the Debian System?
- Debian was offered a Debian-specific license to package a certain
piece of software (I forget which). Would we put it in main?
- Do you know (and can you explain) the difference between free speech
and free beer? Is Debian mainly about free speech or free beer?
- The e-mail client pine is in non-free. Can you tell me the
difference between main, contrib and non-free? Do you know what's
wrong with Pine's current license in regard to the DFSG? (If you
don't know this, never mind).
- At http://people.debian.org/~wolfie/mpg123_copyright you can
find the license of mpg123. Can you tell me why this program
is non-free according to the DFSG?
Do you agree to uphold the Social Contract and the DFSG?
If you are accepted as a Debian developer, you will get accounts
on the Debian machines. Have you read the Debian Machine Usage
Policies (DMUP) at http://www.debian.org/devel/dmup ? Do you
accept them?
I'm sure you have read the Debian Developers' Reference at
http://www.debian.org/doc/packaging-manuals/developers-reference/
- What are Non-Maintainer Uploads (NMUs) and when would you do an NMU?
- Tell me 3 different methods to close a bug in the BTS.
- What would you do if a bug was reported against your package and
you are not able to fix it yourself?
- You've just heard about this great program and you would like to package
it. What would you do?
- Do you know what 'lintian' is? Why is it useful?
- What does version 3.4-2.1 mean? What Debian control file would you
put this in? (Hint: NMU)
- You have a package in contrib, why would it have to go there? What could
you do (in theory at least) to get it into main?
- If you had a file in your package which usually gets changed by a system
administrator for local settings, how would you make sure your next
version of the package doesn't overwrite it?
- What would you do if you wanted to retire from the project and let
other developers maintain your packages?
</PRE>
<HR>
<H3><A NAME="ap4">APENDICE 4: EJEMPLO DE INFORME PARA LA LISTA AM</A></H3>
<PRE>
Report for new developer applicant:
Summary: Accept/Don't accept
1. Background
-------------
2. Identification
-----------------
3. Philosophy and Procedures
-----------------------------
4. Tasks and Skills
-------------------
</PRE>
<HR>
<H3><A NAME="ap5">APENDICE 5: EJEMPLO DE INFORME PARA EL RECEPCIONISTA Y DAM</A></H3>
<PRE>
Front Desk/DAM Report for new developer applicant:
Summary: Accept/Don't accept
1. The applicant's photo ID which is digitized and signed by the
applicant (if necessary)
* Attached/Not necessary
2. The applicants GPG (or PGP if needed) public key for Identification
* Attached
3. Logs of the discussions with the applicant to satisfy steps 2-4 in
the checklist.
* Attached [do not edit out any important contents; however, feel
free to remove unimportant mail headers (but do retain From, Date,
etc) and please remove big attachments such as .orig and .diff files
sent during the T&S stage.]
* Also attached: summary as sent to AM list
4. The applicants GPG public key (RSA/IDEA keys created by PGP are not
accepted now) to sign his (or her) Debian packages. This will be
incorporated into the Keyring of Debian
* Attached/As in 2
5. The request from the applicant for their account name on Debian
(used as <account>@debian.org)
* ???
6. The request from the applicant for the email address which will be
used to forward the emails at <account>@debian.org.
* ???
</PRE>
<HR>
<A HREF="./nm-amchecklist">De vuelta a "Nota para Gestores de solicitud"</A>
#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.
Remítase 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: