Community Sentiment Polling Results (NU4) and draft ZIP 1014

Community Collaborations protocol
266

A couple suggestions:

If you ask “Do you believe A or B?”, the options should be in the order A and then B, for clarity, so how about reversing the order of answer options for the Major Grant Review Committee question?

For the funding cap question, the answer

could be changed to include the word "additional’ in front of spending restrictions, or even better yet just leave it as “The other accountability requirements prescribed in the ZIP are sufficient”. The last part of that answer saying “there shouldn’t be funding restrictions” is a bit misleading since the ZIP does list several restrictions such as “ECC must undertake a firm obligation to use the Dev Fund only in support of the Zcash cryptocurrency and its community.”

One other possibility that I actually think is the best of all is to simply negate the first answer option: “There should not be a Funding Target and Volatility Reserve for each slice as prescribed in the ZIP” This is better because the opposite of wanting a funding cap is not wanting a funding cap, but the question makes it seem like that opposite of a funding cap is the belief that the other requirements are sufficient, which is really not necessarily the position of someone who doesn’t want a funding cap. I also think the term “Funding Cap” should be used instead of “Funding Target”.

Overall I think it is important to recognize that it is possible to drastically sway the outcomes of polls by making subtle changes to the wording, as has been demonstrated by many academic studies. I do not mean to imply any bad intent, but I do think that we should try to reach a consensus where all of the poll questions have a neutral tone that won’t impact the results. :slight_smile:

3 Likes
267

What are the differences between the cap and no cap scenarios if we assume accountability requirements were strengthened elsewhere and they would basically both work to the same end result (it all works out you know), what differences are made from y’all’s (the ZFND and ECC) perspective about this? (I’m only trying to get a better understanding of this because it seems to only affect your two organizations given the end result from my perspective would be identical but I’m the one being asked to weigh that decision)

268

Hi @acityinohio.

Did your position on taking time to explore new ideas change since this agreement with Zooko in December?

My personal perspective and recent comment on funding levels for ECC activities shouldn’t be confused with the ECC stance on a USD-based cap. They are different things. My apologies for causing confusion on that matter. Thanks Josh.

3 Likes
269

Given the current information I would say I support the cap based on how it intrinsically pertains to Community sentiment, accountability requirements will be used to determine whether future funding even continues where has your internal employee incentive alignment mechanism kind a falls within your own internal purview (a lot of people here don’t even know how all that stock incentive works).
This is really the only ground I could find for taking a stance either way because honestly it seems like a compromise by either side, increased accountability requirements to fill the cap Gap or getting creative with said incentive alignment mechanism, seem pretty feasible

2 Likes
270

(Speaking for myself.) The actual value of the cap can obviously be highly relevant to whether someone approves of it. I disagree that it will be as easy as has been implied to change the value of the cap. The draft ZIP says that “The Funding Target SHALL NOT be changed other than by unanimous agreement of ZF, ECC, and the majority vote of the Community Panel.” This agreement could be highly difficult to achieve. Therefore, anyone voting on this question cannot assume that the cap will in practice be set to a level that they would agree with, if they disagree with the initial level.

(For the record, I oppose the cap.)

3 Likes
271

(With ZIP Editor hat.) I agree with this and propose to change it in the draft ZIP, if there is no objection from @acityinohio? It is a clearer description of what this provision is.

I couldn’t agree more!

4 Likes
272

I used the term “Funding Target” in my proposal to reflect the fact it works both ways:

  • Excess, if the Dev Fund value surpasses the monthly target, is deposited to the reserve
  • Deficit, if the Dev Fund value falls below the monthly target, is covered by withdrawing from the reserve (unless it’s empty)
3 Likes
273

Daira,

Can you share (in your personal opinion as a ZEC holder and also as Zcash core dev) why you oppose “Funding Target”?

2 Likes
274

(With all hats on, since this is just a matter of English usage.)

The draft ZIP says that the maximum amount that may be used for funding from each slice is 700,000 USD/month. This applies regardless of the ZEC/USD price. Therefore it’s a cap on the amount of usable funding per month (for each slice).

I’ll defer answering @dontbeevil’s question until we’ve agreed on the terminology.

2 Likes
275

An alternative name would be “Monthly Funding Cap”, if that would help to clarify further.

2 Likes
276

Monthly funding cap and target means the same with full context. Generally,
“Cap” indicates there is a max.
“Target” indicates there is a goal to reach. You can be ahead of goals.

So, “Cap” sounds more appropriate to me.

1 Like
277

Hey friends, I see recent comments from Josh Cincinnati, Aristarchus, and Autotunafish that I think we need to respond to.

As we stated in our recent blog post, The Electric Coin Company will not accept funds from a Dev Fund if it comes with a fiat-denominated funding cap, but other than issue that we see no reason why we wouldn’t accept the role under all of the other terms of ZIP-1014. The reason why we wouldn’t accept the funds with a fiat-denominated cap is that we will only accept a role if we believe that we can be successful at it, and we believe that the long-term incentive alignment between coin-holders and developers is necessary for long-term success.

In my recent comment on this thread, I mentioned that we had other concerns that would not prevent us from taking the role, but that we still wanted to raise before finalizing ZIP-1014 and the ballot. I subsequently raised the most important one of those on github. It has to do with the wording around “Audited financial report”. Eran Tromer and Josh Cincinnati both posted on that issue ticket saying that in their respective opinions it would be fine to remove the requirement for audited financial reports, but it isn’t clear to me if this means that language will be changed in ZIP-1014 before the final polling or what. ECC is fine with that requirement staying in or being removed (see the github ticket for extensive discussion of pros and cons of the requirement of audited financial reports), but I think it should be clarified before the voting so that there’s no question of what the voters were voting on.

I said that there were “concerns”, plural, but my remaining concerns about the language of ZIP-1014 are less important, and I believe they can be handled after the final polling without changing the text of ZIP-1014.

Of course, there are lots of other considerations and hypothetical questions we could explore, but there are diminishing returns to that sort of discussion. We believe that it is more valuable to proceed with the plan that ECC and Zfnd have agreed on, to move ahead on a final vote on the terms that have already been discussed and have already received substantial community support.

As Aristarchus’s post correctly notes, the wording of a ballot can have a dramatic effect, and it should be worded as clearly and neutrally as possible in order to avoid confusing or swaying voters. Here’s our proposed ballot text, in which we attempt to include exactly the questions that Josh Cincinnati’s recent post on this thread suggests, while making the wording as clear and neutral as possible:

Do you support the ZIP 1014 presented here? ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants (ZIP 1014 is a lightly modified version of ZIP 1012, which had the most support in the previous sentiment collection poll. Note that all follow up questions in this poll assume ZIP 1014 as a basis)

  1. Yes
  2. No

Should there be a Funding Cap/Volatility Reserve for the shares to ECC, ZF, and Major Grants? Notes: ECC has indicated they plan to decline their funding if a US Dollar-denominated funding cap is imposed. We are not measuring your approval of the specific amount of the Funding Cap in the ZIP; we are interested in your approval of the concept as a whole. The amount can be set by processes outlined in the ZIP.

  1. There should not be US Dollar denominated Funding Caps
  2. There should be a US Dollar denominated Funding Cap and Volatility Reserve for each slice as prescribed in the ZIP

If the Zcash community votes in favor of a US Dollar denominated cap and ECC declines their funding, where should their slice be redirected?

  1. Major Grants
  2. Zcash Foundation
  3. Miners

If the Zcash community votes in favor of removing the requirement for a US Dollar denominated cap, what should the distribution of the dev fund slices be?

  1. ECC: 50%, MG: 25%, ZF: 25%
  2. ECC: 45%, MG: 30%, ZF: 25%
  3. ECC: 40%, MG: 35%, ZF: 25%
  4. ECC: 35%, MG: 40%, ZF: 25%

Do you believe the Foundation should have independent authority in determining Major Grants, or should there be a new Major Grant Review Committee as prescribed in ZIP 1014?

  1. There should be a new Major Grant Review Committee with near-complete authority as prescribed in the ZIP
  2. The Foundation should have independent authority in determining Major Grants
10 Likes
278

There is a new term if we want to enforce: Maximum Monthly Spend (USD)

279

@daira @dontbeevil I’m in agreement with changing the wording to “Monthly Funding Cap” and would be happy to open up a PR for that on ZIP 1014. I was somewhat concerned that @daira/@gtank may want to keep that ZIP as it exists for historical preservation, but if y’all don’t mind I’d rather do that (likewise with the “audited” wording @zooko, which I can open a PR for as well). Then everyone can have the latest version of the ZIP to read through before the poll.

@daira I guess it’s a matter of personal opinion/speculation, but if the community votes for a cap I for one don’t think it would be difficult to change the cap amount immediately after the ZIP is active/before NU4 activation. In the scenario where the largest slice is 50% the current price of ZEC would have to be 2x to reach the cap, and again I suspect that could be resolved between now and NU4 activation.

Nope my position hasn’t changed; as far as I can tell the poll/ZIP incorporates ideas that were discussed during the initial proposal/polling period.

Thanks for clarifying that it’s your personal position @joshs, I appreciate it. Given that, I’d like to reiterate a desire to see detailed reasoning from the ECC on why my proposed solution to the employee incentive issue is not tenable; I suspect it would make many community members rethink their position on the cap.

@aristarchus @zooko thanks for your feedback on the poll. I completely agree about the wording choice being critical to neutrality of the poll and the Foundation will take your suggestions into account before publishing the final poll next week. I’ve also received private feedback that there should be opportunities to vote “approve of any option” on more of the questions, which the Foundation plans on taking into account.

Note that there are some formatting restrictions in what can be posted within Helios ballot questions (no line breaks or hyperlinks, for example) which also inform how the questions should be constructed/presented. And FWIW the suggested wording on these questions has already been greatly informed by community feedback (e.g. this comment from @mhluongo ) and the Foundation takes concerns around anchoring and bias very seriously.

9 Likes
280

A thought - How about if the poll asked what the amount (if any) that the cap should be? Options could be None, 700k, 1.1m, 1.5m, etc

Those choices, plus appropriate wording that ECC will likely to decline any option other than ‘None’ - would work well.

IIRC there was a comment that ECC would like 1.1m per month to execute their full plan, so a cap equal or greater accomodates that while still providing a control for wild price volatility.

281

[With ZIP editor hat] No need; merged in PR 314.

2 Likes
282

[With ZIP editor hat] I’ve opened PR 315 for removal of the word “audited” from “Annual audited financial report”. (@acityinohio and @tromer had expressed approval of this on issue 313.)

Edit: this has now been merged.

2 Likes
283

(Speaking for myself.) I don’t understand why it’s desirable to vote on a cap before knowing what it will be. Each voter might be in (at least) any of the following categories:

  • voting yes to a cap, hoping it will stay the same / being unsatisfied at any increase
  • voting yes to a cap, because they would accept it at any level
  • voting yes to a cap, because they want it to increase and are optimistic about it doing so
  • voting yes to a cap, because then ECC will refuse the funding and that’s the outcome they want
  • voting no to a cap, because they approve in principle but want it to increase, and are pessimistic about it doing so
  • voting no to a cap, because they disapprove even though they would have tolerated it at a higher level
  • voting no to a cap, because they wouldn’t accept it at any level
  • voting no to a cap, because they personally don’t care but want ECC to accept the funding in the ZIP

but since they can only vote “yes” or “no”, there’s no way to distinguish what they actually meant.

5 Likes
284

Why then not put forward the vote as it should initially be an offer from ECC, which they will accept and the second to leave the original proposal that the community accepted but did not accept ECC. Why then all this explanation in each paragraph.

1 Like
285

This impass should be cleared relatively easy if we ask which one of these scenarios is more conducive or less obtrusive for the project
I stated what I thought assuming no further constraints based on relatively little information so you know idk :vulcan_salute:

1 Like