Task: Reorganize requirements #63
Conversation
|
La estructura está bien. Okay con crear archivo separados, salvo mejor opinión en contrario haría un archivo por nivel ### de headings, aunque tampoco me opongo a que sea uno por nivel ####. El índice completo lo podemos tener en el archivo 1_1_Requisitos.md, ya que lo que hoy está en ese archivo va a moverse a otros. |
|
Bien, perfecto. Usamos |
👌🏻
|
@fmachadopiriz ¿Qué opinás de renombrar el documento de Si estás de acuerdo, lo ajusto. |
|
@fmachadopiriz Agregué tags para cada parte dentro de las subsecciones. Varias opiniones que me interesa leer al respecto:
Otra cosa que quería comentar es que evalué etiquetar según el concepto de proyecto conejo, caballo o elefante que presenta Volere. Según entiendo, estos conceptos aluden a la dimensión del proyecto y por ende a las formalidades de las que requiera, así que no sé qué tanto sería aplicable para los proyectos. Si te parece que igual puede aplicar, lo vemos y lo agregamos. Quedo atento para leer sugerencias 🔍 |
No estoy del todo seguro de renombrarlo, porque creo que no es sólo análisis, sino también relevamiento y especificación, ¿no? |
Los tags quedan buenos, están bien los colores y el casing. Lo que puede parecer confuso es a qué parte del texto aplica, cuando lo vi por primera vez pensé que capaz estaría bueno ponerlo en el propio título, pero luego me di cuenta que dentro del título hay partes requeridas y partes que no, amén de que técnicamente iba a ser complejo mezclar HTML con Markdown. Capaz que al explicarlo queda más claro. También pensé en usarlo como si fuera un tag HTML y poner uno al inicio de lo que es requerido y otro al final —y no en cada párrafo como está ahora—:
El "opcionalmente requerido" podría ser "según proyecto" o algo así. Me queda la duda si pondría otro tag para "opcional" o si todo lo que no diga explícitamente algo se asume opcional. Otra alternativa más simple es comenzar los párrafos opcionales con "Opcionalmente, ..." y los que dependan del tipo de proyecto comiencen con "Según el tipo de proyecto, ....". Visualmente los tags son más claros, pero también la edición va a ser más compleja. No tengo posición definida 100%. En caso de dejar los tags, podrían estar dentro de un link al lugar donde se explican; pero de nuevo, va a ser más complejo de editar. |
Bueno sí, tenés razón. Dejémoslo como |
|
Opa, según lo que leo, percibo que respecto al punto número 3 sobre explicar los tags, lo interpretaste como explicar la razón de por qué los tags opcionalmente requeridos son opcionalmente requeridos —para que quede claro cuándo y por qué lo son—, ¿no? No iba por acá a lo que me refería, pero me lo anoto porque creo que suma —incluso, creo que podría comenzar cada párrafo de los opcionalmente requeridos indicando cuándo son requeridos, esto es: "Si su proyecto tiene interfaz de usuario, especificar..."—. A lo que me refería en realidad era el explicar brevemente qué son los tags —y por eso proponía hacerlo en el índice—, algo del estilo "El tag Respecto a que no queda tan claro a qué parte del texto aplican los tags, estoy de acuerdo. Se me ocurre que podemos solucionarlo reordenando los párrafos y utilizando solamente un tag de cada tipo por subsección —sería algo parecido a lo que proponés—. O sea, ordenar los párrafos requeridos al principio, luego los opcionalmente requeridos, y luego cualquier otro que eventualmente podamos tener. De esta forma, podríamos hacer lo siguiente: H2 de Subsección 1 Párrafo 1. Párrafo 2. ... Párrafo N. ... ¿Cómo la ves? Y por último; sí, ajusto el tag de "opcionalmente requerido" para que sea "según proyecto" 👍🏻. |
|
Okay con esto que comentas. Expliquemos los tags en el índice como propones. Va a quedar muy bueno 💯 |
Co-authored-by: Fernando Machado Píriz <fmachadopiriz@outlook.com>
|
El último commit soluciona #45. |
¿Qué tiene este draft PR?
Hasta el momento, este PR tiene el WIP de la reestructuración de la sección de requisitos. La nueva estructura ha de adherirse a la propuesta por el template de Volere, con el objetivo de que la estructura del proyecto final maride con lo visto en los curso ANDIS I y ANDIS II. La estructura es la siguiente —va hasta el punto 17, pues son los puntos cubiertos hasta el momento—:
Otra cosa que hice por el momento, es comentar las secciones previas o "legacy" para tener de referencia, además de taggearlas con comentarios como
Must haveoMight have, dondeMust havees algo que yo entiendo como obligatorio independientemente del proyecto, mientras queMight havesería algo que puede —o, no— ser obligatorio dependiendo del proyecto y sus necesidades.¿Qué espero de esta primer review?
Dado que estamos evaluando y definiendo cómo organizar y dividir toda la sección de requisitos, lo que me interesa por el momento es que le eches un vistazo a cómo quedaría la sección que teníamos antes, pero ahora cumpliendo con la estructura del template de Volere. Tené en cuenta que no me tomé el trabajo de reescribir los párrafos para no hacer trabajo repetido luego —una vez tengamos confirmado cómo quedará la estructura final, acomodo el hilo narrativo del documento para que quede lindo 😉—.
Vayamos discutiendo aquí cualquier cosa o comentario respecto a la estructura. Yo por ejemplo arranco brindando el siguiente: me parece importante que el contenido de los cursos y la estructura del proyecto matcheen, así que me parece bárbaro que se reestructure lo que tenemos hasta el momento con ese fin 👍🏻.
También creo que para el caso en el que un lector quisiera tener un pantallazo de lo que tiene que hacer —sin necesidad de leer todo el documento—, sería beneficioso tener el documento segmentado en varios, donde cada uno cubre una subsección (sé que esta idea al menos la mencionamos durante nuestra última reunión). De esta forma, el lector podría contar con un índice y ver por arriba qué es lo que se precisa, y además esto nos da la posibilidad a nosotros de ser un poco más explicativos en cada subsección sin miedo a hacer el documento muy extenso.
Estoy atento a los comentarios por venir, e iré actualizando este PR en base a las conclusiones a las que vayamos llegando.