Usar consul ha sido un éxito. Cifras:
- Más de 25.000 visitas únicas
- 21.000 votos en propuestas
- Más de 500 propuestas de usuarios.
- Dinámica positiva. Poco o nada de trolling.
Los proyectos han divergido un poco por varios motivos:
- Necesidades de diseño, campaña e interfície del Ajuntament de Barcelona.
- Necesidades funcionales: Categorización PAM/PAD, fases posteriores, normativas.
- Traducciones, páginas estáticas.
Hacer merge de consul, aunque se ha hecho en diversas ocasiones de manera exitosa, supone problemas:
- Aunque se realicen merges de manera frecuente, la complejidad del proceso es cada vez mayor, ya que el código se parece cada vez menos.
- Supone una carga cognitiva importante que normalmente lleva un sólo programador. Bus number demasiado alto.
- Dificultad de tomar decisiones rápidamente que afecten de manera superficial al proyecto, por ambos lados.
Creemos que la estrategia de consul es práctica para un caso de uso genérico, pero no encaja demasiado con aplicaciones más ambiciosas (almenos por ahora).
Modelo basado en rails engines. Caso de éxito: spree (https://github.com/spree/spree)
Pros:
- Facilita el desarrollo de módulos con funcionalidades muy particulares.
- Versionado.
- Fácil customización, overriding de views, etc.
- Reutilización de módulos. Market de funcionalidades.
- Separación de concerns. Menos código en el core. Más robustez.
Contras:
- Sincronizar migraciones entre módulos.
- Más burocracia. El programador debe tener consciencia de su modularidad y de qué impacto tiene una abstracción.
- Más puntos de fricción.
- Colaboración basada en librerías: Diseñar librerías y servicios usables por ambos proyectos, con más granularidad y mantenimiento separado, que puedan usar no sólo consul/decidim sino un amplio rango de aplicaciones públicas y no tan públicas. Ideas:
- Motor de recomendaciones (filtrado colaborativo) basado en votos / comentarios / participación.
- Motor de newsletters y resúmenes.
- Módulos de integración con el padrón.
- Módulo de integración con servicio de envío de SMS.
- Verificaciones de todo tipo.
- Sistema de gamificación.
Empezar por 2, evaluar si 1 es posible a largo plazo, probablemente pasando por una refundación de ambos proyectos.
Sinergias en intereses comunes externos a la aplicación:
- Definir una API pública estándar para facilitar el consumo y análisis de datos.
- Desarrollo de facilidades para analizar esos datos y sacar conclusiones.
- Aplicaciones comunes que trabajen sobre una misma API: Dashboard a tiempo real.
- Librerías para desarrollar una aplicación móvil trabajando sobre esa API.
- Integración de datos en un portal de transparencia.
Compartir contínuamente experiencias sobre:
- Gamificación y dinámicas
- Seguridad, autenticación, autorización.
- Normativas.
- Power to the people