Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Natural delegation on DAO voting #34

Closed
ManfredKarrer opened this issue Jul 30, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@ManfredKarrer
Copy link
Member

commented Jul 30, 2018

Voting on compensation requests (or more general proposals) requires time and expertise to evaluate the proposal. If the voter does not have sufficient time for due diligence it leads to a better total vote result to not vote rather that to follow how others have voted or to vote based on "feeling".

Best would be if we could delegate vote to others where we know they are more expert or familiar with the request but that is not planned for the first version of the BSQ/DAO due to added complexity and effort (it might be added at some later stage). But we could gain a similar effect if those who are not experts on the subject and/or do not spend sufficient time to evaluate the proposal cast their vote as zero and therefore give those who do vote more relative voting power.

Of course it is important to emphasize that any BSQ stakeholder can vote on whatever they like—but they should keep in mind that the goal of voting is to make the best management decision for the project (and their BSQ stake represents the share of the overall value of the project). So anyone is welcome to become expert and spend enough time to be able to meaningful valuate others proposal, though if that is not the case then it is better for the project to not vote and leave it to others who can fulfill that.

I think many proposals have usually only one or two other contributors who work with them more closely or who are closely familiar with the field the contributed worked on.

Another note:
Please vote explicitly 0 and do not just ignore a vote so everyone can see whether the stakeholder intended to "delegate" their vote or if they just did not care to vote at all.

Please give a thumbs up or thumbs down if you support this proposal as a general guideline or not.

@ripcurlx ripcurlx referenced this issue Jul 30, 2018

Closed

Conduct Aug 1st- 3rd compensation request voting #94

9 of 9 tasks complete
@cbeams

This comment has been minimized.

Copy link
Member

commented Jul 30, 2018

Implied in @ManfredKarrer's text above, but worth calling out explicitly is that voting zero by default allows the voting process to scale up with integrity. For the last nine months we've had basically every contributor voting on every contribution request, and everyone virtually always votes 1 on every request. This suggests that everyone is reviewing everything, and while that might work with our current numbers of 8–10 compensation requests per month, it will break down miserably if those numbers get much larger. The current process is simply not scalable. Some means of delegated voting is a must, and I like the simplicity, elegance and immediate implementability of this approach.

In reality, I doubt that every stakeholder actually reviewed every contribution request in detail every time, and that some degree of "well, everyone else voted 1, so I will too" has been going on. With the approach outlined above, voting becomes much less burdensome on the individual voter. They should at least have a look at each compensation request, but for those they have no familiarity with or expertise or interest in, they can quickly and honestly vote 0 and move on to the next request.

In this way, when a contributor reviews the results of voting for their compensation request and sees, for example, that all or the vast majority of stakeholders voted 0, it may give them pause, and cause themselves to ask, "Is what I'm working on important?", "Am I representing my work clearly?" and so on. And this may cause them to ask questions and get feedback about what they can do differently in the future to get more voting engagement. The status quo of voting 1 by default obscures how stakeholders may really feel about a given compensation request, whereas voting 0 by default allows the reality of stakeholder sentiment to surface naturally.

@sqrrm

This comment has been minimized.

Copy link
Member

commented Aug 3, 2018

Having just voted for this month, using 0 when I wasn't familiar with the work, I've got a few thoughts.

The delegation of votes must happen somehow or the DAO won't work. I wonder how to judge requests where I only partially know the details. For example, I might know in detail about half of a request but not know anything about the other half. To vote 1 on a request where I only know about half the details I would have to research the other half at time of voting. The nature of how we work is might be that this is the typical case and that's manageable, I can investigate the half I don't know much about. If on the other hand work is spread even more, say I only know about 10% of the request as do others. I would be unlikely to vote 1 and perhaps the remaining collaborators as well since we all know only 10% each. This might be a non-issue, just a thought.

Another thought that struck me is that if the break between proposals and voting phase is short someone can add a request late in proposals phase giving little time to comment before voting starts. Once voting starts it's less likely someone who has already voted would go back to look at a request to see if there are new comments. If 0 is the default someone can ask for compensation for no work and with no comments on the request it would get all 0 except a 1 from the person with the request and the request would be accepted. How do we avoid such cases, it seems like there is quite a big incentive to try to ask for compensation if the likelihood of acceptance is high.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented Aug 3, 2018

@sqrrm There is the quorum to make issuance by self vote only of new contributors hard. We can make the break a day or so, also the voting will take about 3 days. i also assume that there will always be at least one "senior" stake holder who will check the request out. There are diff. areas and all areas should be covered by one who feels more responsible and therefore will look into any request which falls in his/her area.

@ManfredKarrer

This comment has been minimized.

Copy link
Member Author

commented Oct 5, 2018

I close that as it had wide consensus and seems most people are following it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.