Reunión sobre LibreQDA

Presentes: Tryolabs (Ernesto, Mauro, Alejandro), Marc, Juan, Lupa

reanalyse

TL Analizaron el software: MBR:

Discutimos temas de la facilidad de instalación del software tipo paquete.
Que sea sencillo al estilo de xampp:
http://www.apachefriends.org/es/xampp.html
(Lo que por cierto, comentamos que era una necesidad del proyecto).

Todas las partes están de acuerdo en que descartamos reanalyse como punto
de partida para el desarrollo del libreQDA.

Tryolabs había pensado en distribuir un virtualización.
Comentamos que esta via es mucho más complicada que la via xampp:

Ver:
http://www.hcosta.info/wp/2012/10/tutorial-xampp-django-wsgi-en-windows-facil/

Acordamos investigar al respecto.

Dinámica de trabajo

Planteamos algunas inquietudes sobre el tema de los 5 días ya utilizados
y sobre la utilización de 2 programadores en lugar de 1, lo que acorta
los 30 días a 15.

Tryolabs propone empezar con 2 desarrolladores pues su experiencia les
lleva a que los inicios de proyectos son muy paralelizables. Ellos
mismos propondrán "desparalelizar" si el proyecto lo requiere.

Acordamos reuniones de sprint cada lunes y viernes (en principio a las
12h de Montevideo).

Tema de lo público/privado en github

Dejarlo privado por temas de intimidad y prolijidad al inicio del desarrollo

Cuentas github:

Preguntas concretas sobre funcionamiento del programa

Modelo de datos

Analizamos a vuelo de pájaro un esquema que nos envían:
http://redmine.tryolabs.com/attachments/download/182/modelo_libreqda_v0.1.png

A priori parece correcto (con un par de matices).
Acordamos revisar el modelo con tranquilidad antes de mandar el ok.
definitivo
(eso si, antes del viernes).

Tema de las citas

Nos preguntan cómo serán las citas.
Comentamos que en el modelo de datos falta información para que la cita
referencie al texto (documento > línia > char + desplazamiento?)
Quedamos pendientes de mandar el documento de consultas para decidir
cual es la mejor manera de almacenar estos datos.

Tema de los códigos

Tryolabs pregunta sobre como representar subcódigos. Preguntan sobre
quantos niveles de jerarquía serán necesarios.

Respondemos: La prioridad és que se pueda definir cualquier tipo de
relación, sin importar profundidad. Si esto implica que no se van a
mostrar los subcódigos en la ventana de códigos, de momento es un mal
menor. Si que se mostrarán las relaciones en la pestaña de relaciones
(tal y como se muestra en el mockup).

Relaciones

¿Qué tipos de relaciones se quieren crear entre los objetos?

Juan explica que se comenta en el mockup.

Comentamos que de momento la única propiedad de una relación es si es
bidireccional o unidireccional (causa-efecto o asociado).
Mandamos relaciones "por defecto", aunque el usuario debe poder crear
las relaciones (o sea los "nombres") que quiera.

¿Cómo continuar?

Tryolabs trabajará sobre el documento de consultas para proponer una
arquitectura que nos mandará en y se validará el viernes.

Tryolabs pide chat de personas de contacto: Lupa y Juan se ofrecen.

No reunimos de nuevo el viernes a las 12h (Montevideo)