I’ll briefly summarize the topic and request everyone to express their opinions.
Mr Kaine is the sole maintainer of the de-facto Zenon codebase, yet he ignores (1, 2, 3) our pull requests or silently accepts them without any comment.
His review process is opaque, his inactivity has stalled this project on several occasions, and the need for his involvement is questionable.
George has summarized most of the concerns in these posts: 1, 2
I propose that we, the active developers of the Zenon project, reach a consensus about how “official” code should be maintained, reviewed, tested, and distributed. Feel free to suggest solutions in this thread.
HyperCore One was formed to handle these objectives, but Mr Kaine continues to undermine our efforts.
I believe it would be in our best interest, as a community, to proceed without Mr Kaine’s explicit involvement.
I was recently watching this long podcast with Jack Dorsey. Some of the things he talks about are relevant to our discussion here.
Dorsey: if you don’t like the architecture of the public square, change it. He also talks about how Satoshi started bitcoin and turned it over and vanished. And how elegant that was. I don’t recommend listening to this unless you have 3 hours to burn in a car or plane.
Here are my general thoughts. I think Kaine is far more active than we know or think. Kaine’s inaction in /zenon-network is on purpose. It must be hard for him to see code sitting there that needs to be reviewed and merged. And yet he lets it sit there. I do not think he is lazy or does not care. He is doing this on purpose. He wants the community to take over. He wants the /zenon-network repo to go away. He wants us to fork him out and/or take over spork production. He wants to vanish.
And once we deliver Phase 1 my bet is he is gone forever. We all know it’s going to happen. It’s just a question of when. So the sooner we move in this direction the better. However, I don’t want to do anything stupid or too quickly that puts the network at risk.
In summary, I am for an orderly transition away from Mr. Kaine and the /zenon-network repo. I think this must be 100% complete by the time we deliver Phase 1 but hopefully before that. I think we can start building trust with the community by asking the community to use our repos for critical infrastructure.
Pillars are trusting the HCT repo for the Orchestrator. HC1 can offer the znn_controller_dart software to upgrade go-zenon to v0.0.6 by fixing big int support. I’m going out for a walk. I’ll post more later.
I don’t know what Mr. Khaine thinks and if there’s no clear communication about it, it doesn’t matter.
It is important that we can move forward as a community. The government module is a crucial part of it. The umbilical cord can be cut with this.
As for the repositories, I think it’s a lot simpler. If we agree today that repo X is leading, we’ll make it leading. No one is stopping us, especially if it means we can move forward faster.
For this we can create a new organization e.g. Zenon-Community where all crucial repos will be stored and Team organizations fork from there. Actually the same as we now only work under our own management. If Zenon-Network wants, it can always synchronize to stay up to date with the community.
This is the /zenon-network repo. When I look at this all I can think about is the SEC trying to make a case that the community is relying on a central entity. That will be an impossible case to make with this level of activity.
When I look at this it makes me think we are (1) winning, and (2) we need to take over. It’s a very clear message to us. So let’s do it.
Should we focus on HC1 and HCT repos… Or should they roll up to a zenon-community repo? Early on when we debated the ZIP process we tried to avoid centralizing the repos into one gate keeper. We envisioned having many repos that the community started to trust over time. That way one “entity” or group of devs cannot gate keep one repo. Sounds like Bitcoin is starting to think in this direction too. @georgezgeorgez found some nice articles about it at the time.
My preference is to release code from HC1, HCT, and maybe even some individual repos that people trust over time. I guess the question then becomes, how do we do code review / audits?
I agree it is crucial for the community to move forward without waiting for Mr. Kaine to approve code, as already stated he is slow at approving and bad a communicating so if this is holding back progress its time to move on.
HC1 and HCT have both delivered code that the community is running so there is already a level of trust built and with the governance module the pillars will have final say as to what gets approved via a spork.
While I agree its good to avoid centralised control over the repos I also think from an onboarding point of view its more confusing if you have code located in different repos as you have to remember X manages XX repo , while Y manages YY repo etc… so to me having a zenon-community org makes sense. But like 0x says then the issue of code reviews/audits comes into play. Maybe community org could host “core” repos like go-zenon, orchestrator, syrius, etc and fork others like SDKs etc with the emphasis on the original devs to maintain the forks and submit PRs back to community org. Not sure if this is feasible just thinking aloud.
all teams join under the same github organization and transfer repos to it
keep creating PRs for the official repos
What if we proposed to Mr Kaine to give us, the contributors, maintainer roles? And maybe even convert the account to an organization and transfer ownership of it to one of the more trusted community members?
I vote for converting the zenon-network github to an organization and giving all (or at least some) of the contributors maintainer roles and maybe even appointing a trusted member of the community as owner of the organization somewhere down the road.
This will give the contributors more flexibility and it will certainly increase github activity.
But for this to happen it has to be supported by a majority of the community devs. We must prove that we can coordinate.
