Respecto a Desarrollo.md about algo3_proyecto_base_tp2 HOT 8 CLOSED

Según mi entendimiento Desarrollo.md es un lugar en el que le proporcionamos una guía a lxs alumnxs sobre como trabajar, por eso allí tenemos guías de configuración de ambiente, diagramas, etc. que les sirven a ellxs para empezar a trabajar en su tp una vez que se copian el repo. Entiendo que cualquier sugerencia como las que mencionás la podemos incluir en ese archivo, o generar uno nuevo en la carpeta docs que se encuentre linkeado desde Desarrollo.md.

from algo3_proyecto_base_tp2.

Ok. Al alumno, de algo 3, le interesa https://github.com/fiuba/algo3_proyecto_base_tp2/blob/master/docs/Desarrollo.md#empaquetado y la guía https://github.com/fiuba/algo3_proyecto_base_tp2/blob/master/docs/Docker.md.

🤔

from algo3_proyecto_base_tp2.

Con respecto a Docker, es una de las formas de configurar el ambiente de desarrollo a la par de la nativa, con lo cual lxs alumnxs pueden elegir la que les parezca mejor.

Por otro lado, el empaquetado es la forma de hacer un release y generar un entregable de forma automatizada. Esta última entiendo que a lxs alumnxs les puede interesar para poder distribuir su aplicación, aunque es cierto que es una tarea más "operativa" que de desarrollo.

from algo3_proyecto_base_tp2.

Según comenta @tomasBustamante, el entiende que el proyecto base algo3_proyecto_base_tp2 es una plantilla agnóstica de la materia, cualquiera de sus prácticas y metodologías.

from algo3_proyecto_base_tp2.

Sí, para mí toda documentación dentro de este repositorio debería tener exclusivamente instrucciones sobre el proyecto en sí. La guía de desarrollo está buena y la de Docker también, ya que muestra cómo levantar el proyecto.
Todas las guías tipo tutoriales de herramientas genéricas (tipo IntelliJ o PlantUML) para mí deberían ir aparte, aunque tampoco es tan importante.

from algo3_proyecto_base_tp2.

De acuerdo.

Me problema es la relación que guardan estos dos elementos: (1) template y (2) documentos accesorios. Veo que la razón cambio de en un documento impacta, seguramente, en el templete. Ejemplo: Si documentamos una restricción el los paquetes es porque el código del template cambio.

Dividiendo las contribuciones en diferentes repositorios es difícil mantener ambos sincronizados.

from algo3_proyecto_base_tp2.

Me problema es la relación que guardan estos dos elementos: (1) template y (2) documentos accesorios. Veo que la razón cambio de en un documento impacta, seguramente, en el templete. Ejemplo: Si documentamos una restricción el los paquetes es porque el código del template cambio.

Dividiendo las contribuciones en diferentes repositorios es difícil mantener ambos sincronizados.

Sí, tal cual. Por eso digo que ese tipo de instrucciones específicas del repositorio deben quedar en el repositorio. Lo que no debería ir, por ejemplo, es una guía de cómo configurar este proyecto en IntelliJ, debido a que (a) no es necesario utilizar IntelliJ y (b) la guía no es exclusiva de este repo, sino de prácticamente cualquier proyecto Maven. Fue por eso que en su momento la extrajimos a este otro repo. Quizás podamos encontrarle un lugar mejor.

La documentación que está actualmente en este repositorio no me parece mal. A lo sumo removería algunas oraciones de más, pero es un detalle. No terminé de entender si sugerías agregar más información o menos al repositorio.

from algo3_proyecto_base_tp2.

Puntualmente (discutamos donde) distinguiría dos audiencias:

1. colaborador del repositorio,
2. Alumno de Algo3. Ejemplo: Si documentamos una restricción el los paquetes es porque el código del template cambio, restricciones de cobertura, etc.

Para (1) Desarrollo.md está ok.
Para (2) no utilizaría Desarrollo.md.

from algo3_proyecto_base_tp2.