Implement Cred Weighted Prioritization
Status: proposal
Champion:
Initiative Description:
As discussed here, we’d like to use cred-weighted voting to prioritize SourceCred initiatives. We can then give the prioritized initiatives a nice cred bounty.
As a practical matter, I propose that we use cred-weighted, dependency-aware conviction voting.
Cred-Weighted
Voting power will be based not on number of votes, but based on the amount of cred behind each vote. We can experiment with different flavors of cred weighting. For example:
- Raw cred weighting: We weight every vote based on the cred of the voter. This will give enormous power to two individuals who have ~70% of the cred, and disenfranchise most people who have very little cred. We could add some constant to each voter so that everyone still has some voice.
- Square root cred weighting: We weight every vote based on the square root of the user’s cred, plus some constant. This will likely shift voting to be more democratic, but still give top contributors a significant voice.
- Logarithmic voting: We weight each vote based on the logarithm of the user’s cred. This would greatly reduce the relative power of the highest-cred contributors.
We could also do other things like having the cred weighting take into account “cred freshness”, so recently earned cred has more voting power than stale cred.
Also, users will be able to split their voting power between multiple initiatives.
Dependency Aware
When voting for an initiative that has unresolved dependencies, a large chunk of the voting power should flow through to the unresolved deps. This way our process produces viable prioritizations.
One approach could be to simply re-use our PageRank logic here, modeling dependency edges between the initiatives. The seed vector would be the raw cred-weighted voting output, alpha would be reasonably high (say 0.2). The result is that dependencies of important initiatives(s) would get prioritized first.
Conviction Voting
The idea behind conviction voting is basically that votes grow more powerful the longer the underlying preference has been expressed for. So if I have been saying “we should do X” for 8 weeks, that’s a much stronger than if I’ve been saying it for 2 days.
You can read about the Commons Stack proposal here: Conviction Voting. One twist is that while I want the votes to get more powerful over time (positive first derivative), I want the rate at which the vote gains power to get lower over time (negative second derivative), until the vote is “refreshed”.
Basically: if someone votes for something in 2019, and then disappears, it shouldn’t be the case in 2021 that their vote is now the most powerful in the system. After a certain period (maybe a few months) the vote loses its power until the author comes around and re-votes for it. Someone who is paying attention could re-vote every week and keep the power strong, but I want there to be some degree of conscious attention needed.
Voting Frontend
We will need a system for recording votes. Since the initiatives are presently reified as Discourse topics, we should do the voting through Discourse too. However, the builtin Discourse poll option is insufficiently flexible for our needs. Instead, we can make a new category (CredSperiment/prioritization) and have individual posts correspond to votes for initiatives. (A post could include votes for multiple initiatives, weighting of the different initiatives, and even explanation of why the voter made the choices they did.)
Benefits:
Implementing cred-weighted prioritization will give the SourceCred community the ability to guide its own development and priorities using its internal ruleset. This will make SourceCred much more “autonomous” (in the sense that DAOs are autonomous).
Implementation plan:
For ease of iteration, let’s do the cred-weighted prioritization inside observable notebooks. We’ll need to do the following:
- Decide on initial formula for cred-weighted voting
- Export initiatives from Discourse (need new APIs)
- Export votes from Discourse (need new APIs)
- Export PageRank code from sourcecred/sourcecred so we can use it for dependency weighting
- Implement formula for conviction voting
- Wrap it all together in a notebook
- Document + demo how to vote on initiatives
Estimated Work (hours):
This is a substantial initiative. I expect that (in addition to dependencies) it will take at least 10-30 hours of work.
Dependencies:
- Cred Analysis Notebooks
- Discourse Reference & Mention Detection
- (possibly) explicit initiative to figure out how we should weight the cred
- Write the Initiatives Plugin
- (possibly) explicit initiative on coming up with a good way to expose discourse data to other plugins
References:
None yet
Contributions:
@decentralion expressed renewed interest to start using Cred weighted voting in the forum. @burrrata then researched Discourse Polls and created the first poll on SourceCred’s Discourse. Then the community discussed and @burrrata discovered how to create a public poll. @Beanow confirmed that public polls can be retrieved via the Discourse API.