Mecánica de la contribución

Una diferencia clave es el tiempo de entrega. Con cada primera contribución, llegas a un equipo (anfitrión) nuevo. En consecuencia, tendrás que conocer su base de código, las tecnologías utilizadas y también su entorno de desarrollo preferido (piensa en el marco de pruebas, el sistema de compilación). Incluso en los casos en los que este tipo de herramientas están estandarizadas, cada equipo habrá desarrollado algunas peculiaridades individuales. Además de la parte técnica, puedes encontrarte con diferencias en la comunicación (piensa en las revisiones de código). Incluso si vuelves después de un tiempo, las formas y los miembros de los equipos pueden haber cambiado. Tómate tu tiempo como lo harías para ponerte al día con un amigo al que hace tiempo que no ves y al que ahora visitas.

Date el tiempo suficiente. Empieza con la suficiente antelación para que tu trabajo esté disponible para aprovecharlo cuando lo necesites. Es mejor añadir más tiempo de holgura al principio: ya te harás una idea de los plazos de entrega una vez que trabajes con el equipo anfitrión. A menudo, notarás una reducción en el tiempo de respuesta del equipo anfitrión después de realizar algunas contribuciones con éxito. Este efecto puede observarse también en el código abierto, puede leer más sobre ello aquí.

En los equipos clásicos, todo el mundo tenía una idea de los plazos de entrega previstos. En el contexto de InnerSource puede que no sea así, ya sea por las grandes diferencias horarias (por ejemplo, Seattle, EE.UU., con PDT, frente a Berlín, Alemania, con CEST) o porque no estés disponible a tiempo completo como con tu equipo original, aunque estén en la misma ubicación física que tú. Por lo tanto, para evitar la frustración de ambas partes, la impaciencia y otros efectos que no fomentan la confianza, tendrás que gestionar explícitamente las expectativas con respecto a tus tiempos de reacción previstos. Un enfoque es reaccionar rápidamente con un "lo miraré, aunque no lo haré en los próximos días" a un comentario de un Trusted Committer si sabes que sólo podrás atenderles dentro de unos días. Lo ideal es que les proporciones una estimación aproximada de cuándo tendrás tiempo de echar un vistazo a su aportación. Hacerlo así genera confianza mediante fiabilidad, incluso a través de un contacto no físico, a larga distancia o por otros medios asíncronos. La confianza establecida te permitirá superar los baches de incertidumbre en el camino de la colaboración que tienes por delante.

InnerSource da mucha importancia a la comunicación escrita, sobre todo cuando se trata de decisiones sobre proyectos. ¿Significa esto que la comunicación en persona está prohibida?

Está claro que no: mientras que la comunicación escrita brilla por su capacidad de archivo y búsqueda, la comunicación en persona brilla por su ancho de banda. Intenta sacar tiempo para reunirte con las personas que hay tras los nombres. Si es posible, intenta reunirte con ellos mientras bebes su bebida favorita o comes algo. Cuando puedas escuchar a la gente hablar, cuando conozcas su idiosincrasia, la colaboración a distancia será más fácil.

¿Tienes una gran función que quieres aportar? Excelente. ¿No sería horrible que todo tu trabajo se desperdiciara? Eso puede ocurrir cuando el equipo anfitrión ya está construyendo algo muy similar, tiene previsto dejar de utilizar el software o no ve que lo que propones encaje en su proyecto. Este problema es frecuente, y muchas relaciones de equipo se han visto afectadas por no acordar de antemano que una contribución es adecuada.

Hazte feliz a ti mismo y al equipo anfitrión (y posiblemente ahorra algo de trabajo) obteniendo el acuerdo del equipo anfitrión sobre el diseño técnico/de usuario de la contribución antes de trabajar en los cambios y enviar un pull request. Tendrás que entender cómo quiere el equipo anfitrión que llegues a esto. Lo mejor es que preguntes a un Trusted Committer sobre la mejor manera de discutir tu propuesta.

En el ámbito del código abierto se ha demostrado una y otra vez que, si puedes elegir cómo discutir tu propuesta, deberías intentar elegir una forma escrita. Lo ideal es que elijas la forma en que los artefactos son públicos, se pueden buscar y se pueden enlazar de forma permanente para permitir que se haga referencia a tu propuesta en discusiones posteriores sobre esta futura contribución u otras contribuciones por venir - por ti o por otros.

Este tipo de acuerdo inicial de alto nivel te ahorrará tiempo en retrabajos o rechazos de pull request en el futuro.

Estupendo, te has familiarizado con el enfoque del equipo anfitrión, y están deseando recibir tu pull request. ¿Qué trampas te esperan ahora?

En primer lugar, estarás en contacto menos directo con ellos. En segundo lugar, no se espera que estés tan bien informado y seas tan competente como en los proyectos a tiempo completo que posee tu equipo. ¿Cómo puedes lidiar ahora con esto de la mejor manera posible?

Intenta examinar su documentación, los archivos de conversaciones y los artefactos de código del equipo anfitrión para desbloquearte. Esta situación es similar a la que probablemente la mayoría de la gente se encuentra cuando utiliza uno de los proyectos populares de OSS.

Al igual que en los proyectos de código abierto, pregunta al equipo anfitrión si ves que después de desbloquearte las cosas no avanzan. Las preguntas que hagas y las respuestas que recibas ayudarán a otros que vengan después a resolver los mismos problemas. Asegúrate de que tu comunicación acabe en un archivo consultable que esté estrechamente vinculado al propio proyecto. Si ves oportunidades de mejora fáciles para alcanzar dicho objetivo si aún no se ha alcanzado, puedes intentar -muy educadamente- sugerir una mejora a tu equipo anfitrión. A veces el status quo surge por pura casualidad y se mantiene así porque nadie tuvo una idea diferente o se preocupó lo suficiente. Las sugerencias de mejora pueden ser bienvenidas en estos casos. No hace ningún bien a ninguna de las partes que le des vueltas a un problema que podría resolverse en una conversación de unos minutos con alguien más informado sobre el proyecto. Está bien pedir ayuda.

Sin embargo, hay una diferencia clave, que supone una ventaja para ti y para otras personas en el futuro: En casi todos los casos deberías preferir los canales de comunicación oficiales del proyecto, que pueden ser una lista de correo, una sala de chat, un gestor de incidencias o algo similar, dependiendo del propósito de tener una forma más sincrónica o asincrónica de interactuar, o de las distintas necesidades de estructuración de la comunicación. Todos ellos suelen tener en común que se basan en texto, se archivan, se pueden buscar y vienen con enlaces estables: esto significa que tu pregunta y la respuesta quedarán escritas, y las referencias que enlaces en esas respuestas también se mantendrán accesibles. De este modo podrás beneficiarte en tu búsqueda de estos conocimientos documentados de forma pasiva. Y ayudar a los futuros colaboradores a tener la misma ventaja. Esta documentación pasiva podría incluso servir para enriquecer la documentación "oficial", en caso de que contenga joyas especialmente valiosas, como definiciones importantes que se crearon ad hoc.

Mientras trabajas, si encuentras documentación faltante (o desactualizada), hazle un favor al siguiente Colaborador y actualízala con lo que has descubierto. Los equipos de proyecto suelen estar encantados de recibir adiciones, actualizaciones o correcciones para su documentación existente: ¡acabas de encontrar otra oportunidad para contribuir! (O simplemente proporciónales amablemente un comentario sobre tu experiencia, y lo que te habría ayudado).

Todos tenemos nuestras preferencias y opiniones sobre el estilo del código, la indentación, etc. El proyecto del equipo anfitrión también las tiene. Trata de adaptarte y de coincidir con esas preferencias, incluso si no es lo que harías normalmente, e incluso si no está especificado en el proyecto `CONTRIBUTING.md`. Si no estás seguro, siempre puedes preguntar amablemente. No obstante, una contribución de invitado para una característica o una corrección de errores no es el momento de introducir una nueva forma de estructurar o formatear el código del proyecto.

El punto básico aquí es permitir que el Trusted Committer valide la contribución sin tu presencia y asegurar una fácil mantenibilidad. Imagina que has construido una característica o el manejo de una rareza irresoluble, o un importante ajuste de rendimiento, y tu código no es del todo obvio (o incluso podría parecer enrevesado / incorrecto a primera vista). Si has cubierto esto con una prueba - e idealmente has arrojado algunas palabras sobre la razón de ser de la misma en un comentario - un futuro editor conseguirá recordar el propósito del código, y la(s) prueba(s) asegurará(n) que el valor que tu código realiza se mantendrá, incluso en las nuevas implementaciones. Para conseguirlo, haz lo siguiente:

Debes asegurarte de que tu pull request incluya cualquier actualización de la documentación que sea relevante para tus cambios. Si la documentación se encuentra en un lugar diferente, asegúrate de añadirla allí y enlazarla en tu pull request.

Para que la revisión del código sea lo más fácil posible para el Trusted Committer u otras personas que lo revisen, intenta seguir estos consejos: