DFINITY Foundation’s vote on Governance proposal #96475

[diegop]

@LightningLad91

I suspect that future motion proposals will be contentious due to subjective views about whether there’s a clear path to code changes. I would appreciate if you or @bjoernek can explain what the minimum criteria is. For example:

• Do we need to provide actual code examples?
• Do we need to provide a preliminary architecture?
• Do we just need to state “This proposal could lead to code changes”

Several people have made arguments that this proposal could have led to code changes driven by follow-on proposals. Does DFINITY not agree?

I have zero issue with DFINITY voting to reject this proposal. I’m just confused by the reasoning and what that means for future proposals.

Very good questions @LightningLad91.

I think at this point in the dialogue it will be helpful to reveal a bit more about my own thinking before I explain more of DFINITY’s.

1. My own thinking

I was originally in favor of voting YES on proposal #96475 before and I subsequently changed my mind after internalizing @bjoernek 's argument. So I had a lot of the same questions you have and I also had time to interrogate my own thinking and @bjoernek 's argument. Ultimately, I was swayed by the argument. This of course is not unique (specially in this case where Bjoern was the closer domain expert since he had put more time to think on it). I have both swayed and been swayed many times at DFINITY. ICP is very important to us so folks analyze things.

As a DAO, it is important to me that folks have healthy dialogues to explain their positions and folks feel free to make their own mind.

2. To answer your specific questions…

I do not have a grand strategy for explanation, so it is best to just lay out each question and answer it as honestly as I can.

@LightningLad91

• Do we need to provide actual code examples?
• Do we need to provide a preliminary architecture?
• Do we just need to state “This proposal could lead to code changes”

No, this is an understandable interpretation of what DFINITY’s “code to path” is, but not what we intend. The tenet is more akin to:

• A proposal for websockets support (with no architecture or code samples) is a feature and would pass the “path to code” test because it is feasible (which is the other DFINITY tenet, “faster than light consensus” is not). Now, DFINITY may agree or disagree with the feature itself, but it would pass the “path to code”.

• A proposal to change a tokenomics parameter would similarly have a “path to code” (regardless if the proposal was all tokenomic analysis), independent of what DFINITY thought.

Inversely…

• Proposal #96475 was a proposal to make future proposals about how to think about future feature proposals. I am not trying to paint a caricature, more laying out how many degrees it was from a concrete feature. To be perfectly honest, this was a bit too meta for the tenet. If you squint you can argue it falls within the “path to code” tenet (that was my original position), but it was a stretch so I changed my mind as well. Now, i have probably submitted proposals that would not pass this tenet in today, so I am in no way criticizing folks, just saying DFINITY’s bar changed.

However… NNS is permissionless, if someone wants to propose a feature X and then explain with their own principles, they totally should!

This is why DFINITY’s position is much simpler than people may interpret: it has a list of filters that make it a default NO.

To quote @Manu who once described it very well:

@Manu

I’d rather see the ICP ecosystem move to a policy where you vote yes if you’re very convinced that the proposal is good, and vote no otherwise (irrespective of whether that meant you think it’s a bad idea or you just didnt understand all the details, or you think it’s too early etc).

This is why a NO is more of a cultural default to DFINITY, unless it believes a YES is very important.

This is an example of “raising the bar” on the tenets.

Ironically (and I really do mean ironically), this organizational conservative temperament of only voting YES when absolutely convinced/necessary is part of the initial intent behind these proposals in the first place. DFINITY cannot control other entities so it is fair to say it is just consistently raising the bar on its YES votes… and also trying to communicate the intent of the NO votes. Sometimes a NO vote may be because it did not understand it, it was too far from a path to code, its infeasible, etc…

This is one reason @bjoernek added:

@bjoernek

We want to be clear in what this means and does not mean

While we vote NO on the proposal, we think it is a reasonable proposal created in good faith. We also very much appreciate the careful syndication of this proposal, which included concise write-ups, forum deliberation, and presentations in the governance working group & in Twitter spaces.

We DO think it was a good faith effort. It just did not pass our internal bar.

As someone who changed his mind on this, I can appreciate some doubts so I can share my own journey thinking about this.

3. Relation to past proposals

I do not think early proposals had a baked philosophy or tenets. Patterns are still emerging as we learn. I wrote the rationale of a lot of proposals last year so I can say that some thinking has changed, but mostly it has been revealed by each proposal, each vote, each community conversation. Every proposal helps us understand more and more about we care about and do not care about, so still lots of room for case-by-case analysis + iteration.

4. Conclusions

We envision a world where many entities have different goals and principles in running this DAO.

This is one reason, I think it is most helpful to explain DFINITY’s position and vote… instead of trying to convince folks to change their own.