This section briefly introduces the proposal
This is an MVP for a specific process to ratify proposals with organization-wide impact.
This proposal is itself structured in the suggested format that it would institute if adopted. Please add questions, suggestions, comments, etc. as comments directly to this document.
This section contains the proposal
Process Details:
- Eligible voter pool: All FTE ConsenSys NDA mesh members are eligible to cosponsor and vote. The aggregate total is the number used to determine quorum. The secretary is the source of truth for this number.
- Proposal submission: Requires 4% of the company to cosponsor.
- Proposal structure: Intro briefly explaining proposal, the proposal for consideration, the general questions and suggestions section, the changelog. (See this document).
- Proposal submission: Proposal written in google docs and shared with evidence of co-sponsorship to
Secretary. - Interim secretary: Sam Wynn.
- Proposal distribution: Sent by Secretary to members email, members channel slack (@channel), and new “proposals” channel in slack (@channel) with link to Google doc.
- Proposal discussion forum: Discussed with questions, comments, and sections by posting comments directly on Google doc (Quip doesn’t comment only permission).
- Document control: Secretary has edit access and controls all changes. All others have view / comment access.
- Debate period: 2 full weeks following the official introduction of the proposal by the secretary.
- Feedback Integration: Original author (one person) has final authority on whether or not to integrate changes.
- Voting period: 1 week following the conclusion of the debate period.
- Voting platform: Google form vote. Must provide email address. Responses spreadsheet made public internally. Options “Yes”, “Abstain”, “No”.
- Quorum: Quorum is reached when 40% of the mesh casts a vote for either “Yes”, “Abstain”, or “No”.
- Adoption: 66% of a quorum votes "yes". All Mesh members have one vote. Calculated per the following formula:
IF AND [Total “Yes” Votes / Total “No” Votes > 66%] , [Total Votes > Mesh Members *.75]
THEN Proposal is adopted
- Veto: Shareholder veto (Joe) within 1 week of adoption.
Best practices:
- Gather feedback and flesh out your proposal prior to bringing it to the entire mesh
- Prevent disaster when appropriate by adding things like a probationary period, a limited duration, a sub-group with the power to roll it back, or success metrics that would automatically terminate the new policy if they are not met
- Please include details on how a proposal would be enforced, with details on how compliance is determined (and by whom) and what the possible reward / punishment may look like.
- Only use this platform for truly organization-wide proposals. Many issues can be worked out within your team or between a small handful of teams without involving the entire company.
In anticipation of a handful of questions:
Q: What would this process be used for?
A: To ratify things like operating principles; salary transparency policies; the 2019 retreat location; or even a proposal to implement v2.0 of the CIP process.
Q: What if it makes more sense to vote on things like our values with a TCR rather than this CIP process?
A: Then put forward a CIP that proposes ConsenSys uses TCR’s to manage our values.
Q: How is a ratified proposal enforced, what’s their duration, is there a probationary period, etc.?
A: These should be specified in the proposal. I would hope that the mesh would not vote to ratify an unenforceable proposal or one that is missing a probationary testing period if it crucially needs one.
General Questions and Suggestions
Please ask questions and post suggestions as comments to specific statements above.
Otherwise ask your question or suggestion as a comment to this section.
Carolyn: This is a great MVP -- A simple proposal and ratification process that I can see getting us the initial set of principles & perhaps usable for other decisions. Specifically for the ops principles use case, I’d like to propose a way of testing principles (maybe 2 or 3 months) post-ratification. Do you think that should constitute a different proposal? Could a proposal for testing the efficacy of ratified proposals be created universally, as to apply to all proposals? Or would we have to make it specific for operational principles?
Rob: I would say that the testing criteria should not be part of this proposal framework, but rather a part of the proposal to adopt that operating principle itself. E.g. I propose that the Mesh should adopt the principle that all information that can be legally shared must be shared in Quip. This principle will be enacted for a probationary period of 3 months, at the conclusion of which the Mesh must reconfirm their acceptance of this principle by doing x.
Will: I like having an MVP. I like that the creator is the owner of the dialog and final decision. That’s contained and doesn’t put much work on anyone else.
What about competing/similar proposals that get 60%? We may need a run off.
Rob: I'm not sure this will happen, and may be something we can pause to address when it does. Similar to the US congress, I would have faith in the mesh to recognize the overlap and incompatibility of two proposals and to give feedback and vote in such a way as to reconcile and adopt one proposal, or remove the incompatible components and adopt both.
Will: The 60% ratification is a key question. Operating agreements are like the constitution. They should be hard to add to and hard to change. Most things should be best practices. Maybe a higher percentage for adoption?
Rob: Makes sense to me. 66% is two thirds. Could do 70% or 80%...
Will: Once its voted on, is it set in stone? Is there a testing and design phase? (Is that beyond the scope of this MVP?)
Rob: Carolyn asked a similar question. I'd said: "I would say that the testing criteria should not be part of this proposal framework, but rather a part of the proposal to adopt that operating principle itself. E.g. I propose that the Mesh should adopt the principle that all information that can be legally shared must be shared in Quip. This principle will be enacted for a probationary period of 3 months, at the conclusion of which the Mesh must reconfirm their acceptance of this principle by doing x."
Will: There are key embedded decisions in here — Joe gets a veto, 60% is enough. Those are major assumptions. I’m concerned about DNA being seen as advocating those at the beginning. It could frame people’s assumptions about the whole project.
Rob: It's a fair point. I have two thoughts. 1) Ultimately someone needs to put forth some kind of process and make firm decisions like this. We can't say the mesh will decide what it wants to do if we can't decide how the mesh decides. 2) The mesh can still reject this framework and can even use the framework itself to change these things. We can make that clear when this is communicated if it gets to that point. E.g., Joe issues a proposal to remove his own veto power, or Bill Gliem issues a proposal to lower the approval threshold to 51%, or Gabe issues a proposal to completely remove this ratification process.
Will: I also wonder about being seen as pushing for a decision on legitimacy quickly. There is a strong case that majority vote is not the best system because new ideas are often minority views. There are ways to protect minority and innovative views in the design and dialog process. That’s an essential advantage of a distributed and iterative systems — minority ideas get to be tested and proved. Mass decisions by majority vote do not have that.
Rob: Similar to my last comment, I think it would be great if someone or a group of people used this framework to propose a better framework. Also, I don't think this framework should be used for things that can be tested in smaller groups. Rather only for things like organization wide operating principles, changes to our mission statement, etc.
Will: Knowing that a lot of people are coming from hierarchical companies, they may not have the background to understand other ways to reach decisions. This may feel comfortable to them, so they vote for it. Not because it fits or works the best, but because it’s what they know. And they may be a large block of votes.
Rob: While both are more traditional and are deeply ingrained mental models for us all, hierarchy and democratic voting aren't two sides of the same coin. I would also say if the mesh thinks hierarchy is best, then who are we to impose a non-hierarchical structure. Rather it would be our responsibility to educate the mesh and pass corresponding proposals so that it could make that decision for itself.
Will: I think we should avoid giving people in the Mesh an easy out to solve a problem before they have heard many voices so they effectively understand the complexity of the problems and the possible alternatives.
Rob: I hope the mesh would be smart enough not to pass hasty proposals, but you're making me realize that corresponding best practices doc for writers outlining things like "hey it's best if you write your proposal with a probationary period and success metrics necessary for its continued adoption" and another best practices doc for the mesh with things like "hey keep standards high. look for research and testing results, don't vote yes without reading up and giving it real thought, ask yourself if a formal proposal is really necessary to solve this issue"
Will: All that said, its a good start. It already worked to get me thinking about what I wrote. That’s the point of an MVP.
Rob: I hope my comments don't come across the wrong way. I've enjoyed reading what you wrote and thinking about your points. Very thoughtful feedback.
Will: If you decide to send it out, I think it should be framed as something to run up against — as an idea to start the discussion, not as DNA’s proposal.
Rob: I agree.
Will: If we have time, I would like to match it with a proposal that has strong distributed/iterative/divergent elements. It would set us up as neutral facilitators for the Mesh discussion.
Rob: I hope that we continue to make decisions in a way that is more distributed, iterative, and divergent...I think the research and creation of a proposal should be done in this way and groups of teams should continue to make decisions however they want (consent based, single owner, "safe-enough-to-try", etc.). I'm merely proposing a mechanism for confirming rough org wide consensus. Does this make sense?
Bill: Great simple proposal and engaging discussion. Very happy to see this format and forum and the direction of the results.
This section details the changes made the proposal since its initial release
10:48AM:1/16/2018
Original: Proposal distribution: Sent by Secretary to members email and members @channel slack with link to Google doc
Revised: Proposal distribution: Sent by Secretary to members email, members channel slack (@channel), and new “proposals” channel in slack (@channel) with link to Google doc
Purpose: I liked the suggestion made by Carolyn for a #proposals slack channel
12:48PM-EST:1/18/2018
Original: Adoption: 60% of total mesh members (minus the number who vote “Abstain”) vote "yes". All Mesh members have one vote.
Revised: Quorum: 75% of the total mesh members participating in voting
Adoption: 66% of quorum votes "yes". All Mesh members have one vote.
IF [Total “Yes” Votes / Total “No” Votes > 66%] , [Total Votes > Mesh Members *.75]
THEN Proposal is adopted
Purpose: Understanding that many mesh members likely won’t bother to engage in voting no matter what the topic is even given a one week voting window
3:42PM-EST:2/12/2018
Original: Quorum: 75% of the total mesh members participating in voting
Revised: Quorum: Quorum is reached when 40% of the mesh casts a vote (“Yes”, “Abstain”, and “No”)
Purpose: To allow for a lower, less cumbersome quorum limit and clarify what constitutes participation.
4:21PM-EST:2/12/2018
Original: Proposal submission: Requires 20 cosponsors.
Revised: Proposal submission: Requires 4% of the company to cosponsor.
Purpose: To prevent spamming as the organization grows
4:30PM-EST:2/13/2018
Addition: Eligible voter pool: All FTE ConsenSys NDA mesh members are eligible to cosponsor and vote. The aggregate total is the number used to determine quorum.
Best practices and FAQ added to proposal
Purpose: Clarification