Open diegovelezg opened 1 year ago
Mil gracias por levantar esto @diegovelezg.
Sólo comento para levantar un punto que es una de las conclusiones que me llevé del trabajo de mi equipo en el offsite en Lima la semana pasada y es que durante todo este año, en el equipo de currícula no hemos levantado ni recibido feedback de nuestras usuarias, lo que en UX es una de las reglas básicas del diseño de servicios, es algo en lo que estamos fallando en Web Dev. Con @unjust lo habíamos dejado mapeado en este issue #1242 y creo que sería bueno que empecemos a levantar formas de ir recibiendo feedback de las estudiantes con respecto a la currícula/enunciados de proyecto en particular. En caso de ser necesario, creo que podemos pedir ayuda al BC de UX para que nos guíen con cómo empezar a hacer eso!
Ya conversaermos mejor pero creo que, como con todo lo que "diseñemos", necesitamos ciclos de feedback de nuestras estudiantes. Quizás esa deba ser parte de las responsabilidades del team de currícula (quizás)
@mfdebian a propósito de varias conversaciones sucediendo, creo que el punto del rango de tiempo estimaso podría se un parámetro de cada proyecto ¿no? así como idioma, programa (AKA track), etc.
Sería de mucha utilidad para poder hacer análisis y reportes para facilitar la operación.
cc @adsoncostanzifilho @CaroLaboratoria
Notas de weekly devs:
relacionado https://github.com/Laboratoria/bootcamp/issues/1242
Hito 1 : SOLAMENTE puedes hacer fork desde master. Punto Deadline: lunes 16 enero Anunciamos en reg
A propósito de los cambios al parser del una "regla" que podríamos considerar es que no se pueda pasar a producción cambios a un proiyecto/tópico de un idioma pero no del otro. Es una manera de asegurar que está siempre en sincro y así aseguramos la "calidad" de nuestro material.
¿qué opinan?
100% de acuerdo! nos ayudará a mantener sincronicidad!
Muy tarde a la conversación. Creo los coaches deben poder hacer algunos cambios para su cohort. Por ejemplo - quitamos Vue en Burger Queen, una decision que tomamos en basado de tiempos de ellas, y la disponibilidad de coaches. Tambien - agregamos "que puede resolver individual o en dupla" a lab notes por algunas que necesitan otra oportunidad a fortalecer git collaborativa.
No se si este te refiere a los cambios, cambios sencillo asi son necesarios depende en el cohort, mas que todo en los ultimos proyectos. Pero no he visto cambios extremo, el dark web de proyectos, 😆 en mi tiempo como coach.
Muy tarde a la conversación. Creo los coaches deben poder hacer algunos cambios para su cohort. Por ejemplo - quitamos Vue en Burger Queen, una decision que tomamos en basado de tiempos de ellas, y la disponibilidad de coaches. Tambien - agregamos "que puede resolver individual o en dupla" a lab notes por algunas que necesitan otra oportunidad a fortalecer git collaborativa.
No se si este te refiere a los cambios, cambios sencillo asi son necesarios depende en el cohort, mas que todo en los ultimos proyectos. Pero no he visto cambios extremo, el dark web de proyectos, laughing en mi tiempo como coach.
@unjust justamente, creo que podríamos diferenciar qué cosas son completamente decisión de cada equipo si cambiar o no (como las que mencionas). Eso sería parte del plan.
El problema
Lo que necesitamos
Mis ideas para la discusion:
Se deben usar los README tal y como están en la rama master a menos que se quiera proponer un cambio/mejora.
No puede haber un "Mercado negro" de cones de READMES que se expanden como el COVID de cohort a cohort.
Si se quiere proponer un cambio/mejora:
Las reglas claras en el readme del repo
Si existe un patrón claro de necesidades recurrentes que no están cubiertas en los proyectos actuales, lo que se espera es que se definan algunos criterios para diseñar nuevos proyectos.
@mfdebian @unjust @lisperaza @merunga @OfeliaR @CaroLaboratoria