1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
---
title: Instrucciones para los mentores de ports
organizations:
- organization: The FreeBSD Ports Management Team
copyright: 2011 Thomas Abthorpe, Chris Rees
releaseinfo: "$FreeBSD$"
trademarks: []
---
= Instrucciones para los mentores de ports
:doctype: article
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:
:lang: es
:toc-title: Tabla de contenidos
:part-signifier: Parte
:chapter-signifier: Capítulo
:appendix-caption: Apéndice
:table-caption: Tabla
:figure-caption: Figura
:example-caption: Ejemplo
include::shared/es/urls.adoc[]
'''
toc::[]
[[port-mentor-guidelines]]
== Guía para las relaciones mentor/aprendiz
Esta sección está destinada a ayudar a desmitificar el proceso de orientación (mentoría), 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.
[[why-mentor]]
=== ¿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.
* Tiene un impulso irresistible de traspasar conocimiento a otros.
* ¡Es un castigo habitual y está cansado de hacer los commits del buen trabajo de otra persona!
[[mentor-comentor]]
=== Mentor/Comentor
Razones para una coorientación:
* Diferencia significativa de zona horaria. ¡Los mentores accesibles y disponibles a través de IM son extremadamente útiles!
* Barrera de idioma potencial. 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 mentoría en solitario:
* No trabaja bien con otras personas.
* Prefiere tener una relación de uno a uno.
* Las razones para la cotutoría no le interesan.
[[mentor-expectations]]
=== 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 con 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 link:{porters-handbook}[Manual del Porter], la link:{pr-guidelines}[Guía para el manejo de informes de problemas], y la link:{committers-guide}[Guía del Committer]. Si bien no es necesario memorizar todos los detalles, cada persona debe tener una visión general de estas cosas para ser parte efectiva de la comunidad (y evitar tantos errores de novato como sea posible).
[[mentees]]
=== Selección de un aprendiz
No hay una regla definida sobre qué hace que un candidato esté listo; puede ser una combinación 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 participación en un área específica de interés como GNOME, KDE, Gecko u otros.
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 cómo interactúan con otras personas. Del mismo modo, participar en el IRC puede darle a alguien un perfil superior.
Pregunte a seis committers diferentes cuántos PRs debe enviar un maintainer antes de ser nominado, y obtendrá seis respuestas diferentes. Pregunte 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.
[[mentorship-duration]]
=== 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 [.filename]#Makefile#, [.filename]#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 por 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.
[[mentor-comentor-debate]]
=== 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 seré 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 será omitido, hicieron el https://lists.freebsd.org/pipermail/cvs-ports/2007-September/134614.html[primer commit aprobado por un comentor registrado]. Commits similares, aprobados por un comentor fueron vistos en el árbol src. ¿Es correcto? ¿Es incorrecto? Parece parte de la evolución de cómo se hacen las cosas.
[[mentee-expectations]]
=== 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á escrita. Responder bien a una crítica 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 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 lidiar con gracia es solo parte de estar en una gran comunidad. En caso de problemas específicos con personas específicas, o cualquier duda, esperamos que se acerquen a un miembro de portmgr en el IRC o por correo electrónico.
|
