What's new

Can we decrease MNO voting apathy?

Eric_Stanek

Active Pivian
Preface:

The comments below apply to both the PIVX Core wallet, and MyPIVXwallet.org. However, I am not up to speed on the Road Map plans for MPW. Plus, their tech stack and UI/UX/Audience is different. So, I will comment only with respect to the PIVX Core wallet, and leave it to the Community and the PIVX Labs team to interpret the intent as it would apply to changes to MPW.

Further, while providing context to the issue and possible solutions, this document is meant to promote feedback/discussion/brainstorming. The ideas presented here may not be feasible or even proper. But, I am confident there is indeed opportunity to strengthen PIVX Governance here. It should therefore be explored.

Problem:

Like most voting systems, the PIVX Governance system suffers from voter apathy.

Description:

Compared to most voting events in real world political campaigns, PIVX actually has a high percentage of voter participation. But, those numbers are artificially high due to the fact that votes are still in the process of being distributed, and there are a number of whales with higher numbers of votes. So, in terms of the percentage or people voting, I suspect the voter participation is much lower that ideal. Regardless, it is always better for PIVX to have more MNOs voting.

Complications:

1. Solutions have been suggested to apply a penalty to MNOs for not voting. This is problematic, because Abstaining is indeed a valid choice. Aside from that, it would be difficult to code, as the voting status can change all the time, and MNOs who don't want to vote, could simply write a script to mimic voting.
2. Other solutions involve notification systems outside the PIVX Core wallet, but that breaks privacy.
3. There is currently no way to know if a User chose to Abstain, or has simply not bothered to vote Yes/No.

Solution:

When the User opens their Core wallet, the code can check to see if there are Proposals that the User has not applied all their votes to yet. It can also calculate the approx days remaining until Super Block as well as other statistics. (More on this below.)

Immediately after the wallet opens, IF there are votes NOT yet applied, a dialog can present the statistics, and remind the MNO of their duty to vote. They can dismiss the dialog, but there should NOT be an option to not show it again.

Considerations:

1. The success of this solution assumes that MNOs open their wallets often. I worry that many leave their wallet closed for many months. This suggested solution won't help much then.
2. This could be quite annoying for someone who has chosen to Abstain from voting for 1 or more proposals. Ideally, we should add functionality to explicitly vote to Abstain.
3. Data presented should be data already available in the wallet, and remain in the wallet only, because it then does not break privacy.

Dialog Content:

This is open for discussion, and could be quite detailed. However, the goal should not be to duplicate data shown in the DAO tab, but to show data designed to motivate the MNO to vote.

Keeping it simple, the dialog could show stats (shown in no particular order) like:

1. Days remaining to vote.
2. Percentage of proposals the MNO has voted for.
3. Percentage of proposal cost, the MNO has voted for.
4. Number of passing proposals.
5. Number of failing proposals.
6. Number of 'controversial' proposals.
7. Percentage of budget currently passing.
.. etc...

Misc:

I can picture some programmed 'annoyances' being used to further motivate the MNO to vote, but they would need to be minor to avoid backlash. For example:

1. Prevent the MNO closing the dialog for a duration based on the % of votes that have been applied.
2. Similar to transaction notifications, add a notification that they still have votes to apply. Frequency can also be based on the % of votes that have been applied.

It would probably be better to code in positive motivations. For example, assuming the dialog displays no confidential information, it can also include a 'Participation Badge', (With various levels) or maybe be displayed as an impressive 'Certificate' format. If the MNO then wishes, they could screen shot the dialog, and post it online. This of course would break some privacy, as they would be identifying themselves as a MNO, but that would be their choice. Maybe even prompt them to add their Discord/Twitter name, to the certificate and the dialog can show the Super Block number too. This might prompt people to collect them.

This new PIVX Core functionality would be ideal for a new Core Developer to prove themselves with, as it does not involve protocol changes (unless the Abstain functionality is included) and is 'Display Only'.

Is anyone aware of similar functionality implemented in a different project?

Summary:

Without breaking privacy, we have an opportunity to reduce MNO voting apathy. Implementation is largely just UI/UX, but could be improved further later on, with a protocol change to include the 'Abstain' status for a vote. There is no downside risk, other than investing the developer time with no real reduction of voter apathy.


Thanks for reading this far! Now .... please provide feedback!
 
People are probably lazy or unaware.

I think more aligned with 6.0 features for voting, because we can assign someone to also vote on our behalf, which will be a good learning curve to prepare the culture of that.

I do not entirely think our situation is actual apathy but rather laziness or not so much 'ease' for the end user to vote.
For example: A user has funds on their ledger, that's in a MN and has to use SPMT, its not a hassle but they have to connect device, unlock device, load SPMT, connect RPC/ledger, and then they can finally try to vote!
A user has funds on Pecunia a master node hosting service, where does one vote at?

With the new master node update for v6.0 we have the option to assign a third party to vote for us or a different address, which in this case can be say your main staking wallet, mpw etc, they can just vote from that wallet if its the one set when deploying the master node.
 
Top