Completa objetivo 1 - Githubissues

En principio, preferiría usar la wiki para la documentación. No obstante, debido a las restricciones de los checks, se crea una carpeta docs con el archivo docs/README.md. Esto añade flexibilidad en el futuro por si se llegase a cambiar.

Siempre tuve eso en mente, pero quizás no lo he reflejado bien.

El procesamiento puede ocurrir en tu ordenador o en un servidor. Es indiferente. La idea es que especifiques una carpeta o una serie de imágenes, y éstas se procesen. Por tanto, esta operación puede hacerse mediante la terminal, o "arrastrando" imágenes a una web, o similar. La salida entre local y remoto no cambia nada a excepción de cómo lo presentes; con un zip, por ejemplo.

Pasarlo a la nube tiene la ventaja de que puedo paralelizar y escalar el cómputo tal y como considere necesario. Esta es, al menos, la idea principal.

Y en temas de protección de datos sí que no he mencionado nada. Estaba asumiendo que todo lo que entre es tuyo, y todo lo que salga igual. En ningún momento se almacena información más allá de la imprescindible para funcionar en el momento de la ejecución.

¿Cómo debería redactar todo esto? ¿Alguna sección en específico?

Si todo "es tuyo" tendrás que pensar cuál es la "value proposition" y la lógica de negocio. ¿El usuario te está etiquetando fondos de escritorio gratis? ¿Qué ventaja tendría subirlo a la nube, cuando una aplicación de escritorio para un solo usuario sería lo más razonable? La nube cuesta pasta, ¿qué lógica de negocio vas a incluir para poder pagar lo que cuesta? (Pista: un usuario no va a pagar por tener en la nube por algo que puede solucionar con un gestor bueno de imágenes en el desktop) En cuanto a protección de datos, el problema es otro: las licencias de las imágenes. Pero mientras que todo esto tiene que ver con el producto, no es muy relevante a la hora de diseñar la hoja de ruta de programación.

Para mí, esta es una herramienta enfocada para el usuario puramente. Es una pequeña utilidad estilo Unix muy portable. En mi cabeza, es algo similar a waifu2x.

Es un programa que permite escalado de imágenes por IA con diferentes parámetros. Tiene tanto una página web específica (un frontend muy sencillico con unos servidores bastante mediocres), así como una aplicación de escritorio: waifu2x caffe (De hecho, tengo pensado incluirlo en el pipeline, pero eso ahora mismo no es muy relevante).

Esto soluciona un problema de comodidad: a veces, no siempre estamos en nuestro escritorio con la aplicación instalada. Por lo que viene muy bien tener una página en la que sueltas los archivos y los procesa rápidamente, para luego así guardarlos en algún sitio (estilo Telegram). Es algo que ya me ha pasado más de una vez: cuando quiero ponerme seriamente a analizar los resultados, uso la aplicación de escritorio. Si quiero un resultado rápido que pueda subir desde cualquier lado (portátil, móvil, un amigo me ha pedido algo...), uso la web.

Tampoco me he parado a pensar en cómo gestionar el tema de la monetización. Claro está, esto no deja de ser una asignatura de universidad y no un proyecto serio de futuro. Puede convertirse en uno, pero lo primero es aprender. Para mí, lo importante es que tiene salida para escalar, y no cómo debo hacerlo ahora mismo. Aún así, si fuera necesario, podría cargar algún sistema de publicidad estilo Adsense para cubrir mínimamente el coste del servidor, pero poco más.

Así que, dicho esto, creo que la lógica de negocio me sigue pareciendo acertada. El usuario es lo primero, y la monetización viene de forma paralela a éste. Si evolucionara hasta un punto en el que no me lo imagino todavía, podríamos, por ejemplo, tratar de vender modelos preentrenados clasificatorios a otras compañías, y ofrecerlo de forma gratuita al usuario medio.

Para mí, esta es una herramienta enfocada para el usuario puramente. Es una pequeña utilidad estilo Unix muy portable. En mi cabeza, es algo similar a waifu2x.

Me temo entonces que no es apropiada para esta asignatura. Recuerda que se trata de computación en la nube. Una herramienta para un usuario raramente será adecuada para la nube. Y no sólo por temas de latencia, disponibilidad y por supuesto, coste (subir 10 MB o bajar 10MB va a costar dinero a alguien en la nube), sino simplemente por concepto. Literalmente estás hablando de fondos de escritorio. Pero veo lo que quieres decir. En esa aplicación usan por ejemplo GPUs de NVidia (eso en la nube vale caro, pero bueno)

Es un programa que permite escalado de imágenes por IA con diferentes parámetros. Tiene tanto una página web específica (un frontend muy sencillico con unos servidores bastante mediocres), así como una aplicación de escritorio: waifu2x caffe (De hecho, tengo pensado incluirlo en el pipeline, pero eso ahora mismo no es muy relevante).

Bueno, tiene un API, así que podría ser una posibilidad. El problema es que este usuario ni siquiera está en los usuarios descritos, que todos hablan de "un programa", una aplicación de escritorio como digo arriba. Si realmente lo que buscas es algo como waifu, déjalo muy claro en los casos de uso (que, por otro lado, parecerían más casos de uso de un cliente que casos que requirieran diferentes funcionalidades)

Esto soluciona un problema de comodidad: a veces, no siempre estamos en nuestro escritorio con la aplicación instalada. Por lo que viene muy bien tener una página en la que sueltas los archivos y los procesa rápidamente, para luego así guardarlos en algún sitio (estilo Telegram). Es algo que ya me ha pasado más de una vez: cuando quiero ponerme seriamente a analizar los resultados, uso la aplicación de escritorio. Si quiero un resultado rápido que pueda subir desde cualquier lado (portátil, móvil, un amigo me ha pedido algo...), uso la web.

OK, lo veo. Por favor, añade claramente estos aspectos del caso de uso al documento correspondiente.

Vale, pero waifu no guarda. Procesa y devuelve. Eso requiere cierto trabajo, pero no tanto como procesar y almacenar. Y sobre todo almacenar requiere de una serie de recursos que te va a ser complicado integrar, salvo que te des de alta ya en Amazon o Digital Ocean y empieces a usar el almacenamiento.

Tampoco me he parado a pensar en cómo gestionar el tema de la monetización. Claro está, esto no deja de ser una asignatura de universidad y no un proyecto serio de futuro. Puede convertirse en uno, pero lo primero es aprender. Para mí, lo importante es que tiene salida para escalar, y no cómo debo hacerlo ahora mismo.

La monetización tiene importancia en tanto en cuanto es lo que realmente dirige la lógica de negocio. Y la lógica de negocio tiene importancia porque en el objetivo 3 tendrás que testear que funciona. ¿Qué vas a testear aquí? ¿Tienes ya la red neuronal entrenada? Si la tienes, ¿es una biblioteca externa? Si es una biblioteca externa, ¿qué valor aporta tu aplicación? Monetización == lógica de negocio == valor. Usar una red neuronal en todo esto es muy peligroso. No porque sean difíciles de testear, que lo son (waifu no tiene ni un test, o yo no lo he visto), sino, sobre todo, porque vas a depender de bibliotecas externas que vas a tener que incluir en tu aplicación desde el minuto 0, antes siquiera de poder hacer un test unitario (objetivo 3, repito).

Aún así, si fuera necesario, podría cargar algún sistema de publicidad estilo Adsense para cubrir mínimamente el coste del servidor, pero poco más.

Esto no es un concurso de emprendimiento. La pasta que puedas sacar de ello no es (demasiado) importante (pero mira los costes de almacenamiento en la nube y luego me dices). Lo importante es que entiendas que tu proyecto de esta asignatura tiene que tener lógica de negocio propia y que, en general, esa lógica de negocio es lo que le va a añadir valor a tu aplicación (por eso se llama de negocio) y por tanto, pensar en cómo sacarle pasta ayuda a pensar qué tipo de usuario podría estar interesado en una aplicación así y, por tanto, cuál es la lógica de negocio que tendríamos que añadir a la aplicación para satisfacer a ese usuario.

Así que, dicho esto, creo que la lógica de negocio me sigue pareciendo acertada. El usuario es lo primero, y la monetización viene de forma paralela a éste. Si evolucionara hasta un punto en el que no me lo imagino todavía, podríamos, por ejemplo, tratar de vender modelos preentrenados clasificatorios a otras compañías, y ofrecerlo de forma gratuita al usuario medio.

No hay ningún usuario en tu conjunto que entrene redes. Tampoco ninguna historia de usuario que diga cómo se entrenan ni qué datos van a necesitar. Como es una herramienta personal, no queda claro cómo van a entrenarse esas redes, ni cuantas redes van a hacer falta (de cada usuario) para que empiece a clasificar en "carpetas". Agarrándome a lo que has dicho, si el negocio es vender modelos preentrenados, ¿no será la lógica de negocio principal entrenar la red? ¿No tendrá que haber un usuario que se beneficie de eso?

Eso sólo te deja unos cuantos problemas:

La lógica de negocio tienes que programarla tú. Buena suerte con testear una red neuronal (que no digo que no se pueda, pero buena suerte). Buena suerte con testear cosas de imágenes (¿cómo generas una imagen con unas características determinadas?)

Ese problema lo vas a tener también en el TFG, por cierto
El problema del almacenamiento tendrás que resolverlo, tarde o temprano.
Relacionado con 1., tienes el problema del bootstrap. Qué hacer cuando no tengas ninguna red entrenada.

Eso te deja unas cuantas opciones.

Cambia el problema a resolver.
No uses redes neuronales para clasificación, sino heurísticas simples basadas en procesamientos rápidos de la imagen junto con, si acaso, algún algoritmo de clustering no supervisado tipo kNN. El almacenamiento de imágenes seguirá siendo un problema, pero lo será más adelante.
Sigue adelante, hasta donde puedas.

En cualquiera de los casos, tendrás que aclarar muy bien cuál es la lógica de negocio y justificar que se trate de una aplicación en la nube. Por ejemplo, las heurísticas simples no justificarán su publicación en la nube salvo que necesiten de las imágenes que suban otros usuarios; kNN sí, porque va a necesitar esas imágenes. El sistema multiusuario resolvería el problema del bootstrap, por lo menos.

Espero haberte aclarado las dudas con esto.

Creo que hay un problema muy grande en la conversación, y es que, desde el primer momento iba a usar modelos preentrenados. Eso hace que el coste de almacenamiento y cómputo baje radicalmente, y pasen a considerarse casi insignificantes.

Programar una red neuronal es un trabajo enorme que no me puedo echar encima. Ni por recursos ni por tiempo. Pero lo que sí puedo hacer es resolver un problema con herramientas que ya existen. Y en este caso, es un problema de clasificación y comodidad.

Requiere un parseo del input, trabajo y cálculo, así como salidas correctas. Partiendo del uso de esas redes (de Pytorch en este caso, según tengo mirado), creo que los problemas del planteamiento casi que desaparecen.

Otra parte que sí que me preocupaba es la de TDD. Sin embargo, creo que sigue siendo relativamente fácil plantearlo. Se pueden testear diferentes imágenes para verificar que el modelo usado genera algo con sentido; comprobar las salidas y la forma de estructurarlas...

Creo que hay un problema muy grande en la conversación, y es que, desde el primer momento iba a usar modelos preentrenados. Eso hace que el coste de almacenamiento y cómputo baje radicalmente, y pasen a considerarse casi insignificantes.

El problema es que estoy tratando de hacerte entender como adaptar tu proyecto a algo que sea válido en la asignatura, y parece que no logro transmitirlo.

Si quieres usar modelos preentrenados, simplemente es absurdo que se use la nube. Punto. Es tener un coste de almacenamiento y una latencia que no aporta ningún valor al usuario. La ingeniería de software es el arte e resolver problemas, y con esto no estás resolviendo ningún problema: estás creando el problema de que hay que conectarse a internernet, quizás tener un API key para evitar slamming, throttling en el servidor para que no te lo cargue, pagar por un almacenamiento del cual no va a obtenerse ningún beneficio.

Adicionalmente, es absurdo usar modelos preentrenados y en general cualquier integración de bibliotecas que no sean propias en este proyecto. Lo que se pide en el proyecto es que el estudiante desarrolle su propia lógica de negocio. Te he insistido varias veces en qué lógica de negocio puede ser, si insistes en este tipo de proyecto, a partir de ahí es decisión tuya.

Programar una red neuronal es un trabajo enorme que no me puedo echar encima. Ni por recursos ni por tiempo. Pero lo que sí puedo hacer es resolver un problema con herramientas que ya existen. Y en este caso, es un problema de clasificación y comodidad.

Tal como yo lo veo, la lógica de negocio que tiene tu proyecto es la red neuronal. Usar una red neuronal entrenada no es lógica de negocio (salvo que me digas que hay que hacer algún tipo de procesamiento o alguna de las otras palabras claves que se mencionan en el guión, lo que hast ael momento no has hecho). En caso de que hagas ese procesamiento, eso es precisamente lo que va a ser la lógica de negocio (y que uses una red neuronal o cualquier otra cosa me va a preocupar relativamente poco al final).

Requiere un parseo del input, trabajo y cálculo, así como salidas correctas. Partiendo del uso de esas redes (de Pytorch en este caso, según tengo mirado), creo que los problemas del planteamiento casi que desaparecen.

Por si no lo has entendido, no puedes usas librerías externas en tu lógica de negocio fundamental. Porque tienes que hacer tests unitarios (objetivo 3) y los test unitarios tienen que ser de código propio. Ese parseo no lo has especificado, ni en la descripción del problema ni en las historias de usuario. Esas son las historias de usuario, y no otras, porque son las que contienen la lógica de negocio. Si quieres ir por ahí, vale, pero tendrá que quedar claro que ese procesamiento sí tiene que ser propio.

Otra parte que sí que me preocupaba es la de TDD. Sin embargo, creo que sigue siendo relativamente fácil plantearlo. Se pueden testear diferentes imágenes para verificar que el modelo usado genera algo con sentido; comprobar las salidas y la forma de estructurarlas...

Es que no existe "la parte" del TDD. El TDD empieza en el objetivo 0, describiendo un problema con una cierta lógica de negocio, y desarrollando el resto de los artefactos a partir de ahí. Si necesitas revisar el texto del objetivo 0, hazlo, pero te vuelvo a insistir, este objetivo lo superarás cuando

Especifiques una lógica de negocio suficiente y propia, en relación con el problema que quieres resolver.
Esa lógica de negocio se beneficie de su ejecución en la nube. (si todo el procesamiento que mencionas se puede hacer más rápidamente en el portátil, tampoco sería adecuada. Por eso te mencionaba lo del entrenamiento, no por otra cosa: un usuario se beneficiaría de los modelos entrenados por el resto de los usuarios, y además de forma inmediata)

Si no tiene sentido el planteamiento, no creo que tenga sentido seguir avanzando. Así que le daré vueltas y pensaré en alguna otra cosa. Cuando lo tenga listo crearé otros PRs, que será más cómodo.

Gracias por el feedback.

Si no tiene sentido el planteamiento, no creo que tenga sentido seguir avanzando. Así que le daré vueltas y pensaré en alguna otra cosa. Cuando lo tenga listo crearé otros PRs, que será más cómodo.

Gracias por el feedback.

Nunca he dicho que no tenga sentido en general. Te he indicado varios caminos por los que podría tener sentido, y por tanto podrías superar este objetivo (que es de lo que se trata el feedback). Si crees que es mejor empezar desde 0 con una nueva idea, adelante. Pero temo que va a ser más trabajo para los dos hacerlo, en vez de tratar de hacer cambios a este.

Lo difícil de seguir con esta idea es que el planteamiento ha cambiado radicalmente. Donde antes tenía problemas algo sencillos de sortear, ahora se ha vuelto un gigante.

La lógica de negocio tienes que programarla tú. Buena suerte con testear una red neuronal (que no digo que no se pueda, pero buena suerte). Buena suerte con testear cosas de imágenes (¿cómo generas una imagen con unas características determinadas?)

Ese problema lo vas a tener también en el TFG, por cierto

Relacionado con 1., tienes el problema del bootstrap. Qué hacer cuando no tengas ninguna red entrenada.

Programar una CNN está fuera de mi alcance ahora mismo. Tendría que ponerme a investigar, aprender a hacerlo, y luego considerar la asignatura propiamente, con todos los problemas que conlleva. Es una receta para el desastre.

El problema del almacenamiento tendrás que resolverlo, tarde o temprano.

Y este es muy difícil de sortear. Necesitaría un dataset consistente, de propósito general y habilitar una forma de que los usuarios entrenen a la red. Además, considerar todo el coste asociado. Se va de las manos.

Si opto por tirar de KNN, quizás sea más factible. Pero dudo muchísimo que el resultado sea especialmente bueno para imágenes en general. Unos fondos muy tontos, estilo "perros, gatos y paisajes" podría funcionar. Pero aún así, dudo que merezca la pena. Es muy complicado en una asignatura como esta.

No veo forma de hacer funcionar esta idea llegados a esta encrucijada. Todos los caminos son costosos y duros.

Por eso, quizás preferiría cambiar de idea de nuevo. Aunque lleve trabajo. Prefiero centrarme en algo que sé que puedo implementar de forma exitosa y que de verdad me lleve a aprender sobre el desarrollo; no que se vuelva un problema. Al final, es trabajo que me estoy simplificando a lo largo del cuatrimestre.

De todas formas, no creo que resulte especialmente difícil. Más o menos tengo ya un planning. El objetivo 0 no deja de ser un párrafo sencillo. El 1 lleva algo más de tarea, pero fluye bien si se parte de una buena base.

Sin embargo, si lo llego a hacer, me gustaría plantear en el objetivo 0 toda la lógica de negocio. No quiero tener más problemas a la hora de enfocarlo. Me gustaría dejar todos los motivos claros desde el minuto 1, para que no me vuelva a pasar esto.

En cuanto tenga el visto bueno, me pongo a ello. ¡Siento el trabajo extra! :disappointed:

Lo difícil de seguir con esta idea es que el planteamiento ha cambiado radicalmente. Donde antes tenía problemas algo sencillos de sortear, ahora se ha vuelto un gigante.

La lógica de negocio tienes que programarla tú. Buena suerte con testear una red neuronal (que no digo que no se pueda, pero buena suerte). Buena suerte con testear cosas de imágenes (¿cómo generas una imagen con unas características determinadas?)

Ese problema lo vas a tener también en el TFG, por cierto

Relacionado con 1., tienes el problema del bootstrap. Qué hacer cuando no tengas ninguna red entrenada.

Programar una CNN está fuera de mi alcance ahora mismo. Tendría que ponerme a investigar, aprender a hacerlo, y luego considerar la asignatura propiamente, con todos los problemas que conlleva. Es una receta para el desastre.

El problema del almacenamiento tendrás que resolverlo, tarde o temprano.

Y este es muy difícil de sortear. Necesitaría un dataset consistente, de propósito general y habilitar una forma de que los usuarios entrenen a la red. Además, considerar todo el coste asociado. Se va de las manos.

Si opto por tirar de KNN, quizás sea más factible. Pero dudo muchísimo que el resultado sea especialmente bueno para imágenes en general. Unos fondos muy tontos, estilo "perros, gatos y paisajes" podría funcionar. Pero aún así, dudo que merezca la pena. Es muy complicado en una asignatura como esta.

Andrés, no estás haciendo una tesis. Se trata de que propongas una lógica de negocio realista, dentro de una aplicación en la nube. kNN al final es distancias ( == lógica de negocio ) los vecinos más cercanos son de otros usuarios ( nube :+1: ) y adicionalmente implican procesamiento adicional para convertirlo a vectores ( == lógica de negocio; pueden ser wavelets o una cuantización vectorial y desescalado cutre). Considéralo un producto mínimamente viable, para otro producto súper chanchi que harás más adelante que incluirá deep neural net con computación cuántica y GPUs de la muerte.

No veo forma de hacer funcionar esta idea llegados a esta encrucijada. Todos los caminos son costosos y duros.

Si procesas de alguna forma, eso te resuelve el problema del almacenamiento. Sólo tienes que almacenar las versiones procesadas, las versiones "guay" se pueden almacenar en el cliente ( === no nos preocupa en esta asignatura )

Por eso, quizás preferiría cambiar de idea de nuevo. Aunque lleve trabajo. Prefiero centrarme en algo que sé que puedo implementar de forma exitosa y que de verdad me lleve a aprender sobre el desarrollo; no que se vuelva un problema. Al final, es trabajo que me estoy simplificando a lo largo del cuatrimestre.

Piensa por favor lo que te comento más arriba. Siempre es mejor mejorar incrementalmente (y ágil) que empezar de nuevo, que tendremos (o no) el mismo problema.

Sin embargo, si lo llego a hacer, me gustaría plantear en el objetivo 0 toda la lógica de negocio. No quiero tener más problemas a la hora de enfocarlo. Me gustaría dejar todos los motivos claros desde el minuto 1, para que no me vuelva a pasar esto.

Realmente es lo suyo. En algunos casos dejé pasar, pero con advertencias.

He estado pensando en el tema, y sí que parece realista hacer una implementación muy sencilla basándose en KNN. Desde el primer momento la descarté, pues pensé que no daría buenos resultados. Pero, al final, eso no es lo verdaderamente importante.

Recoger imágenes de los usuarios, preprocesarlas, almacenar en el servidor la imagen reducida y pasarle KNN parece una buena lógica de negocio. Se aleja de mi visión inicial, pues ahora lo más importante será alimentar el set de entrenamiento, y no producir un buen resultado. Pero creo que podría funcionar. Necesitaría modificar bastante el roadmap y las necesidades de los usuarios, pero no creo que sea demasiado problema. Además, almacenando las imágenes procesadas se puede ahorrar un montón de almacenamiento. Y KNN se puede escalar más o menos bien. Es cuestión de ajustar los hiperparámetros.

He recolectado unos cuantos recursos que me podrían ayudar a la larga. Me preocupa especialmente la parte del preprocesamiento, pues no tengo mucha idea de cómo pasar de una imagen a un vector de características lo suficientemente representativo como para que KNN funcione de forma decente. Pero eso es parte de la gracia de intentarlo. Es cuestión de tiempo.

Además, yo mismo tengo un buen set de entrenamiento de partida. Aunque no es para nada correcto usar imágenes de autores varios sin ningún tipo de permiso. Quizás pueda usar Unsplash para coger unas cuantas muestras diferentes.

Con todo esto, la parte del upscaling al final del pipeline se vuelve totalmente secundario, así como el procesamiento de varias imágenes a la vez. Puede quedarse como una milestone más, no es problema.

Creo que ahora la lógica de negocio tiene más sentido. Si tengo el visto bueno, me pongo manos a la obra.

¡Muchas gracias por las direcciones!

He estado pensando en el tema, y sí que parece realista hacer una implementación muy sencilla basándose en KNN. Desde el primer momento la descarté, pues pensé que no daría buenos resultados. Pero, al final, eso no es lo verdaderamente importante.

Recoger imágenes de los usuarios, preprocesarlas, almacenar en el servidor la imagen reducida y pasarle KNN parece una buena lógica de negocio. Se aleja de mi visión inicial, pues ahora lo más importante será alimentar el set de entrenamiento, y no producir un buen resultado. Pero creo que podría funcionar. Necesitaría modificar bastante el roadmap y las necesidades de los usuarios, pero no creo que sea demasiado problema. Además, almacenando las imágenes procesadas se puede ahorrar un montón de almacenamiento. Y KNN se puede escalar más o menos bien. Es cuestión de ajustar los hiperparámetros.

Te sorprendería lo bien que funcionan algoritmos simples como kNN o NaiveBayes.

He recolectado unos cuantos recursos que me podrían ayudar a la larga. Me preocupa especialmente la parte del preprocesamiento, pues no tengo mucha idea de cómo pasar de una imagen a un vector de características lo suficientemente representativo como para que KNN funcione de forma decente. Pero eso es parte de la gracia de intentarlo. Es cuestión de tiempo.

El procesamiento, en todo caso, es parte de la lógica de negocio. Cualquier cosa que hagas me vale, preocupación por la calidad me vale y también te puedes ganar una recomendación en LinkedIn.

Además, yo mismo tengo un buen set de entrenamiento de partida. Aunque no es para nada correcto usar imágenes de autores varios sin ningún tipo de permiso. Quizás pueda usar Unsplash para coger unas cuantas muestras diferentes.

Dado que lo único que vas a almacenar es la representación, y cada usuario sólo tiene acceso a sus imágenes, no creo que haya, a priori, ningún tipo de problema de copyright. Por supuesto, usar eso o imágenes con CC es mejor.

Con todo esto, la parte del upscaling al final del pipeline se vuelve totalmente secundario, así como el procesamiento de varias imágenes a la vez. Puede quedarse como una milestone más, no es problema.

Creo que ahora la lógica de negocio tiene más sentido. Si tengo el visto bueno, me pongo manos a la obra.

A ver, los vistos buenos no los doy a priori, los doy una vez que hagas los cambios, y no me queda claro si los has hecho... Si sólo lo has hecho en los issues y milestones, os agradecería que también lo hicieras en la documentación.

Tanto la wiki como los issues han sido actualizados (la wiki no se muestra como un pusheo a la rama del PR, por lo que considero que es conveniente mencionarlo aquí).

Asmilex / IV

Completa objetivo 1 #6