2. ¿Qué es un hackathón?
Una experiencia de trabajo colaborativo para
trabajar en proyectos de desarrollo de
software
3. ¿Para qué sirve?
Para dar un empujón a los proyectos
granadinos participantes en el certamen +
visibilizar el software libre + los proyectos que
participan.
6. Educar al colaborador
Explicadle lo necesario para que comiencen
a participar en el proyecto. Nunca será todo
lo necesario. Preved sesión de
entrenamiento personal.
7. Incluir al colaborador
No todos van a ser informáticos, ni van a
tener el mismo nivel. Aún así, deberéis
preparar una tarea para él o ella.
8. Ayuda de la OSL
Problemas con GitHub + difusión del
proyecto + testeo + lo que se pueda.
9. Tareas para todo el
mundo
Analizar, programar, pero también probar,
diseñar, documentar, escribir manuales,
traducir, buscar modelos de negocio, crear
iconos, crear historias de usuario, controlar la
marcha del proyecto, plan de comunicación,
diseñar casos de uso...
10. Y vosotros en todas
Cada tarea, un issue, cada issue debe
resolverse con un commit, cada commit se
refiere a un issue. Si no os fiáis, fork + pull
request.
11. Más vale que sobre, que
no que falte
Es mejor que tengáis que dejar de hacer
alguna tarea, a que vuestra parroquia se
aburra sin nada que hacer.
13. Guía de (buenas)
prácticas
Nombres de clases, de variables, dónde van
las llaves, quién es la persona que decide lo
que va en el código o no, hashtag propio,
plantillas para la documentación...
14. Incorporación de código
Tened un procedimiento claro de
incorporación de código: qué condiciones
debe cumplir, qué tests debe pasar, quién lo
aprueba, quién lo integra, qué pruebas debe
pasar una vez integrado.
15. ¡Integración continua!
● Si no lo tenéis, puedeser laprimeratarea.
● Y parahacer integración continua, hacen falta
tests.
– Puedeser latarea0.
16. Buscad una metodología
de trabajo
SCRUM, programación por parejas... lo que
más os convenga, pero tened una.
Y siempre trabajar con hitos + issues.
17. Cread una lista de
tareas
== issues en GitHub.
En principio para 4-5 personas x 24 horas,
pero puede haber más (o menos).
Recordad: no todos son informáticos.
18. No planifiquéis ningún
trabajo para vosotros
mismos
Tendréis bastante con ir apagando fuegos,
explicando cosas, integrando lo que hagan
otros y ayudando a la gente.
19. Recuerda que hay un fin
de semana por medio
Y tendréis que prever algún sitio, durante
todo el tiempo o parte.
20. ¡Usad tickets!
Github y el resto de las plataformas tienen un
método fácil de asignar tareas.
21. Gran poder conlleva gran
responsabilidad
Los que asistan os están dando su tiempo.
Vosotros tenéis que darles, al menos, el
vuestro. + Reconocimiento + invitarlos a café
o a pizza.
22. El hackathón es
programación +
comunicación
Designad fotógrafo Flickero/Picasero+
instagramero + YouTubero + twittero +
bloguero + Facebookero + G+ero + cronista
(puede ser un colaborador externo)
No os van a faltar usuarios, pero tratad de atraer a todo el mundo. Las razones por la que una persona elige un proyecto u otro son sólo técnicas en una enésima parte (que puede ser la cuarta).
Y los colaboradores van a ser de todo tipo. No vayáis a contar si usáis este lenguaje súper raro o Gradle o Shippable. Interesarlos en EL PROYECTO
Las primeras sesiones del hackatón serán en plan taller, pero preparad unas transparencias para explicar lo necesario, tanto para los técnicos como los no técnicos.
Si necesitáis presentaciones sobre git, GitHub y cosas así pedidlas a la OSL. También hay bastantes presentaciones sobre temas diversos. No perdáis el tiempo preparando una presentación, buscad alguna que haya por ahí. Dedicadle tiempo a organizar el proyecto.
Y siempre debéis dar permiso a los usuarios para que hagan el commit. En el trabajo colaborativo todos las colaboraciones deben estar acreditadas.
Como casi todos tenéis github, decidles simplemente que se descarguen los clientes de GitHub en su ordenador.
Pero, evidentemente, tampoco mandéis tareas por mandar... Agrupad las tareas en hitos y comprobad de esa forma cómo se va avanzando en cada hito.
O haced el último commit, incluyendo un TODO con mucho DO.
Si no sabéis lo que es la integración continua, quizás este es el momento de aprenderlo http://about.travis-ci.org/docs/user/getting-started/. Usad también la metodología SCRUM que os van a enseñar (o la que os apetezca) para ir integrando los cambios.
Programación por parejas http://en.wikipedia.org/wiki/Pair_programming
Ahora mismo hay 106 personas inscritas, pueden aparecer entre 40 y 50.
Pero puede que haya gente que llegue tarde o se quede en su casa. Prevé una forma fácil de comunicación: tickets en la forja, hangout, lo que sea.
Puede ser un bar que tenga la uni cerca (y llegue el WiFi), un sótano en vuestra casa... Desgraciadamente no hemos podido encontrar un local en esta ocasión.
GitHub, además, permite fácilmente cerrar o referenciar tareas desde los commits. Esto lo hemos dicho al menos tres veces, pero conviene repetirlo. La dinámica de crear y cerrar tickets es una forma genial de ver el avance de un proyecto y anima a los que los cierran (o a los que no lo han hecho todavía).
El colaborador puede diseñar un plan de comunicación, por ejemplo, y coordinar a quien se encargue de todo eso.
Cerrad muchos hitos (o uno solo) y que se vea actividad en las forjas. Los que participéis en el CUSL, haced referencia a él siempre que podáis.