Now that some of us have maintainer roles for the Github repos, let’s start transferring or forking relevant repos to the organization so that other builders can find everything in one place.
This will also fix one of out greatest issues, which is having a Github with almost no activity, which might make outside visitors see NoM as a ghost chain.
We should also figure out who are the maintainers, since all repos require at least 2 approvals and the go-zenon repo requires 3 approvals to get a PR merged. (to the best of my knowledge)
And several personal repos. Early on when we established the ZIP process we envisioned keeping code repositories separate in order to avoid centralized power in one admin or core maintainers. Moreover, @georgezgeorgez has envisioned node software in different languages. So if we blow up go-zenon and nodes stop working, “dart-zenon” will continue to make blocks and the network persists.
Should all the “main” code base live in /zenon-network? go-zenon, syrius, orchestrator, side-chain?
Should we develop code in /hc1 and /hct and reference it from /z-n with submodules or a mirror?
If we move code to /z-n how do we prevent the centralized github drama that bitcoin has experienced?
It would be nice to show activity in the /z-n repo because it’s a marketing tool. But if we can reference / mirror other repos where code is advanced would that serve the marketing purpose?
I think we should discuss some of these big picture questions before forking / moving / creating new repos in /z-n.
At the very least, independent participants should be mirroring (e.g. gitea) all three accounts you listed.
I’m still not sure if all AZ-funded software should live in the /z-n account.
Perhaps we’ll even reduce its scope of responsibility and transfer certain projects to dedicated teams.
Maybe move everything that’s directly related to the network?
For example the orchestrator and the extension chain are third-party solutions, so they could stay on separate orgs
