With great power comes great responsibility

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)

1 Like

I’ve got the following repos:

  • go-zenon
  • znn-pow-links-cpp
  • argon2_ffi
  • znn_swap_utility
  • znn_controller_dart
  • znn_cli_dart
  • znn-wiki

Guys, it looks like I’ve been given admin roles and have some additional rights. I can see the maintainers on each repo. I will post them here below.

I’m open to any discussion about how my admin rights should be limited and/or checked.










I’m not an admin

Where I am maintainer so far:

  • go-zenon
  • znn-pow-links-cpp
  • argon2_ffi
  • znn_controller_dart
  • znn_cli_dart
  • znn_swap_utility
  • znn-wiki

I’ll update the list accordingly. I’m now a little busy upgrading some dependencies for Syrius and the Dart SDK.

Wow! I’m shocked by this revelation.

Who has access to the syrius, websites, twitter repos?

is sumoshi21’s Write role a missclick?

It might be the first recorded case of a Mr. Kaine missclick.


1 Like

Not sure.

So we have the following main repos


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.

  1. Should all the “main” code base live in /zenon-network? go-zenon, syrius, orchestrator, side-chain?
  2. Should we develop code in /hc1 and /hct and reference it from /z-n with submodules or a mirror?
  3. If we move code to /z-n how do we prevent the centralized github drama that bitcoin has experienced?
  4. 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.

Any thoughts?

1 Like

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.

1 Like

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