Proyectos participantes en el certamen: lista de comprobación

Aviso: Este es un post antiguo, puede que su información esté desactualizada. Si está buscando algo sobre un evento actual, tenga en cuenta que puede que este no sea el que busca.

A los participantes en el certamen de proyectos libres les animamos a que se pasen por nuestra oficina para darles una serie de ideas sobre cómo echar a andar el proyecto y qué hacer para que sea fácil colaborar con él. Es una lista de comprobación de diferentes puntos, que os vamos a poner a continuación por si no podéis pasaros por la OSL. Es también útil para el CUSL.

1. Lo más importante es la licencia. Si no tiene licencia, no es libre. Una licencia es un fichero llamado LICENSE en el directorio principal y una cabecera en cada uno de los ficheros del proyecto que haga referencia a la misma. Elegir una licencia no es trivial, pero si necesitáis que os echemos una mano, no tenéis más que preguntar.
2. Los recursos como música, imágenes, iconos y demás tienen una licencia diferente. Conviene que se agrupen en un solo directorio y se le ponga una licencia libre, normalmente Creative Commons
3. Aunque cada uno puede usar la metodología que quiera, aconsejamos usar desarrollo basado en pruebas (en alguna versión, como desarrollo basado en comportamiento). Eso implica escribir tests unitarios para cada una de las características del sistema, sus funciones, y que la cobertura sea la máxima posible. Todos los lenguajes de programación tienen un marco de test, pero si tienes duda sobre qué usar en tu proyecto, una vez más, pregunta.
4. Necesitas programar esas pruebas para añadirle integración continua, que consiste en hacer integraciones de código continuamente (en vez de hacer ciclos de programación y ciclos de integración) y, cada vez que se hace, pasar los tests programados anteriormente. Podéis usar sitios como Travis, que se configura simplemente con un fichero en YAML que especifica el entorno y dice como se pasan los tests
5. Como todos usáis git a estas alturas, podéis considerar la posibilidad de trabajar sobre varias ramas, al menos una de desarrollo y otra `master`. Así podéis trabajar especulativamente sobre la rama de desarrollo y pasar a la máster sólo cuando vayáis a incorporarlo a la publicación final.
6. En todos los proyectos de software libre es muy importante la comunicación. Abrid una cuenta de Twitter al proyecto, que también podéis configurar en GitHub para tuitear cada vez que se haga un commit. Si ya tenéis un blog, abrid una categoría para el proyecto. Si no lo tenéis, os aconsejamos que uséis GitHub pages. Tras la generación original de la página desde el panel de control, este script te puede configurar el repo para que se actualice automáticamente desde el README.md y, por supuesto, para que puedas añadir lo que desees desde él. GitHub pages usa Jekyll, y se puede usar directamente para crear un blog; Octopress funciona sobre Jekyll y permite trabajar un poco más fácilmente con blogs, pero quizás es un poco más complicado de usar. Podéis usar el que quieras, pero poned historias periódicamente con soluciones que se os haya ocurrido, tutoriales para usar lo que tengáis, tecnologías que hayáis tenido que aprender o, en general, lo que se os ocurra. Esto es imprescindible para contactar con y crear comunidad alrededor del proyecto.
7. Usad los issues de Github para organizar las tareas. Si usáis alguna otra herramienta, conviene que la conectéis con GitHub para que se refleje vuestra actividad también allí. Los issues permiten también a los usuarios comunicarse con vosotros y ver claramente el avance del mismo. También es importante: los issues se cierran siempre con un commit.
8. Tened una hoja de ruta, o al menos un fichero TODO donde indiquéis qué es lo que queréis hacer y por dónde vais. La hoja de ruta, además, incluirá cuando pensáis publicar algo y qué va a incluir; la hoja de ruta se traducirá en milestones o hitos que puedes incluir en GitHub y los issues se pueden asignar también a los Milestones. Por ejemplo, si alguien os envía un informe de error se puede asignar a un hito determinado: la versión 0.0.3, pongamos. En la hoja de ruta convendría que hubiera un hito antes del hackatón a principios de marzo y otro antes del final del certamen, a principios de junio.