With our current architecture we're facing a crossroad, where we need to talk about how could be the best approach to handling all the git repositories and all the problems that we're having right now and the problems to come.
On one hand, this is the picture right now:
Official modules on decidim/decidim
- decidim-accountability
- decidim-admin
- decidim-api
- decidim-assemblies
- decidim-budgets
- decidim-comments
- decidim-core
- decidim-dev
- decidim-meetings
- decidim-pages
- decidim-participatory_processes
- decidim-proposals
- decidim-surveys
- decidim-system
- decidim-verifications
Official modules outside decidim/decidim
- decidim-module-consultations
- decidim-module-sortitions
- decidim-initiatives
- decidim-results
- decidim-module-blogs
- decidim-module-mentions
Non official modules
- Census (DIBA)
- Crowdfundings (podemos-info)
- DataViz (Barcelona)
- Debates (Barcelona)
- Members (FundAction)
- Pol.is (OSP)
- Surveys (Hospitalet)
- User Export (OSP)
- Verification Census API (DIBA)
- Verification Census API (Barcelona)
- Votings (podemos-info)
This is mostly how we're working right now. The only difference between what belongs on decidim/decidim right now are not technical issues but mostly administrative reasons (which company has made that development). This would involve moving all the Official modules outside decidim/decidim to Official modules on decidim/decidim.
This is simpler, specially because it allows the APIs to change on any given moment and make that change on a single PR, and all the CI and translations on the same place. Also simpler to grep.
A couple big companies that had this model are Google and Facebook. More info: https://danluu.com/monorepo/
This doesn't scale that well (lots of LOC for every module, lots of times to CI to finish).
Most of the modules of Official modules on decidim/decidim should go outside, leaving a leaner core module:
- decidim-admin
- decidim-api
- decidim-core
- decidim-dev
- decidim-pages
- decidim-system
All the other modules would be on separate repositories.
Allows to make the APIs between modules more mature, allow better scaling.
This have some pain points, regarding:
- Translations: we should create a new crowdin project with their integration
- CI: configure again. Maybe with dummy apps and default configs it's a little less pain
- Docs?
- Issues
Having somekind of generators or a skeleton on making a new gem would reduce these pain points.
Well, I read the whole thing and except for the initial posts which include motivations to migrate to a monorepo solution, the rest is a migration path discussion, which doesn't really apply to us since we are currently a monorepo.