+1 to what William said.
my 2c: the repository refactoring described here makes sense to me as a long term outcome (long term being >6 months in the future). For now, I don’t think there’s any urgent need to pull things out of sourcecred/sourcecred; in the case of sourcecred/payouts, I think by far the most efficient path is to simply collapse all the payout logic into sourcecred/payouts.
I do want to make it possible to depend on the code outside of sourcecred/sourcecred, i.e. make it possible to import (say) the Graph module, or logic for TimelineCred. This would be most valuable for Cred Analysis Notebooks. It would also enable a more robust interface/implementation for sourcecred/widgets. But achieving this doesn’t require changing the repository structure.
I think there are 3 “scopes” of SourceCred we can think about:
- Scope 0: Only SourceCred uses SourceCred.
- (where we are now)
- APIs, interfaces, and workflows can be very messy
- can break compat whenever
- Scope 1: Other projects use SourceCred, mostly “off the shelf”
- projects are turning on SourceCred instances that are very similar to our own usage: GitHub, possibly Discourse, Cred+Grain, etc
- we need the SourceCred Instance System for usability
- plugin interfaces are not mature, all plugins come from core
- shouldn’t break compat on workflows, can break compat on interfaces
- Scope 2: SourceCred as a protocol
- Other projects are extensively using SourceCred APIs, possibly in ways that are fairly different from how SourceCred is dogfooding
- Consumers are developing plugins for their own use case that are not expected to merge upstream
- shouldn’t break backcompat on workflows or interfaces
The repository refactoring to improve / enforce the ability to add new plugins is something we only need at scope 2. However, even getting to scope 1 is months away, and going to multi-repo doesn’t help at all within Scope 1. So we should hold off engaging in multi-repo work until we are well into Scope 1.