DHF Proposals Could Use Polls

Ever since I read about the initial version of Open Polls protocol, I had an idea but I didn't find the right day to post about it. I decided today is the day.

DHF Proposal System: Simple, but Inflexible

The DHF proposal system has a few simple, but strict rules that govern it:

• someone creates a proposal, which involves a post that describes it and a set of parameters: starting date, ending date, payment per day in HBD; there is also a fee to create a proposal to avoid spam and discourage long-term proposals (10 HBD + 1 HBD for every day of the funding period above 60 days)
• stakeholders vote or not on the proposal
• if the proposal has more stake voting on it than the return proposal, it gets funded, if not, it doesn't
• the proposal can move between being funded and unfunded during the funding period, based on its votes compared to the return proposal
• when the funding period expires, if the proposal needs an extension, a new proposal needs to be created and the process starts over
• the proposal parameters cannot be changed after being created

Time to Improve the DHF?

Any idea to improve the DHF proposal system probably adds complexity compared to this simple process, and someone would need to make the changes, and they need to be applied in a hard fork (I believe), so things are not trivial.

However, sometimes the simplest way is not the best way (other than from the code perspective), because a simple process sometimes fails to be useful in more complex situations.

I don't have the key to improving the process, for that more minds are needed to think about this from different perspectives, but I do have some ideas that may or may not be considered worth implementing.

Adding Polls to DHF Proposals

My first idea, which I will present here, builds upon the existing system and integrates polls into proposals.

Here's the reason why I consider integrating polls into the DHF proposal system to be useful.

It often happens that disagreements on proposals are not fundamental (they are considered useful), but parameters are the ones that create disputes. Basically, it's about how much HBD the DHF would pay for it.

Integrating polls into the DHF proposals allows the proposer to create a few options from which voters can pick one, where mainly the parameters differ (payment per day and/or duration of funding).

Why would the proposer want that? Everyone would vote for the cheapest option, right? Wrong! Each payment/duration option comes with a different proposal (all presented in the same linked post), often on a gradual scale. Do you know how the subscription models come in tiers, with higher tiers offering extra options to justify a higher cost? Or how software has different versions from basic to professional with added features the more expensive the product version? Well, something like that I had in mind. If you want more HBD, you deliver more! If you want to pay less, you get what you paid for (and not more).

So, the options (if there are multiple options) would be presented as a poll, on which stakeholders vote as they see fit. Just like now, but instead of voting on a proposal as a whole, they vote on one option that establishes what they want to receive for how much HBD.

The winning option in the poll is the one that gives the parameters for the proposal.

Special Cases

In the event of a tie (highly unlikely when we compare total VESTS voting on each option), different solutions can be chosen. I think choosing the cheapest option from the ones tied at the top can be one solution, in this case.

What will be the total VESTS taken into consideration when comparing different proposals and their position relative to the return proposal? I think the best way would be to consider all votes on all options, rather than only the ones given for the winning option in the poll. Each of them gave support to the proposal in one form or another.

Final Words

That's it regarding integrating polls! What will be achieved by integrating them:

• bring more clarity (hopefully) on what is paid for and what isn't
• prevent situations when good proposals don't pass because they ask for too much (in the perception of voters); right now, the only thing they could do if they wanted to offer a cheaper alternative with less being offered is to create another proposal and pay another fee (having two similar proposals running at the same time probably wouldn't help)
• reduce situations where proposals remain without funding (temporarily) due to payment disagreements

I have another idea that builds upon this one, where payments would be received on completed milestones/project instead of hourly (as an alternative, not instead of the current implementation). But about that another time.

---

Want to check out my collection of posts?

It's a good way to pick what interests you.

Posted Using InLeo Alpha