Guía para los proyectos participantes en el hackatón de proyectos de la UGR, donde explicamos qué hacer para atraer colaboradores en el hackatón y, si es posible, conservarlos

1. 9º Hackatón Certamen
UGR: Trucos y consejos
para proyectos
participantes
JJ Merelo
dirosl@ugr.es

2. ¿Qué es un hackatón?
Una experiencia de trabajo colaborativo
sobre 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.

4. ¿Cómo se usa?
Vayamos por partes

5. Atraer al colaborador
Tenéis unos diez minutos para contar de qué
va el proyecto y atraer a colaboradores.

6. Educar al colaborador
Explicadle lo necesario para que comiencen
a participar en el proyecto. Nunca será todo
lo necesario. Preved sesiones 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 + palmadas en la espalda +
lo que se pueda.

9. Tareas para todo el
mundo
Analizar, programar, pero también probar,
diseñar interfaz de usuario, 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 está en un
milestone y 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.

12. Previo al hackathón
¡Liberad ya el (o algo de) código y subidlo a
GitHub! (Si no lo habéis hecho)

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. Mejor práctica:
Crear un contributing.md queayudeapresentes(y
ausentes) asaber quéhacefaltay cómo seañade.

15. 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.

16. Si no ha sido probado, no
funciona

17. ¡Integración continua!
● Si no latenéis, puedeser laprimeratarea.
● Y parahacer integración continua, hacen falta
tests.
– Puedeser latarea0.

18. 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/milestones +
issues.

19. 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.

20. 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.

21. Recuerda que hay un fin
de semana por medio
Tenemos espacio en la corrala de Santiago,
pero podéis ir donde queráis.

22. 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.

23. Hackathón :=
programación +
comunicación
Designad fotógrafo Flickero/Instagramero+
instagramero + YouTubero + twittero +
bloguero + Facebookero + G+ero +
Instagramero + Snapchatero + Telegramero
cronista (puede ser un colaborador externo)

24. #hackathonugr
+ (#|@)[proyecto] + [@oslugr]

25. El lunes día 13 queremos ver versiones x+1
(o +2) de todo.
Obtened un resultado
tangible

26. El hackathón no termina
el lunes
Tratad de conservar a los colaboradores
hasta el final del concurso (y más allá)

27. Preguntas, sugerencias
y comentarios