Y si aparece algún error de compilación, debemos saberlo inmediatamente (y siempre antes de fusionar el PR correspondiente). Tanto #2 como el tutor necesitan que compile correctamente.

La interpretación del proyecto existente en la introducción no concuerda ni está alineada con la idea inicial y principal del proyecto por lo que hay que realizar una revisión y una posterior reescritura de la misma.

Se debe manejar la colaboración en la creación de memes, permitiendo que múltiples usuarios editen un meme sin pisarse.

Esta issue, que aborda la falta de un análisis del problema, está directamente relacionada con #2 ya que sin un análisis detallado del problema, es difícil garantizar que la memoria del proyecto sea clara y coherente, lo cual es esencial para cumplir con los requisitos de los tutores y el tribunal.

Documentar este análisis no solo mejorará la calidad de la memoria, sino que también asegurará que tanto tutor como tribunal tengan una comprensión común y precisa de los desafíos a abordar, alineando así todas las historias de usuario pertinentes con los objetivos del proyecto.

Este problema de diseño de infraestructura vamos a atajarlo mediante uso del Domain Driven Design.

Se debe manejar toda la gestión de usuarios, incluyendo registro, autenticación, permisos, roles, etc.

Se debe gestionar los catálogos, memes y plantillas de memes de cada usuario.

En la sección del estado del arte aparecen nombradas algunas plataforma en relación el almacenamiento en la nube. Para llevar al lector a la página web de la plataforma en cuestión no es necesario incluirla en la bibliografía.

En vez de soluciones comerciales se deberían de haber contemplado soluciones de software libre que son más próximas y justas de comparar con el proyecto.

Aún no existe el proceso de selección de tecnología para el proyecto el cual debe estar reflejado en la memoria.

Se tiene que realizar una elección de tecnología (el lenguaje de programación va de la mano con la tecnología) de la parte del diseño. Por lo tanto antes se debe hacer:

• #21.

Se debe manejar el versionado de memes, permitiendo a los usuarios acceder a versiones anteriores y restaurarlas en caso de ser necesario.

Aún faltan las historias de usuario tras seguir con el método personas. Se crearon personas pero no sendas historias usuarios.

Han quedado algunos ficheros residuales que vienen de la plantilla a partir de la cuál se generó el repositorio del TFG.

Se debe gestionar la funcionalidad de búsqueda de memes, permitiendo a los usuarios encontrar memes específicos basándose en diferentes filtros, queries, etiquetas, etc.

En la introducción, antes de pasar a cualquier otra cosa, se tienen que formular los objetivos generales del proyecto. Los objetivos siempre van a tener la forma: Se va tratar de resolver el problema X para la persona y. Más adelante se especificará en historias de usuario, y milestones, pero el problema debe quedar claro desde el principio. Por supuesto, el problema qu ese describa tiene que tener relación con el título del proyecto, que es lo que ha sido aprobado por la comisión (y lo que va a evaluar #2).

En la sección de propuesta de estado del arte no se ha proporcionado información sobre si el proyecto se va a comercializar y de qué modo.

Vamos a realizar una modificación y personalización de la estructura de la memoria sacada de la plantilla de memorias de TFG de la ETSIIT. #2

La memoria debe contener una introducción donde se escriba acerca de la motivación, descripción y objetivos del problema a abordar.

• Motivación.
• Descripción del problema.
• Objetivos.

Issue enlazada con #2 para que el README.md se actualice con el progreso del proyecto para todo el que quiera seguir el progreso y sepa como instalar, configurar y desplegar en local la solución en desarrollo.

La UI debe facilitar la navegación por catálogos de memes, incluyendo catálogos públicos, compartidos y privados.

La UI debe incluir un editor de memes que permita a los usuarios crear memes a partir de plantillas, desde cero o modificar ya hechos. La edición debe ser con herramientas conocidas y que usualmente aparezcan en este tipo de herramientas.

Cuando se hace push de un archivo .tex no se ejecuta el workflow de latex.

Antes de producir código de DDD hay que saber con qué lenguaje/s se va a trabajar. Se documentarán todas las decisiones tomadas en la selección de el/los mismos.

Debido al comentario se ha decidido crear una issue en relación a la creación de una descripción de la memoria, de la dirección del repositorio, etc. Todo esto para satisfacer a #2. Las posibles soluciones serían:

• Una subsección más dentro del capítulo de la introducción.
• Otro capítulo en el que se exponga todo esto.

Se ha decidido realizar todo esto en el capítulo 4 referente a la planificación. Se actualizará la memoria respecto a lo ya realizado en el TFG junto con las decisiones tomadas y sus respectivas justificaciones.

Issue para tenerlo en cuenta en el capítulo de la implementación creado a raíz de este comentario:

Aparte de que aquí no es relevante, por favor no pongas los criterios que crees que va a querer leer el tribunal en vez de los que usas. Si vas a probar una por una la velocidad de las herramientas usando un benchmark y tomar una decisión con respecto al resultado, hazlo (si es que la velocidad es siquiera relevante, claro). Si no, no lo pongas.
Esto no es un trabajo de una asignatura, es una memoria de un proyecto donde tienes que documentar las decisiones tomadas.

Originally posted by @JJ in #35 (comment)

Creo que ya lo he mencionado, pero la metodología y la planificación son diferentes. La mentalidad o el marco de desarrollo son una cosa, generalmente incluida en la introducción o en un capítulo de metodología, y la planificación tiene que salir de esa metodología.
Considera, por favor, meter en su propio capítulo todo lo que corresponda a la metodología.

Originally posted by @JJ in #35 (comment)

A partir de este comentario se ha originado este issue que pretender abordar la necesidad de un capítulo de metodología en la memoria. Este capítulo va a ser incremental e iterativo estando presente a lo largo de todo el proyecto incorporando de forma continua las metodologías que se vayan utilizando en el proyecto. Por este motivo, es por lo que este issue no pertenece a ningún milestone.

La UI debe ser accesible desde cualquier dispositivo, incluyendo ordenadores, tabletas y móviles. Debe ser completamente responsiva, adaptándose a diferentes tamaños de pantalla y resoluciones.

Aún no aparecen los milestones en la introducción por lo que se va a proceder a redactarlos.

La idea de este capítulo de la memoria es describir cómo está el panorama en el problema que se trata de resolver además de realizar un avance de la propuesta basándome en la investigación realizada.

La UI debe ser intuitiva y fácil de usar, centrada en la simplicidad y claridad. Debe ser visualmente atractiva y moderna, siguiendo las buenas prácticas de UI/UX. El diseño debe facilitar la navegación rápida y eficiente.

Las personas descritas mediante la metodología no se ajustan del todo con la realidad además de ser ejemplos demasiado lejanos. Además, se considerará el utilizar las mismas personas que se mencionen en la introducción para que la memoria se sienta más cohesionada #2 .

Un error con TeXtidote puede bloquear la comprobación gramatical y ortográfica en CI. El bug se debe a que la macro de latex \lstset para el diseño de fragmentos de código no se elimina aun poniéndolo en el argumento de --remove-macros de TeXtidote.

Opciones de TeXtidote:

--output html
--check es
--dict ./diccionario/diccionario.es.txt
--ignore sh:seclen,sh:stacked,sh:nonp,sh:nobreak,sh:nsubdiv,sh:figref,lt:es:SPANISH_WORD_REPEAT_BEGINNING_RULE
--remove titlepage,titlepage,centering,textwidth,cleardoublepage,centeroffset,oddsidemargin,evensidemargin,large
--remove-macros cleardoublepage,bfseries,today,tableofcontents,listoffigures,listoftables,lstset,textit

He visto que la issue en el repositorio de TeXtidote puede ser el problema.

#2 requiere que la memoria esté escrita correctamente y que transcriba correctamente el trabajo hecho; por otro lado el desarrollo ágil hace énfasis en la calidad, y esta calidad debe reflejarse en la documentación.

Hay que refinar la introducción ya que es demasiado genérica. Debe captar la atención del lector (#2).