Contribuir

Las contribuciones útiles suelen nacer de que alguien topa con algo: una página se comporta de forma inesperada, un ajuste no hace lo que el manual daba a entender, una frase de la documentación admite dos lecturas, un paso da por supuesto un acceso que no existe. De eso está hecho un proyecto mejor, y describir bien uno de esos puntos ya es una contribución.

No hace falta arreglar nada para ayudar. Un relato preciso de lo que esperaba, de lo que ocurrió en su lugar y del documento que estaba siguiendo suele valer más que un parche, porque muestra en qué consiste el trabajo de verdad.

Una contribución es una propuesta, y quienes mantienen el proyecto deciden qué aceptan. Un cambio puede adoptarse tal cual, ajustarse, quedar en espera o rechazarse: porque no encaja con para qué sirve el proyecto, porque movería un límite trazado a propósito, porque no es correcto o simplemente porque nadie ha tenido tiempo de revisarlo todavía.

Lo que eso no afecta es su propia copia. La licencia ya le da derecho a modificar el software para usted y a distribuir su propia versión, sin pedir permiso a nadie. Devolver una mejora al proyecto es lo que la hace útil para los demás: por eso se hace, y por eso nadie está obligado a hacerlo.

Lo esperado y lo ocurrido. La diferencia es el fallo. «Cambié el idioma y el selector siguió en inglés» dice algo; «la web está rota» no dice nada.

Dónde ocurre. La versión de Foundation que usa el sitio, la página o la ruta y —si solo afecta a un idioma— el idioma concreto. Un fallo en un idioma y otro en todos son trabajos distintos.

Qué cambió usted. Un proyecto Foundation nuevo y un sitio ya adaptado son casos diferentes: un fallo de la plataforma y uno del sitio construido sobre ella no se investigan igual.

El mensaje literal. El texto del error suele ser el camino más corto a la causa, y contarlo con palabras propias elimina justo los detalles que importan.

Qué ha probado ya. Evita repetir trabajo y a veces demuestra que la documentación llevó en la dirección equivocada: eso también es un fallo, solo que de la documentación.

Si quiere aportar trabajo técnico y no solo informar de algo, las expectativas del proyecto están en el repositorio, y conviene leerlas antes de dedicar tiempo a un cambio. Tres documentos las reúnen: las reglas de funcionamiento para agentes de programación describen cómo se trabaja dentro de una instalación de Foundation; la arquitectura explica las capas, los límites y la dirección de las dependencias; el manual de validación fija qué debe demostrar una comprobación — incluida la regla de que ninguna capacidad puede anunciarse por encima del nivel que su implementación y sus pruebas verifican realmente.

Estos documentos son la disciplina de mantenimiento del proyecto, no un reglamento de contribución. No dicen nada sobre lo que usted puede hacer con su propia copia: eso lo regula la licencia. Describen cómo se mantiene coherente este código y son sinceros sobre la capacidad disponible: un número reducido de responsables revisa lo que llega, y un cambio que trae sus propias pruebas, describe con claridad el problema que resuelve y no incluye ediciones ajenas al asunto tiene muchas más probabilidades de ser aceptado que otro que deja a los demás el trabajo de entenderlo.