Instrucciones para los Mentores de Ports

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.


1. Guía para las Relaciones Mentor/Aprendiz

Esta sección está destinada a ayudar a desmitificar el proceso de orientación (mentorship), así como a promover abiertamente una discusión constructiva para adaptar y desarrollar las directrices. En nuestras vidas tenemos demasiadas reglas; no somos una organización gubernamental que impone una regulación, sino un colectivo de personas afines que trabajan para lograr un objetivo común, manteniendo la garantía de calidad del producto que llamamos árbol de ports.

1.1. ¿Por qué hacer de mentor?

  • La mayoría de nosotros, fuimos guiados en el proyecto, así que devolvamos el favor ofreciendo guía a alguien más.

  • Tienes un impulso irresistible de traspasar conocimiento a otros.

  • ¡Es un castigo habitual y estás cansado de hacer los commits del buen trabajo de otra persona!

1.2. Mentor/Co-mentor

Razones para una co-orientación:

  • Diferencia significativa de zona horaria. ¡Los mentores accesibles y disponibles a través de IM son extremadamente útiles!

  • Potencial barrera de idioma. Sí, FreeBSD está muy orientado al inglés, al igual que ocurre en el resto del área del desarrollo de software, sin embargo, tener un mentor que hable un idioma nativo puede ser muy útil.

  • ¡ENOTIME! Hasta que haya un día de 30 horas y una semana de 8 días, algunos de nosotros no tenemos mucho tiempo para dedicar. Compartir la carga con otra persona hará que sea más fácil.

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

  • Dos cabezas piensan más que una.

Razones para la orientación en solitario:

  • No trabajas bien con otras personas.

  • Prefieres tener una relación de uno a uno.

  • Las razones para la co-tutoría no te interesan.

1.3. Expectativas

Esperamos que los mentores revisen y prueben todos los parches propuestos, al menos durante un período inicial con una duración mayor a una o dos semanas.

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

Esperamos que los mentores se aseguren de que sus aprendices lean el Porter’s Handbook, el PR handling guide, y el Committer’s Guide. Aunque no es necesario memorizar todos los detalles, todo committer necesita tener una visión general de estas cosas para ser una parte efectiva de la comunidad (y evitar tantos errores de principiante como sea posible).

1.4. Selección de un Aprendiz

No hay definida una regla que haga que un candidato esté listo; puede ser una combinación del número de PRs que han enviado, el número de ports que mantiene, la frecuencia de las actualizaciones de los mismos y/o el nivel de participación en un área de interés particular como GNOME, KDE, Gecko u otras.

Un candidato no debería de tener timeouts, responder a las solicitudes y, en general, ser útil en el soporte de sus ports.

Debe haber un historial de compromiso, ya que es ampliamente entendido que la capacitación de un committer requiere tiempo y esfuerzo. Si alguien ha estado más tiempo, y ha observado cómo 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 cuándo recibirán derechos de commit.

Estar suscrito y seguir las listas de correo es muy beneficioso. No hay una expectativa real de que el envío de publicaciones a las listas convierta a alguien en un committer, pero demuestra compromiso. Algunos correos electrónicos ofrecen información sobre el conocimiento de un candidato y también sobre cómo interactúa con otras personas. Del mismo modo, participar en el IRC puede darle a alguien un perfil superior.

Pregunta a seis committers diferentes cuántos PRs debe enviar un maintainer antes de ser nominado, y obtendrás seis respuestas diferentes. Pregunta a las mismas personas cuánto tiempo debería estar participando, el mismo dilema. ¿Cuántos ports deberían tener como mínimo? ¡Ahora tenemos un bikeshed! Algunas cosas son difíciles de cuantificar, el mentor tendrá que usar su mejor juicio y esperar que portmgr esté de acuerdo.

1.5. Duración de la tutoría

A medida que el nivel de confianza crece y evoluciona, el aprendiz puede recibir derechos de commit "implícitos". 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 período de orientación, un mentor debe verificar un aumento en la versión de un port que afecte a los ports que dependan de él.

Cada persona es diferente, cada aprendiz tiene una curva de aprendizaje diferente, el tiempo de dedicación y otros factores influyen en el tiempo requerido antes de que puedan "volar en solitario". Empíricamente, un aprendiz debe ser observado durante al menos 3 meses. 90-100 commits es otro objetivo que un mentor podría usar antes de finalizar con un aprendiz. Otros factores a considerar antes de finalizar con un aprendiz son el número de errores que pueden haber cometido, QATs recibidos, etc. Si todavía están cometiendo errores de novato, todavía requieren la guía de un mentor.

1.6. Debate mentor/co-mentor

Cuando una solicitud llega a portmgr, generalmente viene como, "yo propongo a 'foo' para que obtenga derechos de commit en los ports, yo seré el co-mentor con 'bar'". Propuesta recibida, votada y ejecutada.

El mentor es el principal punto de contacto o el "primero entre iguales", el co-mentor es el backup.

Algunas personas, cuyo nombre será omitido, hicieron el primer commit aprobado por un co-mentor registrado. Commits similares, aprobados por un co-mentor fueron vistos en el árbol src. ¿Es correcto? ¿Es incorrecto? Parece parte de la evolución de cómo se hacen las cosas.

1.7. Expectativas

Esperamos que los aprendices estén preparados para las críticas constructivas de la comunidad. Todavía hay mucha "sabiduría popular" que no está por escrito. Responder bien a una crítica constructiva es lo que esperamos al analizar tus contribuciones existentes en el IRC y en las listas de correo.

Advertimos a los aprendices de que algunas de las críticas que reciben pueden ser menos "constructivas" que otras, (ya sea por problemas de comunicación lingüística o por ser muy quisquillosos) y que lidiar bien con ello es solo parte de estar en una gran comunidad. En caso de problemas específicos con personas específicas, o cualquier duda, esperamos que os acerquéis a un miembro de portmgr en el IRC o por correo electrónico.


Last modified on: 20 de julio de 2022 by Fernando Apesteguía