h1. Reunión sobre LibreQDA

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

{{>toc}}

h2. reanalyse

TL Analizaron el software:
* bastante desordenado
* no está suficientemente desarrollado
* código feo: mezcla front-back ends
* no pudieron dejar algo corriendo para poder evaluarlo colectivamente

MBR:
* Dice que además no podrías distribuirlo como un soft de escritorio
* Complicado empaquetar solr dentro de un xampp

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.

h2. Dinámica de trabajo

* 35 días de desarrollo: 5 fueron utilizados la semana pasada
* Quedan 30 días que lo van a hacer con 2 desarrolladores: 3 semanas
* Sprints FIXME: completar
* Disponibilidad en el chat
* Hostear el proyecto en github
** Privado mientras se esté desarrollando
** Dinámica de corrección de errores

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).


h3. Tema de lo público/privado en github

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

Cuentas github:
* marcbria
* lupa18

h2. Preguntas concretas sobre funcionamiento del programa

h3. 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).

h3. 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.


h3. 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).


h3. 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.

h2. ¿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)