Voting on SIP-015 is compromised by CAB members also being authors of the SIP. For example, the Technical CAB has at least four out of nine members listed as authors of SIP-015. CAB members that also are authors of a SIP should be restricted from voting, or at least recuse themself.
In my opinion, this is only evidence that the SIP is broadly supported by the community, such that even the most technically literate and active members of Stacks have officially signaled their support and authorship towards the SIP. Moreover, as a CAB member myself, who is not an author on the SIP, I (or any other of the dozens of CAB members) could speak up in the event that there was anything untoward happening.
Ultimately, we are a small ecosystem, and therefore there will be some overlap in these areas. But, trying to delay essential network upgrades that are widely supported by massive swaths of the ecosystem (pick your method of polling to confirm this) will ensure that we always remain a small ecosystem, and perhaps a dead one. I am not being hyperbolic here — this is a reality we must all face. Let’s not get in our own way on this.
3 Likes
Maybe it would be more effective to address the subject directly vs indirectly. If educated CAB member opinions are being ignored or not being given sufficient consideration, then this is probably what should be openly discussed. Discussion, even heated, about how some things should be done, and possible ramifications… it’s all good, right?
+1 Crypto moves super fast and there is a LOT of competition for attention and $.
And naturally there will always be differences of opinion on how much focus should be placed on moving fast versus more testing and design analysis, especially since blockchains are harder to change once released than traditional software.
@njordhov if there are things that you firmly believe are clearly wrong or mistakes or could be done in a better way (in your experienced opinion) that are not getting sufficient consideration on Github, then I think you should not be shy and voice them. We all assume you are acting in good faith. So if there are things you think could harm the Stacks project, we should all want to hear them and have them discussed and addressed. Of course it’s easy for me to say as I’m not part of the very busy core dev team.
1 Like
Yes, and to just drive the point home more directly: in less than 12-18 months, the Stacks applications with most network activity (e.g. Gamma, ALEX, likely others) will be dead if we don’t move quickly on a solution to improve the network’s state (speed, scalability) and it’s association with modern/native Bitcoin addresses and native Bitcoin operations; these things aren’t even largely addressed in this network upgrade — many of them come in the next upgrade which will only be delayed by this one’s delay.
This is an existential crisis and should be treated as nothing less. We do not have the luxury of getting into a ideological debate about the SIP process right now. It’s like reorganizing deck furniture on the sinking Titanic. Let’s move with purpose and intention, but let’s move at warp speed; the future of the network depends on it.
2 Likes
We have to move quickly, yet at the same time not make fatal mistakes that put the network and ecosystem in the wrong direction and at risk. SIP-015 might be too big to fail as rejecting it could lead to an existential crisis. It includes widely desired improvements such as better block validation and improved stacking experience.
As a resolution, I have suggested factoring out the Clarity-related proposals in its own SIP, so we can move forwards with the rest of SIP-015 without further delay. This way, core Stacks 2.1 improvements such as stacking experience and block validation can be independently tested on mainnet, allowing bugs in the core to be fixed before deploying the upgraded Clarity VM. The community will be able to properly consider the proposed changes to Clarity, hopefully avoiding the mistakes inherent in the current design and implementation.
1 Like
I would suggest this be broken out into it’s own discussion - or has it already other than on github?
On a Stacks core engineering call maybe? or it’s too narrow a subject for that. So here or Discord then?
I have never been shy about voicing my concerns. You can find some in the discussion for the SIP-015 PR, such as: https://github.com/stacksgov/sips/pull/95#discussion_r1008931985
1 Like
The key is stay positive, constructive and seek the optimal solution all things considered as apposed to just trying to win the “my way is better” argument.
Also, you may not be aware of all the reasons for a particular design decision.
I think it’s great that you take the time to participate and I hope you continue to do so.
any other of the dozens of CAB members) could speak up in the event that there was anything untoward happening.
Check. I am a member of the Technical CAB reviewing SIP-015.
The deadline for the Technical CAB to vote on SIP-015 has now passed. Four of the nine members of the Technical CAB voted in favor of approving SIP-015.
I understand the worry here, and I agree that it absolutely makes sense for a single or dual-author SIP that has not been discussed heavily in the community. For SIP-015 though, there is a long list of authors from various entities, an equally long list of implementors, and as mentioned above, strong support from the community. It seems unnecessary to limit this SIP in this way.
The Technical CAB has reached the predetermined requirements for an approval at this point – we hit a quorum of 5 voters and a majority approved (4 out of 5). As discussed in our chat, we will publish the concerns of the approving CAB members, as well as a dissenting opinion.
I also share some of the concerns above of delaying this SIP for a perfect solution, but I would be happy to continue to discuss your concerns, and hope that we can continue to improve upon these issues after this particular SIP has passed.
1 Like
Having the same people sign off a SIP as authoring it leaves the impression of a rigged system with lacking oversight. The concern with SIP authors voting in a CAB to approve their own SIP is of even greater concern when there are many authors and a substantial overlap with CAB members.
I really do understand your concern here, and I’m not trying to ignore it and push this through, just trying to be pragmatic. Looking at the Technical CAB, if I remove those of us that are authors, that leaves us with 6 members eligible to vote, meaning a quorum of 4. In that scenario, we have also reached our requirements for approval. I noticed that I missed one vote in my earlier count (one approval was in a separate comment), so it is actually 5-1 counting everyone, or 3-1 discounting those members who are listed as authors.
1 Like