Implementacion

[Slowmybrosh]

Para una correcta documentación (#8), se necesitan justificar todas las decisiones tomadas en el desarrollo del proyecto (#33). Inicialmente, en este capítulo se han añadido los siguientes apartados:

• Uso de Github
• Plataforma de la aplicación
• Lenguaje de programación ajustado a la plataforma

[Slowmybrosh]

@JJ Cuando puedas le echas un vistazo a este capítulo?

[Slowmybrosh]

@JJ He quitado las cosas prematuras o irrelevantes, añadido un minusculo parrafo de porque se utiliza github. Además de elegir una justificación del lenguaje para la plataforma, teniendo en cuenta unos pequeños requisitos.

[JJ]

Estás haciendo un PR para un issue en el que te comenté esto. Sin un problema claramente planteado, es difícil evaluar si lo hecho resuelve el problema o no.

[Slowmybrosh]

Estás haciendo un PR para un issue en el que te comenté esto. Sin un problema claramente planteado, es difícil evaluar si lo hecho resuelve el problema o no.

Debería tener creado un issue que plantee el problema de que lenguaje de programación elegir? Antes de incluir la respuesta en la documentación?

[Slowmybrosh]

Una vez más, no debes documentar lo que has elegido hasta que efectivamente lo hayas hecho en la fase de desarrollo del producto en la que estés. Todavía no has empezado a tirar las líneas de código, así que todavía no puedes hablar del lenguaje elegido. Tampoco sabes qué vas a hacer una vez lleges al nivel de abstracción del API, así que no lo hagas. En general, te repito lo mismo que antes: cuando implementes documéntalo y documentar significa explicar los retos que has tenido para tomar una decisión y lo que has considerado.

Pero como empiezo a desarrollar las líneas de código para #22 si no tengo una plataforma elegida ni un lenguaje de programación

[JJ]

Estás haciendo un PR para un issue en el que te comenté esto. Sin un problema claramente planteado, es difícil evaluar si lo hecho resuelve el problema o no.

Debería tener creado un issue que plantee el problema de que lenguaje de programación elegir? Antes de incluir la respuesta en la documentación?

Deberías

1. No poner en la documentación cosas que no has hecho todavía en el proyecto. Elegir cosas es comenzar a usarlas, y luego justificar en la documentación qué pasos se han seguido para tomar la decisión, qué se ha considerado, y por qué.
2. Crear issue que planteen problemas específicos, con soluciones específicas. "Implementación" no es un problema.
3. En general, y salvo los primeros capítulos, va a haber muy pocos issues que estén relacionados sólo con #8. Los issues son para resolver problemas de los usuarios, y #8 sirve más bien para decidir cómo se formula o qué se incluye o no en la documentación.

Conviene en todo caso que sigas una metodología un poco más sistemática para abordar el proyecto. Primero tienes que plantear la motivación, escribir los user journey, usar design thinking y la metodología de "personas" para pefilar los usuarios, crear a continuación las historias de usuario, y sobre todo, documentar todo en el primer o primeros capítulos de la memoria antes de pasar a hacer la implementación, porque esos son los pasos para los proyectos. Ya te lo puse en el issue #36, y ni siquiera le has asignado un milestone. Convendría que fueras un poco sistemático para poder llevar el proyecto a buen término.

[Slowmybrosh]

Estás haciendo un PR para un issue en el que te comenté esto. Sin un problema claramente planteado, es difícil evaluar si lo hecho resuelve el problema o no.

Debería tener creado un issue que plantee el problema de que lenguaje de programación elegir? Antes de incluir la respuesta en la documentación?

Deberías

1. No poner en la documentación cosas que no has hecho todavía en el proyecto. Elegir cosas es comenzar a usarlas, y luego justificar en la documentación qué pasos se han seguido para tomar la decisión, qué se ha considerado, y por qué.
2. Crear issue que planteen problemas específicos, con soluciones específicas. "Implementación" no es un problema.
3. En general, y salvo los primeros capítulos, va a haber muy pocos issues que estén relacionados sólo con [HU00] Miembro del tribunal - Criterios de Evaluación #8. Los issues son para resolver problemas de los usuarios, y [HU00] Miembro del tribunal - Criterios de Evaluación #8 sirve más bien para decidir cómo se formula o qué se incluye o no en la documentación.

Conviene en todo caso que sigas una metodología un poco más sistemática para abordar el proyecto. Primero tienes que plantear la motivación, escribir los user journey, usar design thinking y la metodología de "personas" para pefilar los usuarios, crear a continuación las historias de usuario, y sobre todo, documentar todo en el primer o primeros capítulos de la memoria antes de pasar a hacer la implementación, porque esos son los pasos para los proyectos. Ya te lo puse en el issue #36, y ni siquiera le has asignado un milestone. Convendría que fueras un poco sistemático para poder llevar el proyecto a buen término.

Tengo lo relativo a #36 escrito en mi documentación local, pero no subido al proyecto.

[JJ]

Una vez más, no debes documentar lo que has elegido hasta que efectivamente lo hayas hecho en la fase de desarrollo del producto en la que estés. Todavía no has empezado a tirar las líneas de código, así que todavía no puedes hablar del lenguaje elegido. Tampoco sabes qué vas a hacer una vez lleges al nivel de abstracción del API, así que no lo hagas. En general, te repito lo mismo que antes: cuando implementes documéntalo y documentar significa explicar los retos que has tenido para tomar una decisión y lo que has considerado.

Pero como empiezo a desarrollar las líneas de código para #22 si no tengo una plataforma elegida ni un lenguaje de programación

¿Cómo lo pones en la documentación si todavía no está hecho en la práctica? La documentación documenta lo que se ha hecho, y conviene que vaya en el mismo PR.