Monorepo first for test suite and reference implementation

[OR13]

I propose we start out, with the test suite, reference implementation and spec all in the same repo.

I am almost 100% confident that we will end up splitting them up at some point in the future, but I think there are a large number of advantages of starting with a mono repo.

I fully expect especially as we gain confidence / tests / code we may want to split these things up and cross link them.

Likely there will be objections about issue tracking, versioning , publication, etc...

I propose that GitHub has filters and good development structure can totally mitigate these basically forever.... here is a similar project:

https://github.com/ipfs/js-ipfs

hosts the client, server, core interface (test suite) and common helpers.

[dmitrizagidulin]

@OR13 what's the benefit of having the test suite bundled with the spec? (Vs in its own repo).

[dlongley]

One consideration for having a reference implementation in the same repo as the spec is that might complicate packaging for installation and use of the reference implementation. Depending on how the test suite is packaged -- there may be similar concerns.

[OR13]

The benefit is that we can easily track issues related to reference implementation, test suite and spec conformance in a single issue tracker, and have a one stop shop for seeing what is working, and what is not....

Its easy to build, package and deploy each package in a mono repo separately with github actions...

We can see how changes to the reference implementation impact the test suite in real time on PRs.

We can note cases where the spec or reference implementation are confusing, and we can fix issues with the spec, reference implementation and test suite in a single PR... instead of... well having them be maintained by people hopping around 3 repos trying to keep things in sync, or more accurately, 1 or 2 people doing that...

Since its more work to maintain 3 repos that 1, we should be careful not to ask the working group to do that, unless there is some really good reason... each repo will have its own issues, discussion... need to have issues reviewed, PRs reviewed, etc.... all that needs to happen in a timely manner for people to feel like contributing is working...

When we create multiple repos we increase the time for review, and the management burden for code owners / editors... multi-repo structures are more work for the people who contribute to all repos regularly... those people are the people we should be optimizing around supporting.

It also create a scenario where people who provide feedback on the spec, rarely see notes on the reference implementation or test suite... those are all missed opportunities for a spelling correction, a term defintion, or a helpful comment... we will see less contribution to 3 repos, than we will with one... which brings me to another point... tracking contributions, a repo with 10 contributors and regular PRs looks a lot more health, than 3 repos with 2 or 3, and sporadic updates... we will have more stars, more contributors, better activity ranking (draws contributors from the wild)... and a better chance for addressing questions from the community... sometimes a question raised on a test repo.... really belongs on a spec repo... spec contributors will never see it, and the won't respond to it...

I could go on, but this is one of those "feelings" things, like spaces vs tabs, or snake_case vs kebab-case vs camelCase... There will always be tribes around this.... In my opinion, separating repos is a thing you do when you have so much contribution, you need a way to help split it up into buckets so that issues / PRs are getting addressed... microservices and modularization come with scaling... which many people want to avoid up-front, pre-optimization, pre-scaling can introduce extra drag, slow things down, at a time when nobody is using the thing or contributing to it....

I would love to have this repo be the first time where I felt like the contribution was heavy enough to justify the management overhead for 3 repos... but given the working group is just getting started, we are clearly not seeing that level of contribution, and i think we will all know when we hit it, because managing issue and PR reviews in this repo will become impossible due to volume... we are clearly not there yet.

[OR13]

I'd like to see this setup so that people can contribute to the stuff on a technical layer, and we can split stuff up as is needed, when its needed.

[OR13]

I'm labeling this as blocking because its preventing technical contribution.

[sondreb]

A point to not use mono-repo:

• Different release cadence of the artefacts, let's say there is a .NET implementation and a JavaScript one, it would either pollute the release history (e.g. can be hard to find an implementation that has not had a recent build/release) or each release would need to have every single artefact.

There is always the possibility to move implementations either out or in, issues won't easily move though.

[OR13]

Issues can be transferred to repos, and so can implementations.

The working group has not commited to a reference implementation per langauge, though I think that would be valuable... and would certainly be best accomplished with seperate repos.

The context of this issue is the workgroup items, that we are committed to by the charter:

an implementation, and a specification...

I see no reason to split them up until required to do so because of contribution optimization... we are not seeing any contribution to a reference implementation right now, so i suggest we start that work in this repo, and only move it when it becomes too burdensome.

[OR13]

Pull request which implements interoperability tests: https://github.com/decentralized-identity/secure-data-store/pull/70

Hopefully this shows that a mono repo won't get in the way of contribution, and that each "module" can easily to moved to its own repo if we see sooooooooooo much contribution that seems necessary to keep up.

[OR13]

1/2 done, we have tests... we need a "sample" implementation.

[OR13]

we've done this, we will keep mono until we need to split things up.