CUR : reglas de uso de proyectos

diegovelezg commented 1 year ago

El problema

Hoy cada equipo hace un repo para la ejecución cambiando a veces de manera TOTALMENTE discrecional lo que mejor piensan.
El consenso pre-existente tiende a diluirse y perderse conforme van cambiando las personas del euipo.
No tenbemos reglas claras que eviten discrecionalidad y divergencia indeseables.
Siempre queremos y necesitamos probar mejoras pero no hay un proceso definido para hacerlo de manera consistente y quie nos permita decidir no solamente basándonos en opiniiones.

Lo que necesitamos

Una clara descripción del modus operandi para utilizar los readme del repo (AKA reglas de juego).
Una definición de proceso sobre cómo modificar para probar y luego "devolver" lo aprendido a la currícula.
Volver a poner un rango de tiempo para completar el proyecrto en función de un análisis simple (TBD cc @adsoncostanzifilho ). Esta sección nadie debería quitarla (por ejemplo)

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:
- Se abre un issue planteando el problema que se quiere resolver, las razones de la solución que se plantea y la manera en que se espera "medir" el impacto del cambio.
- Quien hace la propuesta está en la obligación de regresar a conmpartir los aprendizajes y, de ser pertinente, proponer cambio con un PR.
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

mfdebian commented 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!

diegovelezg commented 1 year ago

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)

diegovelezg commented 1 year ago

@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

diegovelezg commented 1 year ago

Notas de weekly devs:

Necesitamos terminar de entender por qué suceden los "mercados negros".
Sigamos discutiendo y definiendo el problema.
Si bien entendemos que hoy es un problema cultural, es un problema hace 5 años y los problemas siguen ocurriendo.
Una idea es tomar el control del script para hacer las versiones para cada cohort.
Necesitamos plicar métido científico para nuestros cambios mejoras.

relacionado https://github.com/Laboratoria/bootcamp/issues/1242

diegovelezg commented 1 year ago

Hito 1 : SOLAMENTE puedes hacer fork desde master. Punto Deadline: lunes 16 enero Anunciamos en reg

diegovelezg commented 1 year ago

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?

mfdebian commented 1 year ago

100% de acuerdo! nos ayudará a mantener sincronicidad!

unjust commented 1 year ago

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.

diegovelezg commented 1 year ago

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.

Laboratoria / curriculum