N=1, but my vote approving #12 was in spite of the cap, not in its favor. I thought it one of the best proposals overall, but my vote shouldn’t be counted as community support for the cap. Of course I don’t speak for anyone else either.
My reason is like @joshs and @aristarchus: given the intensity of competition we have a better chance of success with top employees with serious long-term skin in the game. I’ve worked at a startup myself and would not do it again without that. (I’m not looking to work for ECC; it’s just that I’m not sure this point is getting enough weight.)
Different project, different context, different vision/goals, but perhaps some useful food for thought from a team that’s been conducting radical experiments with decentralized governance (includes reflections on budgeting, third party developers, separation of powers, interacting with and attracting users): The Aragon Association in 2020
Sorry I missed responding to this before @mlphresearch it’s become a dizzying thread.
I neglected to say so before but I think option this would further complicate the proposal — particularly for variable-length Major Grant recipients which would create more uncertainty. There’s already a method in ZIP 1012 in the case of violation/enforcement which matches the current state of the trademark:
Moreover, if the community desires a change to the rules, an interested party can always submit a new ZIP and the Zcash ecosystem can evaluate its merits and escalate with a similar decision making process as we have now; we can initiate that process dynamically and only in the case that something needs to be addressed.
Again sorry I missed this earlier! Yes absolutely, my personal goals for this body are to make it larger, broader, and more inclusive — and ideally remove as much arbitrary Foundation selection-criteria as possible (i.e. eventually make it self-selecting).
My suggestion was meant as an explicit alternative to funding caps that would guarantee ZEC allocations for max 12 months, regardless of price.
So, if monthly caps were removed, the current proposal would still allow for changing the allocations and/or governance rules (assuming majority support in a community sentiment poll), even if fund recipients disagree with the decision? If so, then the question can indeed be simplified to Yes/No on funding caps. Perhaps someone from ECC can comment whether they see the two options as equivalent.
No problem, thanks
Would that (i.e. increasing membership) happen before the Panel is asked to make further decisions and what is the criteria for including new members? Given that the Panel would be responsible for determining the membership of a new grants committee (if indeed a separate body is created), these feel like important details to disclose prior to the final vote.
To all the keen watchers of this thread: @zooko and I just had a call and agreed on both the ECC and Zcash Foundation’s next steps for defining a ZIP with clear community consensus.
In order to collect clear community sentiment, the Foundation will run a final Helios poll using the modified ZIP 1012 as a basis which include key questions for the community to decide which were already published and discussed in the previous round of voting. There were multiple new ideas brought up in this thread from different community members and we aren’t expressing an opinion about the merits of these ideas, but simply that if we were to include new ideas the community would need more time to evaluate them — time which is in short supply.
I will add precise wording of the poll to this thread after the poll has been assembled but most of the questions won’t deviate too much from the earlier suggestions I had. The poll will ask about general support for the Foundation’s modified ZIP 1012 as a basis, supported percentage ranges for each slice outlined by the ZIP, the Foundation’s authority regarding the Major Grant Review committee, and whether there should be a Funding Target/Volatility Reserve for each slice or not (“cap” vs “no cap”).
The constituency of this final Helios poll will be a combination of the forum users who participated in previous sentiment collection process and the community advisory panel, whom I will be reaching out to shortly.
Based on the results of the poll we will further modify the ZIP to reflect the community’s preferences and present a final ZIP.
We’re both thrilled with the progress the community has made and are excited to conduct this final poll, and the ECC and ZF are optimistic it will lead to a final ZIP with clear community consensus and a path forward for NU4.
@acityinohio, @zooko: this sounds very reasonable! A couple of questions:
Will the parameter-questions be given as approval votes, or “pick one”, or with an “any of the above” option? Personally, I would like to be able to indicate that I support any of the variants you mentioned, and would like my vote to contribute to the legitimacy of whatever is the final decision.
As for the “cap” question, will it be just two options, “Funding Target, initially $700k/month” vs. “no Funding Target”? Or will you also explore adjustments to the initial USD amount?
How about adding a very first question: Should the proposal be modified at all or kept as it is?
I mean in theory there is a chance that a majority of voters/community do not want to have the proposal changed/modified in anyway. Hence such question should be a must as question 1. IF for example the majority of community feels like the proposal should not be modified it would be against the first community vote to offer a bunch of modify options without the initial option not to modify anything.
With the caveat that I still need to get ECC and board feedback/approval on the final poll, I expect we’ll have the options I listed above for the percentages and “any of the above” (good idea!) with users picking between those five options. Ideally we’d use ranked-choice voting but unfortunately that isn’t supported with Helios without doing really user-not-friendly workarounds (i.e. doing 4! = 24 choices for a single question)
It will just be two options, and the rationale is two-fold:
Since we can raise the cap as outlined in ZIP 1012 we can always engage in that process if necessary.
We’ll get a clearer signal on whether the community supports the concept of a Funding Target/Volatility Reserve or whether they prefer no fiat-based constraints to the slices.
No, it shouldn’t be like that. With such formulating, at least in my opinion, we remove allready the first community vote and head to another modified proposal.
In my opinion the first question should be more like:
The community voted for Proposal 12 (ZIP 1012) do you want to:
keep it as it is
have it modified in several terms (see below)
abstain
The difference might not look big but it is actually. I mean the community just voted for proposal 12, hence everything from here should begin with the original version and not with an allready modified one.
To get the complete breakdown of opinions, it should be something like:
Do you support…
The original ZIP 1012
The modified ZIP 1012
Neither
Abstain
EDIT: By the way, this makes more sense if the modified proposal does not include monthly funding caps / volatility reserves by default, and the option of adding these are addressed in a separate question.
An update on timelines here after discussion with the ECC: given the fact that the winter holidays are right around the corner — and we want to honor the rare opportunity for community members and ZF/ECC employees to reflect and relax — we’re going to put a pause on assembling the poll and the final Helios vote until after New Years.
I know that may be disappointing to some, but I suspect it will lead to more engagement and a better outcome on the final poll. Thanks for understanding and I hope everyone has a good holiday break.
Yay! Everyone gets a holiday this year! Thank you, Cin. Looking forward to drinking scotch and playing video games with my kids all day. Happy Holidays, everyone!!
I was asked to contribute some of my thoughts here in the hope that it can be helpful in some way.
For context, I think one of the few things the Ethereum project got very wrong was leaving out a vesting schedule for the first 50-100 people who contributed. Nearly all of those people are now working on competitors or furnishing their holiday homes.
Here is the debate I engaged in on Twitter:
I was lucky enough to stumble across Stripe in 2012 and Ethereum in 2014. I have seen two projects go from around 30 people to thousands. I have seen their value go from millions to billions. Money is a weird thing.
With each project, I was only involved for a matter of months. I then saw what happened over the years afterwards.
I would strongly recommend having a 6-month cliff and an increasing amount of reward over time. Snapchat gives people more stock each year for 6 years. If someone lasts 6 years, they are usually extremely valuable. If someone is toxic in the first few months, they need to go.
I am sure this is not a new sentiment. I just thought it might be somewhat helpful.
I remain concerned (speaking for myself, not for ECC or as a ZIP editor) about the ECC’s status when applying for Major Grants, relative to other applicants.
@tromer has said that “If ECC is not allowed to compete for Major Grants, then its dedicated slice [would need] to be much larger.” However the Major Grant awarding process has an inbuilt bias against ECC, specifically:
This is very likely to preclude ECC from actually being awarded any Major Grants — even in the short term, if alternative applicants show up immediately. Under these conditions, how can ECC management and developers have any confidence they/we are not just wasting time and effort in making Major Grant proposals?
It might be fairer and more effective to just increase ECC’s dedicated slice and bar them/us from applying for Major Grants. (Again, to clarify, I’m not speaking for ECC here.)
An advantage of that approach is that ECC would no longer be financially incentivized to cast work that it would need to do anyway as Major Grant work, which arguably would be a perverse and unproductive incentive.
I just noticed that the current PR has a recently added extra sentence relative to ZIP 1012 (and what @tromer quoted above):
[new sentence in bold]
This introduces a couple of problems:
There is a perverse incentive for ECC to drain the Volatility Reserve in order to be able to apply for Major Grants (especially, but not only, if the amount in the Volatility Reserve is fairly small compared to the potential grant allocation).
If the short-term coin price spikes so that a Volatility Reserve is created, then ECC is immediately excluded from applying for Major Grants — even if plans to make a grant application were in progress. In other words, ECC is effectively penalized for the coin price going up!
IMHO these are serious problems and the extra sentence should be removed.
Together with the following paragraph:
… ECC could be virtually excluded from obtaining Major Grants.
I am skeptical about the funding caps in general, but I’d like to ask a more specific question: why are the caps $700k/month for all slices, rather than being in proportion to the percentages in each slice? Also, how was the figure $700k/month decided on?
Looking forward to drinking scotch and playing video games with my kids all day. 
Happy Holidays, everyone!!