Observaciones Dataverse DEV012

[JuanCarlosHM]

• No es claro como utilizar cada una de las partes del proyecto, por ejemplo como funcionan los archivos view y main. fue de los mayores retos de las estudiantes
• De este proyecto al otro el nombre de main e index puede causar confusion (sobre todo por que reutilizan código)
• Las estudiantes se sienten confundidas respecto a los valores del dataset que no se usan
• El test y en general el proyecto nunca plantea de que tipo tiene que ser la función renderView, que puede funcionar sin mayor problema o con un objeto o con un arreglo, en ese sentido debemos ser más explícitos con ello ya que afecta el tema de los test de OAs
• Las estudiantes comentan que no es claro como es que el html se relaciona con el resultado del proyecto. Les fue dificil el uso de las nuevas etiquetas propuestas en el ejemplo
• Comentan que el html fue confuso en la parte de los atributos de las etiquetas
• El formulario de PF debería evaluar temas como el uso de los microdatos
• El uso de microdatos no es claro, lo cual puede causar frustración al momento de pasar el test:
  • li tiene atributo "itemtype"'
  • i.getAttribute('itemscope')).not.toBeNull()
• La reutilización de clases es incompatible con el test
  • header no tiene atributo "class"
• El test: “elementos li tienen un class con CSS” solo es descrito al ejecutar los test, cuando debería ser visible en el readme
• El uso de modelo de caja en los li no es explicito en el readme
• El uso de map, de sort y de reduce en el 2do proyecto es innecesario. Se asume que las estudiantes ya logran entender callbacks y ciclos después de un proyecto que tiene una duración de 2 a 3 sprints. El uso de cualquiera de los 3 debería ser suficiente, incluyendo el ciclo for (foreach, for of, for in)
• El uso de parseInt ParseFloat o ParseNumber es muy ambiguo. Muchos proyectos de las estudiantes lo agregan sin ser necesario (solo para pasar los test).
• No hay razón para preferir el uso de forEach sobre for en este y en ningún otro proyecto
• Existe un test que crea un ciclo infinito en los OAs de prompt (sospechamos que es el test: Debe ser una URL válida)
• Es muy difícil para las estudiantes cubrir el requerimiento de los 80 a 100 caracteres en chatGPT en la propiedad “description” del dataset
• La expresión regular: /^([a-z]+)((A-Z)+)$/ evita palabras en minúscula que no estén intercaladas con palabras en mayúscula (solo una palabra escrita en minúscula cumple la notación camelCase), se sugiere el cambio por la siguiente: /^[a-z]+([A-Z][a-z]+)*$/
  • De cualquier forma ambas son incapaces de validar una frase del estilo: “holamundo”, por lo cual considero que el test en realidad es innecesario.
• En los test no se especifica que deben tener un data set de prueba para correr los oas de html.
• No se especifica que las imágenes del data set deban ser estrictamente una URL con formato https (causando error en caso esté localmente).
• Las pruebas e2e están sujetas a una versión específica de node, causando que estudiantes con un S.O con node inferior al soportado (+v14) no puedan ejecutarlo.
• Limitación en los ciclos a usar (incluso si la estudiante únicamente empieza dominar la base del ciclo for, no puede ser usada y se pide forEach).
• Las pruebas buscan estrictamente hacer uso de etiquetas específicas y que a su vez, estas no se encuentren dentro de otras etiquetas (entre sections, div, nav, etc), lo cual no se precisa en el readme.

---

Update:
Creo con los comentarios abajo y entre los PRs #1695 #1672 #1676 hemos intentado responder y modificar con este feedback.

[unjust]

Gracias @JuanCarlosHM - voy revisando los puntos con otros en el equipo y planeando los cambios.
Te busco si tengo preguntas sobre las observaciones.

[unjust]

• No es claro como utilizar cada una de las partes del proyecto, por ejemplo como funcionan los archivos view y main. fue de los mayores retos de las estudiantes

Intentamos explicar los responsabilidades de cada archivo aqui
https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcmainjs
https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcviewjs

No se si ellas no estan leyendo esta parte o si podemos explicar mejor cual son sus responsabilidades. En los Q+A's debemos revisar estos puntos.

[unjust]

• De este proyecto al otro el nombre de main e index puede causar confusion (sobre todo por que reutilizan código)

Decidimos los nombres no ser iguales explicatamente porque no quiere dar la sensacion que van copiando index-> index o main->main. Creo index es un convencion mas usado en SPAs entonces pensamos que este seria bueno por Dataverse Chat.

[unjust]

• Las estudiantes se sienten confundidas respecto a los valores del dataset que no se usan

Hm. Puede ser que van utilizandolos en Dataverse Chat que no usan en Dataverse. Con los requisitos de propiedades queremos dar suficiente data para ellas pueden usar en filtrar/sort/statistica. Puede ser que ellas pueden hacer un prompt mas adelante para limpiar los propiedades que no usan. O podemos decir en el readme que las propiedades que no usan no son un problema, es parte de ejercicio a usar el prompting para tener un resultado especifica.

[unjust]

• El test y en general el proyecto nunca plantea de que tipo tiene que ser la función renderView, que puede funcionar sin mayor problema o con un objeto o con un arreglo, en ese sentido debemos ser más explícitos con ello ya que afecta el tema de los test de OAs

Si planteamos aqui - https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcviewjs
Deberia resaltarlo en otro parte o explicarlo en otra forma?

[unjust]

• Las estudiantes comentan que no es claro como es que el html se relaciona con el resultado del proyecto. Les fue dificil el uso de las nuevas etiquetas propuestas en el ejemplo
• Comentan que el html fue confuso en la parte de los atributos de las etiquetas

Cual etiquetas especificas? Los selects o lis ?

[unjust]

• El formulario de PF debería evaluar temas como el uso de los microdatos

Mmmm no se si vamos agregar un OA de microdatos. Pero este puede ser dentro de HTML semantica porque estamos agregando semantica a los elementos

[unjust]

• El uso de microdatos no es claro, lo cual puede causar frustración al momento de pasar el test:

  • li tiene atributo "itemtype"'
  • i.getAttribute('itemscope')).not.toBeNull()

Se que microdatos es algo nuevo, pero es parte de HTML spec. Aqui estamos poniendo un ejemplo de como se ve el HTML con los attributos itemscope itemtype y itemprop
https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#4-funcionalidades

Como podemos hacer este parte mejor?

[unjust]

• La reutilización de clases es incompatible con el test

  • header no tiene atributo "class"

• El test: “elementos li tienen un class con CSS” solo es descrito al ejecutar los test, cuando debería ser visible en el readme

Decimos aqui https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#css
Uso de selector class para los items que puede ser mejor como Uso de selector class para los <li>
Se que el proyecto tiene muchos requisitos de OAs, pero no creo es mal si se realizan que su codigo falta algo en el momento correr los tests. Pero tenemos que asegurar que el mensaje de test es claro y entendible. Fue entendible?

[unjust]

• El uso de modelo de caja en los li no es explicito en el readme

Si no es. Queremos asegurar que aun estan logrando OAs de box-model, y pensamos que los items deberian tener alog de margin o padding. Quiza necesitamos evaluar que en todo el codigo hay uso de box model y no solo los li.

[unjust]

• El uso de map, de sort y de reduce en el 2do proyecto es innecesario. Se asume que las estudiantes ya logran entender callbacks y ciclos después de un proyecto que tiene una duración de 2 a 3 sprints. El uso de cualquiera de los 3 debería ser suficiente, incluyendo el ciclo for (foreach, for of, for in)

En verdad un punto de data lovers fue trabajar con arreglos usando estos metodos. Puede ser que exigiendo todo no es correcto (por ejemplo puede hacer sin map o sin reduce) y podemos exigir solo algunos.

Tambien aqui es el hecho que solo por no tener un OA logrado 100% no debe parar ellas hacer Project Feedback. Quiza necesitamos cambiar el lenguaje de README para ser flexible en eso.

[unjust]

• El uso de parseInt ParseFloat o ParseNumber es muy ambiguo. Muchos proyectos de las estudiantes lo agregan sin ser necesario (solo para pasar los test).

Voy a ver donde pedimos eso, tampoco creo es necessario. Quiza fue algo llevado de text Analyzer sin pensar!

[unjust]

• No hay razón para preferir el uso de forEach sobre for en este y en ningún otro proyecto

Quiza "preferir" es muy fuerte y el tests debe ser relajada. Pero diria que un estudiante que queda usando for cuando puede usar forEach deberia aprenderlo.

[unjust]

• Existe un test que crea un ciclo infinito en los OAs de prompt (sospechamos que es el test: Debe ser una URL válida)

Aha! QUiza eso es que estamos invesitgando. Gracias! https://github.com/moniyama/DEV012-dataverse/pull/6#issuecomment-1801929663

[unjust]

• Es muy difícil para las estudiantes cubrir el requerimiento de los 80 a 100 caracteres en chatGPT en la propiedad “description” del dataset

Ok. Podemos cambiar eso quiza, pero el punto de description es que sea mas largo que short description. No pueden agregar "que sea entre 80n a 100..." al prompt?

[unjust]

• La expresión regular: /^([a-z]+)((A-Z)+)$/ evita palabras en minúscula que no estén intercaladas con palabras en mayúscula (solo una palabra escrita en minúscula cumple la notación camelCase), se sugiere el cambio por la siguiente: /^[a-z]+([A-Z][a-z]+)*$/

Aqui? https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/tests-read-only/oa/oa-prompting.spec.js#L112

• De cualquier forma ambas son incapaces de validar una frase del estilo: “holamundo”, por lo cual considero que el test en realidad es innecesario.

🤔 vamos conversar si no deberia exigir eso o al menos que mainField es camelcase

[unjust]

• En los test no se especifica que deben tener un data set de prueba para correr los oas de html.

Ok resaltamos eso un poco mas. Probable pensamos que era obvio porque sin data no puede generar el html.

[unjust]

• No se especifica que las imágenes del data set deban ser estrictamente una URL con formato https (causando error en caso esté localmente).

ok o quiza relajamos el regex para aceptar otros

[unjust]

• Las pruebas e2e están sujetas a una versión específica de node, causando que estudiantes con un S.O con node inferior al soportado (+v14) no puedan ejecutarlo.

Ok vamos viendo como podemos comunicar eso mejor - un version minima en bootcamp

[unjust]

• Limitación en los ciclos a usar (incluso si la estudiante únicamente empieza dominar la base del ciclo for, no puede ser usada y se pide forEach).

Voy a ver este test mas cerca. Creo que queremos que no usan for mas que forEach pero entiendo como algunas estan aun aprendiendo for

Otra vez, una falla de un test de OA no debe significar que no puede pasar por project feedback.

[unjust]

• Las pruebas buscan estrictamente hacer uso de etiquetas específicas y que a su vez, estas no se encuentren dentro de otras etiquetas (entre sections, div, nav, etc), lo cual no se precisa en el readme.

Cual pruebas fallan? Creo los selects, ul etc son libres a exisitr dentro sections, nav etc no?

[marianaLz]

• No es claro como utilizar cada una de las partes del proyecto, por ejemplo como funcionan los archivos view y main. fue de los mayores retos de las estudiantes

Intentamos explicar los responsabilidades de cada archivo aqui https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcmainjs https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcviewjs

No se si ellas no estan leyendo esta parte o si podemos explicar mejor cual son sus responsabilidades. En los Q+A's debemos revisar estos puntos.

Creo que se puede abordar desde los Q&As, a mí me parece claro. Podemos iterar con eso y si no es suficiente habrá que volverlo a redactar.

[marianaLz]

• El uso de microdatos no es claro, lo cual puede causar frustración al momento de pasar el test:

  • li tiene atributo "itemtype"'
  • i.getAttribute('itemscope')).not.toBeNull()

Se que microdatos es algo nuevo, pero es parte de HTML spec. Aqui estamos poniendo un ejemplo de como se ve el HTML con los attributos itemscope itemtype y itemprop https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#4-funcionalidades

Como podemos hacer este parte mejor?

Creo que debemos explicar un poco más cuál es la finalidad de esto

[marianaLz]

• El uso de map, de sort y de reduce en el 2do proyecto es innecesario. Se asume que las estudiantes ya logran entender callbacks y ciclos después de un proyecto que tiene una duración de 2 a 3 sprints. El uso de cualquiera de los 3 debería ser suficiente, incluyendo el ciclo for (foreach, for of, for in)

En verdad un punto de data lovers fue trabajar con arreglos usando estos metodos. Puede ser que exigiendo todo no es correcto (por ejemplo puede hacer sin map o sin reduce) y podemos exigir solo algunos.

Tambien aqui es el hecho que solo por no tener un OA logrado 100% no debe parar ellas hacer Project Feedback. Quiza necesitamos cambiar el lenguaje de README para ser flexible en eso.

apoyo la idea de ser flexibles y que puedan trabajar con uno o dos métodos. No para todas es tan claro a pesar de haber pasado por un proyecto así antes. Es parte de practicar.

[marianaLz]

• No hay razón para preferir el uso de forEach sobre for en este y en ningún otro proyecto

Quiza "preferir" es muy fuerte y el tests debe ser relajada. Pero diria que un estudiante que queda usando for cuando puede usar forEach deberia aprenderlo.

además forEach es un método propio de JS, for es mucho más genérico de otros lenguajes

[JuanCarlosHM]

• No es claro como utilizar cada una de las partes del proyecto, por ejemplo como funcionan los archivos view y main. fue de los mayores retos de las estudiantes

Intentamos explicar los responsabilidades de cada archivo aqui https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcmainjs https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcviewjs

No se si ellas no estan leyendo esta parte o si podemos explicar mejor cual son sus responsabilidades. En los Q+A's debemos revisar estos puntos.

Considero que este párrafo puede ser confuso para ellas:
Esta no es la única forma de dividir tu código, puedes usar más archivos y carpetas, siempre y cuando la estructura sea clara para tus compañeras.

Sería interesante profundizar por que sugerimos este enfoque y porqué pese a que tienen libertad de enfrentar el proyecto de otra manera, esta es la sugerida. Pese al énfasis que realizamos en los Q&A las estudiantes continuaban mostrando dificultades con este tema.

[JuanCarlosHM]

• De este proyecto al otro el nombre de main e index puede causar confusion (sobre todo por que reutilizan código)

Decidimos los nombres no ser iguales explicatamente porque no quiere dar la sensación que van copiando index-> index o main->main. Creo index es un convencion mas usado en SPAs entonces pensamos que este seria bueno por Dataverse Chat.

De text-analyzer a este proyecto, en realidad, las responsabilidades se mantienen. Entonces coincido con la idea de que puede ser interesante cambiar de dataverse a dataverse-chat el nombre de index a main, pero de text-analyzer a dataverse no considero que sea necesario

[JuanCarlosHM]

• El test y en general el proyecto nunca plantea de que tipo tiene que ser la función renderView, que puede funcionar sin mayor problema o con un objeto o con un arreglo, en ese sentido debemos ser más explícitos con ello ya que afecta el tema de los test de OAs

Si planteamos aqui - https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#srcviewjs Deberia resaltarlo en otro parte o explicarlo en otra forma?

Es suficientemente claro, pero pese a ello muchas estudiantes utilizaron esta función con objetos para renderizar elemento por elemento y después llevarla ejecución a un ciclo.

[JuanCarlosHM]

• Es muy difícil para las estudiantes cubrir el requerimiento de los 80 a 100 caracteres en chatGPT en la propiedad “description” del dataset

Ok. Podemos cambiar eso quiza, pero el punto de description es que sea mas largo que short description. No pueden agregar "que sea entre 80n a 100..." al prompt?

Por lo que logramos identificar muchas estudiantes tenían problemas ya sea en la conexión o en la misma respuesta, es decir, no es que su prompt fuera malo, sucedía que su computadora se quedaba trabada o directamente la pagina dejaba de responder. Sumado a esto muchas estudiantes tenían que curar los datos a mano ya que para que funcionara tenían que solicitar los datos uno a uno.

[JuanCarlosHM]

• El uso de microdatos no es claro, lo cual puede causar frustración al momento de pasar el test:

  • li tiene atributo "itemtype"'
  • i.getAttribute('itemscope')).not.toBeNull()

Se que microdatos es algo nuevo, pero es parte de HTML spec. Aqui estamos poniendo un ejemplo de como se ve el HTML con los attributos itemscope itemtype y itemprop https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#4-funcionalidades
Como podemos hacer este parte mejor?

Creo que debemos explicar un poco más cuál es la finalidad de esto

Sumando a esto, si dejamos un ejemplo que parta desde la ul -> li -> dl sería más claro para las estudiantes. ]
Coincido 100% en el profundizar en microdatos, ya que muchas estudiantes no se dieron a la tarea de investigar más allá de pasar el test

[Davichobits]

• El uso de microdatos no es claro, lo cual puede causar frustración al momento de pasar el test:

  • li tiene atributo "itemtype"'
  • i.getAttribute('itemscope')).not.toBeNull()

Se que microdatos es algo nuevo, pero es parte de HTML spec. Aqui estamos poniendo un ejemplo de como se ve el HTML con los attributos itemscope itemtype y itemprop https://github.com/Laboratoria/curriculum/blob/main/projects/02-dataverse/README.md#4-funcionalidades

Como podemos hacer este parte mejor?

@unjust veo que en el ejemplo se utiliza el atributo itemtype con el valor "WomenInTech". En este caso cómo definiríamos un esquema propio para la data?

[Davichobits]

• Es muy difícil para las estudiantes cubrir el requerimiento de los 80 a 100 caracteres en chatGPT en la propiedad “description” del dataset

Ok. Podemos cambiar eso quiza, pero el punto de description es que sea mas largo que short description. No pueden agregar "que sea entre 80n a 100..." al prompt?

Por lo que logramos identificar muchas estudiantes tenían problemas ya sea en la conexión o en la misma respuesta, es decir, no es que su prompt fuera malo, sucedía que su computadora se quedaba trabada o directamente la pagina dejaba de responder. Sumado a esto muchas estudiantes tenían que curar los datos a mano ya que para que funcionara tenían que solicitar los datos uno a uno.

Para generar la data que IA están utilizando?
Yo hice unas pruebas hace un par de días y ChatGPT me respondía incompleto, por más que iteraba sobre un prompt inicial, nunca lograba darme el dataset que solicitaba.
Luego probé con Copilot de microsoft y con el mismo prompt inicial me dio lo que solicitaba. De pronto se puede sugerir el probar con diferentes IAs.

[unjust]

Creo con los comentarios abajo y entre los PRs #1695 #1672 #1676 hemos intentado responder y modificar con este feedback.