RE: DHF Proposals Could Use Polls
You are viewing a single comment's thread:
Thank you for sharing this idea!
Yes, something like this would definitely be possible. It should work right out of the box, more or less. Since the poll is a regular post, and the proposal is linked to a regular post, you can just make your regular post a poll. And people will see the poll when they open your post. This is how it is planned.
The proposal creator could make the poll be about any aspect of the proposal, be it requested funding, deliverables, how it will be done, etc.
It might also make sense to use the polls to create a pre-proposal. The pre-proposal could allow stakeholders to vote on various parameters of the proposal, until things are fleshed out to the satisfaction of the stakeholders, upon which a proposal with those parameters can be created. Splinterlands has used a pre-proposal system like this, but in a more manual form.
Thanks for dropping by! Polls have so many use cases. I hope the Open Polls protocol will be accepted and implemented throughout the Hive ecosystem, as it will enhance our options considerably.
Ok, but how would the poll affect the parameters of the proposal, if the DHF code isn't updated to set the proposal parameters to the ones associated with the winning option of the poll?
Yes, a pre-proposal post with a poll would be a solution that wouldn't require any additional coding work. I do have an incremental build on my idea which would require updating the code of DHF, however. I know there isn't much desire to change this code at this time, but maybe at some point, it will become a priority.
Splinterlands has a manual pre-preproposal system (without polls) but continues to tweak its proposal system. For example, initially, voting 'no' on pre-proposals could stop them from becoming proposals. Now, if a pre-proposal gets enough votes, regardless if they are 'yes' or 'no', turns it into a full proposal (still, someone has to add it, it's not automated or decentralized). Splinterlands hasn't found a magic formula with the SPS DAO, but they are willing to make small, incremental changes to improve things. It doesn't help that they don't have enough dev power right now. This is a problem we generally have on Hive, unfortunately.
I think and hope so, too. It will be important to design everything with maximum flexibility as well as simplicity and ease of use, so that everyone can easily implement the system. And it is great to see people coming up with use cases and ideas for how it can be useful. Even though a poll doesn't necessarily enforce anything on its own, people can choose to agree on and follow its outcome, and if this is the case then polls can serve as a general governance system that can be used for all sorts of decision-making scenarios, with very high flexibility to tweak the poll settings for the particular situation. I guess we'll see what happens and how we'll use it.
There are some things that can be changed after a proposal is published. The funding requested can be reduced (but not increased). The deliverables agreed on can also be changed by agreement, which would mean simply changing the post to specify the deliverables. I guess another thing that can be changed is that the proposal can be deleted at any point - I don't know if the end date can be changed but the proposal creator can promise to delete it at a certain date and a notification system can be tied to the poll to notify all poll participants to stop voting for the proposal at that date. This last example sounds perhaps a bit too convoluted for regular usage, but my point is more so that changes to the core blockchain software take time and typically give us limited flexibility, whereas if we think of ways to do something without needing to change the blockchain software itself, then we have very high flexibility and ease of change. If we can make it work reliably and easily, of course.
Yep, definitely. Now, imagine a situation where instead of people developing solutions for their particular app, they developed general solutions. Specify an open protocol for how it will work, make backend nodes that anyone can run, and then make it easy for frontends to implement the feature. There is so much repetition of work happening right now, and instead we can think of how to create generalized and highly flexible features or building blocks that anyone can use. I don't think we have a lack of dev power but a lack of this kind of coordination, which incidentally polls can also help with, hopefully.
Developing open-source, general solutions with wider contributions from different corners of an ecosystem should be one of the strongest points of a decentralized system in Web 3. That's why I don't like when we keep returning to the practices from Web 2 of silo development. Maybe because when you control most aspects of development, it seems like you can make it go faster, which may be true in some cases. Cooperation is not always easy, but it is desirable in Web 3.