Facilitar el agregar a una organización

[renich]

Es necesario usar un método para agregar organizaciones; acompañado de una plantilla y que haga fácil el llenado.

A lo mejor una orden a make para que cree una plantilla?

Sería bueno incluir alguna pruebita para no permitir plantillas vacías.

[alvarezp]

No se podría con Make porque no soporta parámetros (como el nombre para ponerle al nuevo archivo). Tendría que ser un script, pero yo creo que no es necesario tal script si en el README.md se documenta el procedimiento. Tal procedimiento podría ser simplemente:

1. Toma la plantilla en plantillas/gulnew.yaml y cópiala a src/
2. Modifica el archivo.

Para plantillas/gulnew.yaml podría ser el siguiente contenido:

---
nombre: Grupo de Usuarios de ...
activo: false
acronimo: gulnew
comentario: Grupo nuevo
direccion:
    ciudad: Ciudad
    estado: Estado
contacto:
    e-mail: contacto@example.com
presencia:
    facebook: https://www.facebook.com/groups/gulnew
    github: https://github.com/gulnew
    google-groups:
        - informacion: https://groups.google.com/forum/#!forum/gulnew-anuncios
          tema: Anuncios
        - informacion: https://groups.google.com/forum/#!forum/gulnew
          e-mail: gulnew@example.com
          tema: General
    google-plus: https://plus.google.com/communities/123456789123456789123
    irc: irc://freenode.net/#gulnew
    planeta: http://www.gulnew.org/planet
    podcast:
        - nombre: Podcast de Gulnew
          activo: false
          formatos:
              - mp3: http://podcast.gulnew.org/mp3
              - vorbis: http://podcast.gulnew.org/ogg
    twitter: https://twitter.com/gulnew
    web: http://www.gulnew.org/

Y, sí, con esta plantilla podría haber un test para encontrar archivos que contengan cadenas por defecto y fallar la prueba. Algo basado en ! [ -f src/gulnew.yaml ] && ! egrep 'Usuarios de \.\.\.$|gulnew|example\.com|123456789' src/*.yaml

[alvarezp]

Y me faltó el paso 3: agregarlo al final de la variable GROUPS al principio del GNUmakefile.

[dualbus]

Ah, faltó mencionar el uso de YAML: Estábamos pensando sobre usar YAML como backend para generar el markdown. Las ventajas de usar YAML:

• Es un formato fácil de parsear (a diferencia de markdown, que realmente solo sirve para dar formato a documentos)
• Es un formato legible para humanos (a diferencia de XML o JSON)
• Hay librerías para prácticamente todos los lenguajes relevantes
• Permitiría manipular de forma más sencilla la base de datos de organizaciones, para hacer cosas como: Lista los podcast de todas las organizaciones activas, lista todas las organizaciones que tienen un email de contacto, etc.

Voy a crear un issue separado para rastrear esto. Ya hay avances experimentales en mi fork y en el de @alvarezp

Sobre la plantilla, me agrada la idea de Octavio de buscar archivos con cadenas por defecto.

[alvarezp]

@renich, @dualbus -- cierto!! disculpen la distracción. En mi comentario estoy usando un ejemplo en .yaml por el trabajo experimental que está realizando @dualbus pero lo cierto es que, mientras tanto, la plantilla sería en .rst bajo la misma técnica: contendría cadenas predefinidas para hacer que la prueba falle si no lo han editado por completo.

[renich]

@alvarezp @dualbus ok, suena bien. La cosa sería generar el PDF a partir de YAML entonces.

Me gustaría discutir un poco el formato; en lo particular, el nodo "activo". Creo que debemos considerar muy bien si lo vamos a usar o no; y en qué nodos.

Si al primer nivel tienes "activo", es muy probable que tengas activo todo lo demás. El "histórico" del que tienen ganas está muy chido, pero es muy importante que no contamine la información y que siga siendo un directorio práctico; no un sementerio de GULs y organizaciones FOSS-friendly.

Propongo considerar las siguiente bifurcación:

• Usamos "activo" en todos los nodos; para poder determinar si el servicio/evento sigue activo o no. A la hora de generar el PDF, generamos dos: histórico y directorio. El histórico, contendrá toda la info de con "activo: false".
• Usamos un solo nodo "activo" global.

[mimex]

+1 al uso de YAML, creo que eso permitiría también usar la info para hacer apps[1] o servicios como el API de Hackerspace[2]

[1] https://f-droid.org/repository/browse/?fdid=ch.fixme.status
[2] http://spaceapi.net/new/docs/getting-started

[dualbus]

Va, a discutir :-)

Si al primer nivel tienes "activo", es muy probable que tengas activo todo lo
dem�s. El "hist�rico" del que tienen ganas est� muy chido, pero es muy
importante que no contamine la informaci�n y que siga siendo un directorio
pr�ctico; no un sementerio de GULs y organizaciones FOSS-friendly.

Toma el caso del GULTij como un ejemplo. El grupo est� activo, pero su podcast,
OpenCharla, no lo est�. Creo que ser�a mejor el siguiente algoritmo para
consultar si cierto elemento est� activo:

• Si el estado global es 'inactivo', entonces, todos los elementos est�n
  inactivos.
• Si el estado particular del elemento es 'inactivo', entonces, se considera
  que ese elemento est� inactivo.

As� podemos cubrir el caso de OpenCharla, y ahorrarnos el trabajo de marcar
cada elemento como inactivo si un grupo en general est� inactivo.

Propongo considerar las siguiente bifurcaci�n:

• Usamos "activo" en todos los nodos; para poder determinar si el
  servicio/evento sigue activo o no. A la hora de generar el PDF, generamos dos:
  hist�rico y directorio. El hist�rico, contendr� toda la info de con "activo:
  false".

Ah, precisamente eso hace:

https://github.com/dualbus/dir-foss/blob/tmp/src/build.py#L47

En efecto, la idea no es contaminar el PDF final con una lista de GUL muertos,
pero s� me gustar�a tener un hist�rico. Esto ayudar�a a que si alguna persona
de dicha ciudad/estado tiene una iniciativa de formar un GUL, le de preferencia
a retomar proyectos ya existentes, que crear uno m�s.

Tambi�n ayuda a saber qu� grupos ya documentamos de cierta forma, aunque al
final resultaron no estar activos.

• Usamos un solo nodo "activo" global.

Estoy de acuerdo en usar un nodo activo global, pero para los casos
excepcionales, tener la posibilidad de deshabilitar a nivel elemento.

[renich]

@dualbus hehehe, muy bien. Suena lógico. Creo que podemos hacer justo lo que tu algoritmo propone.

En cuanto al histórico, suena muy bien. Podemos tener un historico.pdf y que, ahí se pongan todos los elementos que están inactivos.

Por ejemplo, en el directorio, GULTIj tendría su entrada y una leyenda; al final, sugiriendo ver el histórico para ver los elementos inactivos. En el histórico, tendríamos la entrada de GULTIj y sus elementos inactivos.

Suena bien?

[renich]

ping