Hackathon cierre Common Core: Revisar y Actualizar

[CaroLaboratoria]

Como cierre del Common Core se realizará una Hackathon con el objetivo principal de que las estudiantes vivan la experiencia de tener este tipo de instancias antes de separarse a su track correspondiente.

Como propuesta inicial se plantea realizar la Hackathon con temática de películas utilizada en el Bootcamp 2017-2.

Es necesario revisar si el nivel de esta instancia es acorde al momento planteado que es posterior al proyecto 3.

Se reciben sugerencias, opiniones al respecto

Gracias!

cc/ @Laboratoria/bootcamp-coaches @diegovelezg @lupomontero @lalogf @rocioalberdi

[nerdale]

Hola @CaroLaboratoria Los coaches de SCL estuvimos conversando y nos parece un buen proyecto para el cierre, en cuanto a la parte front end tiene manipulación de data y manejo del DOM, lo que si habría que especificar/agregar el uso de test y ver la posibilidad de entregarles un boilerplate, es como han venido trabajando hasta ahora y no nos hemos centrado en que entiendan ellas como configurar su propio proyecto, instalar dependencias etc. creemos que eso es más relevante para el comienzo del track FE.

:smile:

[nerdale]

En realidad creemos que hay dos caminos:

1. Sin Boilerplate: Hará que las estudiantes estén poniendo el foco en elementos accesorios del proyecto. Si es una hackaton de 3 días donde el énfasis está en soltar la mano, codear y trabajar en equipo, no se justifica realmente el configurar todo el proyecto, los archivos de test etc., que por otro lado, sería un skill interesante para las FE pero no sé si necesariamente para las UX, especialmente en este contexto de common core, pero la estructura del proyecto en si sería más básica en comparación a las que ya han trabajado en estos meses.

2. Con Boilerplate: Seguirá con lo que conocen, enfocándose en todos los ámbitos del proyecto. En una hackatón de 3 días si bien trabajarían con una estructura ya conocida, tendrán muchas cosas más en que concentrarse, codear, test, linter js, linter html etc. pudiendo aparecer muchos focos en que concentrarse.

[CaroLaboratoria]

Gracias Ale. Mientras esperando más comentarios al respecto de los coaches, me gustaría hacer una propuesta base sobre el contexto (narración del reto). @lupomontero como este no es un proyecto propiamente tal, dónde lo propongo dentro de la estructura que ya tenemos aquí?

cc/ @Laboratoria/bootcamp-coaches @diegovelezg @lupomontero @lalogf @rocioalberdi

[lupomontero]

Gracias por tus comentarios @nerdale. Antes de decidir en qué dirección debe ir la propuesta (con o sin boilerplate), me gustaría escuchar la opinión de lxs @Laboratoria/bootcamp-coaches .

@CaroLaboratoria: como dices, este no es un proyecto propiamente dicho y creo que en este caso en particular tiene sentido manejarlo fuera de este repo (repo de la currícula). Al ser una hackathon, no tendría mucho sentido que el reto esté público (o sí? :thinking:). Qué les parece si por ahora creamos un repo privado donde podamos armar un README.md y un boilerplate (en caso decidamos incluirlo), y de ahí después lo pueden forkear.

[nerdale]

@diegovelezg ya comenzó a armar un draft para esto.

[lupomontero]

Ver #783

[lizzie136]

Agregué unos comentarios en el PR. Por otro lado, voy a poner mi comentario aquí para que no se desligue la conversación.

Desde mi punto de vista una de los principales retos del trabajo en equipo es decidir por donde comenzar. De mi parte no vería la necesidad de un boilerplate porque si un objetivo de aprendizaje es el tema de complejidad del trabajo en equipo en sí, darle un boilerplate ya comienza a dar bastantes leads de cómo sería el trabajo.

• Creería que podemos sugerir un boilerplate, pero que depende de ellas la elección de herramientas, estructura de código, tests y demas. Si pediría tests como parte del proyecto. Y un mínimo de cobertura. Quizás como hay bastante visual y aún no estoy segura que hayan visto mucho de mocking a este punto y no es un objetivo tampoco, pediría solo las funciones puras de manejo de datos.

[CaroLaboratoria]

Muchas gracias @lizzie136 ! Al final por lo menos la decisión para SCL que partió hoy, fue dejarlo sin boilerplate y enfocarnos en trabajar en todo el trabajo en equipo y en corto plazo. Cierto @nerdale ?

Quería comentar también sobre lo propuesto por @lupomontero . Al no ser un proyecto propiamente tal, genera ruido que esté dentro de la currícula oficial. Es por esto que creemos que es mejor mantenerlo al margen como dice Lupo y crear un repo privado. Así además nuestras estudiantes verán el desafío de la hackathon cuando sea el minuto y no antes.

[lizzie136]

Genial @CaroLaboratoria! De acuerdo contigo y @lupomontero , para este caso un repositorio privado sería lo ideal.

[gaposx]

Me gusta la implementación de SCL al dejarlo sin boilerplate y con enfoque en trabajo en equipo y resultados al corto plazo. Tal como en otras hackathon, el objetivo es mostrar un MVP en pocas horas; el imponer una estructura y obligar a tests como parte del proyecto me suena un poco contraproducente.

[CaroLaboratoria]

@lupomontero cómo seguimos con este tema? te parece si creamos al repo privado y migramos las Hackathones y el proyecto "Silicon Valley"/"Job Placement"?

cc/ @Laboratoria/bootcamp-coaches @diegovelezg @lupomontero @lalogf @rocioalberdi

[lupomontero]

Gracias a todxs por los comentarios :rocket: :star:

• Con respecto al proyecto job-application, veo que la versión del README.md del repo privado de curricula-ejecucion es más reciente que el que hay en este repo. Podemos considerar que ya se ha movido y borrarlo acá?
• Por otro lado, acá dejo PR al repo privado para mover también el proyecto de registro de visitantes: https://github.com/Laboratoria/curricula-ejecucion/pull/44

Cierro este issue acá y continuamos las conversaciones con respecto a estos proyectos en particular en el otro repo :secret: