Cómo usar las plantillas de relaciones públicas de GitHub

Si realiza algún trabajo, independientemente de si es de código abierto o de código cerrado (aunque sé que la mayoría de los que leen este sitio están involucrados en el código abierto), es probable que use algún control de fuente, y probablemente sea GitHub.

Para muchos de ustedes, siguen un proyecto, contribuyen a un proyecto o manejan solicitudes de incorporación de cambios a un proyecto. ¿Y qué pasa con esos proyectos en los que trabajas en equipo?

Quizás su flujo de trabajo sea algo como esto:

• creas una rama para trabajar en una característica,
• empujas la rama para detallar el trabajo que has hecho para que un compañero lo revise,
• la revisión se fusiona,
• continua.

Pero, ¿qué pones en la plantilla para la solicitud de extracción? ¿Es lo mismo cada vez o es diferente? ¿Qué pasa si el contenido del PR está relacionado con algo en Trello, Asana, Basecamp o algún otro sistema de gestión de proyectos?

Ahí es donde entran en juego las plantillas de relaciones públicas de GitHub.

Plantillas de relaciones públicas de GitHub

Puede leer todo sobre ellos en la página, pero aquí está la esencia (sin juego de palabras):

Es difícil resolver un problema cuando faltan detalles importantes. Ahora los mantenedores de proyectos pueden agregar plantillas para problemas y solicitudes de extracción a los proyectos, lo que ayuda a los colaboradores a compartir los detalles correctos al comienzo de un hilo.

Y la idea es simple: creamos plantillas para problemas y solicitudes de extracción para otros que brindan un nivel de información que deben completar antes de enviar un problema o una solicitud de extracción.

Esto nos ayuda, ya que los mantenedores saben cualquier información que necesitamos antes de investigarla. Además, puede permitirnos vincular a un problema anterior, un boleto anterior, cualquier cosa anterior relacionada con el proyecto.

Por ejemplo, supongamos que está trabajando en un proyecto y desea incluir la siguiente información:

• una breve descripción de lo que hace el PR para que el mantenedor no tenga que adivinar,
• el estado del RP sobre si debería estar listo para fusionarse o si todavía está en desarrollo pero listo para alguna revisión,
• un enlace al ticket en su administrador de proyectos para el cual el PR es relevante.

No digo que esta sea la información que se requiere, pero es algo que hemos usado y que he encontrado útil (y es bueno ver que se realizan más mejoras con el tiempo ).

Pero, ¿cómo usamos esto?

El sitio es bastante claro, pero es realmente simple. Necesita los siguientes archivos en el directorio de su proyecto o en el archivo. directorio github :

• PROBLEMA_PLANTILLA
• PULL_REQUEST_TEMPLATE

Cada uno de estos debe ser un archivo de descuento que resalte exactamente qué es lo que está buscando que sus colaboradores incluyan cada vez que estén, ya sabes, contribuyendo a su proyecto de alguna manera.

Y luego, cada vez que un usuario busca informar un problema o crear una solicitud de extracción, se le solicita la información de la plantilla.

Bonito, ¿no?

No es mucho, pero…

Puede que no creas que es mucho, pero es bastante fácil ayudar a mejorar la calidad de la información que llega a un proyecto, hacer que tus colaboradores piensen en lo que están poniendo en el proyecto y luego responder en consecuencia.

Además, te ayuda a ti y al resto de tu equipo a comprender qué es lo que se va a revisar y a prepararse para cualquier cambio que pueda surgir al trabajar en estos proyectos.