@josh I challenge you to include a clause in your dev fund extension proposal/ZIP that specifies ongoing decentralised governance that allows ongoing adjustments every network upgrade (if needed). Since we don’t have holder voting mechanisms yet I’d settle for some multi org/dao/polling with some large amount of voting rights reserved for more formal holder voting mechanisms when they come available.
i don’t believe invalidates my proposal. i combine ECC/ZCG. So it effectively would give the % allocation to ZCG and if they choose to fund ECC they can. It might need a minor word change or simply remove ECC from the combination. But it would still work as is if ECC removes themselves.
1 Like
@Dodger rgarding the poll, it feels poorly formed. I assume your intent is to use these results to determine which proposals (or adjustments to existing proposals) should be made and voted on in a subsequent poll.
Here are a few examples to illustrate the issues:
- Assuming 20% of voters don’t want to continue the dev fund, they will likely vote for 0% and 1 year. This might lead to a misinterpretation that there is high support for a 1-year extension as @josh has proposed when, in fact, it’s driven by those who oppose the dev fund altogether.
- The community’s opinion on Bootstrap is irrelevant since it’s an invalid option. If you want community feedback on Bootstrap’s decision regarding ECC’s stance on receiving dev funds (which is a valid question), it should be a separate question and asked specifically. Do I recommend ZF do this? No, due to the potential for too much drama. However, ZecHub or another body could do this if they wanted.
- What if I want to vote for 23% but only if there is a declining schedule? The current format doesn’t allow for this flexibility.
These are just a few examples of how the poll can lead to misleading results or fail to capture nuanced opinions.
6 Likes
On question 4, I am assuming that you mean direct funding from the chain and not funding through indirect methods. It’s not clear.
If you mean direct funding from the chain, and ECC has already communicated that we will not accept direct funding from the chain, its unclear why you included ECC in the list.
I also thought that Qedit would only accept indirect funding through a third party and not direct funding from the chain. If so, its unclear why you included Qedit in the list. Perhaps I’m wrong but has anyone verified with them?
This is also and important distinction because a situation where a vote leads to dev funding going to ZF, ZCG and Qedit might then require all funds route through a ZF controlled wallet. I’m not clear on whether, knowing that, the community might vote differently. And I’m not clear on whether that would be an acceptable outcome to even ZF itself.
Regardless, as a ZCAP member who also received the request for feedback on this poll, my opinion echos the concerns of others above. I hope you will listen to them. It’s a poorly constructed survey that will lead to more confusion than clarity.
If people like us that are engaged with, and have been following all this day-to-day are confused by its structure and omissions, it is likely that ZCAP members will also be confused.
4 Likes
Hi @GGuy,
I think we have a myriad of options. 
Option 1 is to let the dev fund expire, Option 2 is to extend the current dev fund (my proposal), but we could also choose to work through revisions of other proposals and simply let the dev fund expire until there is clear community consensus on the right path forward. That would halt the dev fund for a period but not necessarily indefinitely.
With due respect, no one asked us about whether we would accept the inclusion in these other proposals. Assumptions were made. In hindsight, I think it would be a good idea for proposers (both in plans and poll creators) to check with the affected parties to check if they are agreeable to what is being proposed on their behalf. They might not, or may have certain stipulations.
2 Likes
In that ZIP, I am advocating for a one year extension with a mandate for the community to work together on non-direct funding models. A non-direct funding model could emerge during that time, that allows for ongoing governance changes.
I believe the idea with the funding bloc (separate from this ZIP) satisfies what you are looking for but I’m happy to speak with you on it. This is a little off topic and so happy to take the conversation to the ZIP post as well.
3 Likes
@joshs, with all due respect, I hope you’re not suggesting that the decision not to inform the community/proposer sooner about not accepting funds was because “no one asked.” This lack of communication has contributed to the current poor state of affairs, and it’s disheartening.
As you’re aware, I have long advocated for greater involvement of ECC and ZF in the development fund process. I commend you for taking steps in that direction 
.
1 Like
As I stated in a different thread;
I see only 3 real pathways:
- fully expire the fund
- 1-year extension and setting of the Zcash Funding Bloc
- no extension and setting of the Zcash Funding Bloc
Pathway number 3 would ensure people work hard to get there.
2 Likes
The question to ZCAP does not approximate the q1 question of whether or not to extend the devfund. The questions are very different. For instance, do I agree in principle that a new devfund mechanism could be agreeable? Sure, maybe. We’re open minded people so, almost everyone can vote, “sure, maybe something new could be good.” Maybe I believe that some decent mechanism could exist in principle. But, maybe I believe that a new devfund should under no curcumstances go to a corporate entity with a politicized executive director position. So, my vote “Yes” can somehow be interpreted as a vote to extend the current funding? The question says “new” and “replace.” The ZCAP question might as well be, “can you imagine any devfund mechanism you would support?” Sure, we’re all imaginative people. Almost anyone can imagine something that they would support. Yes answers to the ZCAP poll should not be construed as supporting a “new” devfund that is substantially similar to what has been in place.
If you want to use a poll to support a position, the poll question should probe the position more directly. Using that particular ZCAP question to support the idea that “the community” prefers having a devfund to not having a devfund is incorrect.
4 Likes
Correct. 
#1, #2, and #3 should be voted on asap because in the event the community chooses #3, we should give ourselves as much time as possible to consider all the options and make a decision by July. It’s important to note that #3, the “no extension” choice, doesn’t necessarily mean that the community will go with the Funding Bloc option. As a community, we could still choose the direct funding model or something else that gets proposed between now and July.
For #2 I would also add an option that lets respondents choose a 1-year extension without committing to the Funding Bloc (non-direct funding model).
Personally, given the amount of uncertainty about all the possible options and the amount of insight people continue to contribute to this conversation, I don’t think a well thought-out model is possible by July. What I like about the proposal to extend the dev fund by up to a year, is that we can still implement whatever model we decide on before the year is over. I believe that there’s enough hunger for change, people are motivated to get this done. Very few people will actually want to drag this out for another year. But having a few extra months could mean the difference between something that works longterm and something that creates a bunch of new problems.
1 Like
Since I concentrated on unbiased statistics in college, I’ll take a stab at making questions that get to the heart of some of these issues directly without bias. Note that these polls will be anonymous to reduce bias from social pressure (but discourse database admins will probably be able to see who voted for what (?))
The Dev Fund should be allowed to expire in November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
The current Dev Fund allocation should be extended beyond November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Corporation-owned addresses should be removed from the protocol by November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Corporation-owned addresses should be removed from the protocol by the end of 2025
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Corporate Dev Fund recipients should be required to hold and use ZEC directly rather than converting to USD and other alternatives
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
ZCG should receive ZEC directly from the protocol after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
ZF should receive ZEC directly from the protocol after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Bootstrap (ECC) should receive ZEC directly from the protocol after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Qedit should receive ZEC directly from the protocol after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Shielded Labs should receive ZEC directly from the protocol after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Financial Privacy Foundation should receive ZEC directly from the protocol after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Zechub should receive ZEC directly from the protocol after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Total Dev Fund allocation of the block reward should increase from 20% in November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
Total Dev Fund allocation of the block reward should decrease from 20% (or be eliminated) in November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
The entire Dev Fund should transition to a “grants-only” model.
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
The Dev Fund should be managed by a DAO-like structure with “k of n” voting.
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
The community should have a greater role in funding decisions through a decentralized voting mechanism.
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
The Dev Fund should prioritize direct funding for individual developers and specific projects over providing ongoing support to organizations.
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
9 Likes
I didn’t like how my original questions didn’t include keeping at 20% or increasing. So, here’s one more. >= 20% after November 2024?
Total Dev Fund allocation of the block reward should be greater than or equal to the current 20% after November 2024
- Strongly Agree
- Agree
- Disagree
- Strongly Disagree
0
voters
2 Likes
This is not correct.
The ZIP states “The extension period should be used to design, gain community consensus on, and implement a non-direct funding model.” It does not specify what that model will look like. It gives us time to explore options. If no option has clear community support, the dev fund will expire.
3 Likes
where is this requirement defined
Why not have a separate question just for keeping the dev fund at 20%?
2 Likes
looks same way to me… its like the spam attack. all the core orgs tried their hardest to ignore it for months before actually saying it out loud that there was a huge problem happening.
they did it the same with this devtax debate… waited until a few community proposals got out and then Josh showed up to put out a strong arm proposal to basically guarantee another year or two of devtax. the DAO concept is good but hows it possible in a year???
like youre saying GGuy this is another planning and communication mess. par for the course here. im voting to end the devtax in November and hopefully the ZCG could grant funds to a project to start officially building something resembling to Joshs DAO idea.
1 Like
Could be. These were just a quick draft. Survey methodology is a science in itself which I’ve studied more than most. But, I already see several things that could be improved.
I think figuring out the basics of community sentiment - greater than or equal to 20% versus less than 20%, for example - is a decent starting point. I think the community should be ready for several rounds of polling in different formats and venues if we really want to narrow down to something near “consensus.” It’s a difficult problem because there will be clearly be a large segment who will not be happy with whatever decision is made. Consensus appears impossible. But, I think these survey questions are generally better than the ZCAP question on a “new” devfund to “replace” the existing devfund that has been used to support the position that the community wants a devfund (including continuing the devfund allocation we already have).
Complete removal of all bias is basically impossible. I can see my own bias in the questions I presented. 
1 Like
My main concern about the Dev Fund expiring is not the effect it will have on large organizations, which have runway to stay afloat while a new model is being worked on. I’m worried about the smaller projects that bring value to the community, like ZecHub. Keeping them alive would be my main reason to vote for an extension.
But I admit, letting the dev fund expire in November is a tempting option that could flush out many inefficiencies from the ecosystem. It’s the “F it” button.
At the same time, I don’t like the idea of giving 100% of mining rewards to the miners. It could increase sell pressure. Dev Fun recipients and Zcashers that get paid in ZEC are likely to hold some of it. ECC, for example, is holding on to their ZEC.
Given all of the above, the 1-year extension for the creation of a non-direct funding model seems like the best option to me.
4 Likes
Agreed. It’s a good start though.
Three groups will have financial resilience after a one-year extension?