                    Instrucciones para los mentores de ports

  The FreeBSD Ports Management Team

   Revision: fd2ce49dd1

   Copyright (c) 2011 Thomas Abthorpe, Chris Rees

   Last modified on 2019-06-06 20:53:50 +0000 by Sergio Carlavilla Delgado.
   [ Split HTML / Single HTML ]

     ----------------------------------------------------------------------

   Tabla de contenidos

   1. Guia para las relaciones mentor/aprendiz

1. Guia para las relaciones mentor/aprendiz

   Esta seccion esta destinada a ayudar a desmitificar el proceso de
   orientacion (mentoria), asi como a promover abiertamente una discusion
   constructiva para adaptar y desarrollar las directrices. En nuestras vidas
   tenemos demasiadas reglas; no somos una organizacion gubernamental que
   impone una regulacion, sino un colectivo de personas afines que trabajan
   para lograr un objetivo comun, manteniendo la garantia de calidad del
   producto que llamamos arbol de ports.

  1.1. ?Por que hacer de mentor?

     * La mayoria de nosotros, fuimos guiados en el proyecto, asi que
       devolvamos el favor ofreciendo guia a alguien mas.

     * Tiene un impulso irresistible de traspasar conocimiento a otros.

     * !Es un castigo habitual y esta cansado de hacer los commits del buen
       trabajo de otra persona!

  1.2. Mentor/Comentor

   Razones para una coorientacion:

     * Diferencia significativa de zona horaria. !Los mentores accesibles y
       disponibles a traves de IM son extremadamente utiles!

     * Barrera de idioma potencial. Si, FreeBSD esta muy orientado al ingles,
       al igual que ocurre en el resto del area del desarrollo de software,
       sin embargo, tener un mentor que hable un idioma nativo puede ser muy
       util.

     * !ENOTIME! Hasta que haya un dia de 30 horas y una semana de 8 dias,
       algunos de nosotros no tenemos mucho tiempo para dedicar. Compartir la
       carga con otra persona hara que sea mas facil.

     * Un mentor novato puede beneficiarse de la experiencia de un
       committer/mentor senior.

     * Dos cabezas piensan mas que una.

   Razones para la mentoria en solitario:

     * No trabaja bien con otras personas.

     * Prefiere tener una relacion de uno a uno.

     * Las razones para la cotutoria no le interesan.

  1.3. Expectativas

   Esperamos que los mentores revisen y prueben todos los parches propuestos,
   al menos durante un periodo inicial con una duracion mayor a una o dos
   semanas.

   Esperamos que los mentores se responsabilicen de las acciones de su
   aprendiz. Un mentor debe hacer un seguimiento con todos los commits que el
   aprendiz hace, tanto los aprobados como los implicitos.

   Esperamos que los mentores se aseguren de que sus aprendices lean el
   Manual del Porter, la Guia para el manejo de informes de problemas, y la
   Guia del Committer. Si bien no es necesario memorizar todos los detalles,
   cada persona debe tener una vision general de estas cosas para ser parte
   efectiva de la comunidad (y evitar tantos errores de novato como sea
   posible).

  1.4. Seleccion de un aprendiz

   No hay una regla definida sobre que hace que un candidato este listo;
   puede ser una combinacion de la cantidad de PR que ha enviado, la cantidad
   de ports mantenidos, la frecuencia de las actualizaciones de los ports y/o
   el nivel de participacion en un area especifica de interes como GNOME,
   KDE, Gecko u otros.

   Un candidato no deberia de tener timeouts, responder a las solicitudes y,
   en general, ser util en el soporte de sus ports.

   Debe haber un historial de compromiso, ya que es ampliamente entendido que
   la capacitacion de un committer requiere tiempo y esfuerzo. Si alguien ha
   estado mas tiempo, y ha observado como se hacen las cosas, hay un cierto
   conocimiento acumulado previamente. Con demasiada frecuencia, hemos visto
   a un maintaner enviar algunos PRs, aparecer en el IRC y preguntar cuando
   recibiran derechos de commit.

   Estar suscrito y seguir las listas de correo es muy beneficioso. No hay
   una expectativa real de que el envio de publicaciones a las listas
   convierta a alguien en un committer, pero demuestra compromiso. Algunos
   correos electronicos ofrecen informacion sobre el conocimiento de un
   candidato y tambien como interactuan con otras personas. Del mismo modo,
   participar en el IRC puede darle a alguien un perfil superior.

   Pregunte a seis committers diferentes cuantos PRs debe enviar un
   maintainer antes de ser nominado, y obtendra seis respuestas diferentes.
   Pregunte a las mismas personas cuanto tiempo deberia estar participando,
   el mismo dilema. ?Cuantos ports deberian tener como minimo? !Ahora tenemos
   un bikeshed! Algunas cosas son dificiles de cuantificar, el mentor tendra
   que usar su mejor juicio y esperar que Portmgr este de acuerdo.

  1.5. Duracion de la tutoria

   A medida que el nivel de confianza crece y evoluciona, el aprendiz puede
   recibir derechos de commit "implicitos". Esto puede incluir cambios
   triviales en un Makefile, pkg-descr, etc. De manera similar, puede incluir
   actualizaciones de PORTVERSION que no incluyan cambios de plist. Otras
   circunstancias pueden ser formuladas a criterio del mentor. Sin embargo,
   durante el periodo de orientacion, un mentor debe verificar un aumento en
   la version de un port que afecte a los ports que dependan de el.

   Cada persona es diferente, cada aprendiz tiene una curva de aprendizaje
   diferente, el tiempo de dedicacion y otros factores influyen en el tiempo
   requerido antes de que puedan "volar en solitario". Empiricamente, un
   aprendiz debe ser observado por al menos 3 meses. 90-100 commits es otro
   objetivo que un mentor podria usar antes de finalizar con un aprendiz.
   Otros factores a considerar antes de finalizar con un aprendiz son el
   numero de errores que pueden haber cometido, QATs recibidos, etc. Si
   todavia estan cometiendo errores de novato, todavia requieren la guia de
   un mentor.

  1.6. Debate mentor/comentor

   Cuando una solicitud llega a Portmgr, generalmente viene como, "yo
   propongo a 'foo' para que obtenga derechos de commit en los ports, yo sere
   el comentor con 'bar'". Propuesta recibida, votada y ejecutada.

   El mentor es el principal punto de contacto o el "primero entre los
   iguales", el comentor es el respaldo.

   Algunas personas, cuyo nombre sera omitido, hicieron el primer commit
   aprobado por un comentor registrado. Commits similares, aprobados por un
   comentor fueron vistos en el arbol src. ?Es correcto? ?Es incorrecto?
   Parece parte de la evolucion de como se hacen las cosas.

  1.7. Expectativas

   Esperamos que los aprendices esten preparados para las criticas
   constructivas de la comunidad. Todavia hay mucha "sabiduria popular" que
   no esta escrita. Responder bien a una critica constructiva es lo que
   esperamos al analizar sus contribuciones existentes en el IRC y en las
   listas de correo.

   Les advertimos a los aprendices que algunas de las criticas que reciben
   pueden ser menos "constructivas" que otras, (ya sea por problemas de
   comunicacion lingu:istica o por ser muy quisquillosos) y lidiar con gracia
   es solo parte de estar en una gran comunidad. En caso de problemas
   especificos con personas especificas, o cualquier duda, esperamos que se
   acerquen a un miembro de portmgr en el IRC o por correo electronico.
