Yesterday had a chat with @decentralion about things to work on next, mono-repo vs multi-repo structures, refactoring we need, etc. (Don’t know how long a discord link stays valid, but here it is)
Milestones and versioned releases
A few milestones we converged on:
- Adding initiatives.
- Urgent UI and infrastructure* improvements for the CredSperiment.
- Migrating to instances and a modular system design.
*= not physical (e.g. servers) infrastructure, but for example a solid CLI command to calculate payouts, instead of the current magic process of updating notebooks.
These are ordered by the larger planning guideline to:
- First focus on CredSperiment and making SourceCred work well for it’s own community.
- The move on to make SourceCred easier to use for other open-source projects and make it work well for them.
The instance system is a good example of making things easier for other projects, so it’s further down compared to direct improvements for CredSperiment.
We also felt like they make sense to mark releases based on that:
- v0.5.0 = Initiatives release.
- v0.6.0 = UI and infrastructure reworked.
- v0.7.0 = (Modular) instances system.
I wouldn’t say these are set in stone (other than initiatives as I’m championing that ) , but perhaps a useful indicator.
Multi- vs mono-repo and modular design
There’s a need to split some of
sourcecred/sourcecred's code into modules we can use elsewhere. For example some of it’s code has been copy-pasted or reproduced in
Conversely we have plugins, but they’re baked into the core software at
src/plugins. Actually pulling those out of the core will force us to develop plugins the way a 3rd party developer would too (dogfooding our plugin system).
In this chat:
There’s a worry that multi-repo will cause overhead to keep consistent in terms of tooling, quality and synchronized releases. A tools repo could be a half-solution but doesn’t fully avoid this. Mono-repo on the other hand can lead to taking shortcuts and coupling modules, like we’re doing with the plugins now.
What we could agree on though is:
- The “core” needs to be a module which we can depend on as a library.
It can expose common utilities and types as well.
- Core needs a serious diet.
Taking the UI, the plugins, maybe the CLI as well, out of it into other modules.
- Those non-core modules could be in multi-repo or mono-repo.
In particular would love to hear @wchargin’s take on this structure.