Maybe it’s just me, but it seems like there aren’t as many likes flowing around as before. If this is true, then this is a problem. Hoarding Cred will lead to low value Cred for all parties involved! The more we give Cred, the more people are likely to engage in order to earn Cred. The more people engage with the community and earn Cred, the more Cred they have to give away. This creates a virtuous feedback cycle.
Currently, as far as I know, nodes that don’t flow Cred out kind of just accumulate Cred. It’s like a damn that builds up a big reservoir of Cred. This reduces the flow of Cred downstream, and as a result less will grow (building on the Cred/water metaphor).
Have we considered and explored mechanisms to incentivize nodes to share Cred? If so, please link! If no, let’s discuss!
I like that you’re drawing attention to this. A bit of “share the love and everyone wins” ethos is by design and good to be aware of
I think you’re right that accumulation of Cred can happen in nodes that have few or no outbound edges. In practice having no outbound edges is uncommon though. As likes are not the only way to create these edges. Mentions, replies, references, quotes, these all create edges too. If in normal activity these “damns” still pop up and start accumulating Cred, I think we should distinguish between two classes of problems.
A technical problem -
The algorithm could bias towards this pattern and inflates scores beyond what the community feels like it should be worth. There’s a couple of ways we could tweak the algorithm to disperse these pockets of Cred. Like changing weights, considering new edge types, manually curating, etc.
A coordination problem -
If people are feeling incentivized to “hoard Cred” and deliberately withhold from likes and attributing dependencies and such, that’s a more complex issue. Perhaps the incentives are indeed wrong and we should boost sharing dynamics. Perhaps it’s because of a misconception, where people believe it’s a zero-sum game and they will lose Cred by “giving it away” to others. What does it mean for collaboration within the community? Does it translate to people trying to do things on their own vs cooperating?
I think this is where the most interesting challenges for SourceCred lie.
However
I didn’t get this feeling necessarily, but it would be very interesting to see some data.
Another one for my wishlist of UI improvements
My feeling is that some of the velocity shifted away from the forums into different areas.
The spike here I think comes primarily from discourse activity.
Which is also heavily incentivized at the moment.
With an 8x weight for topics and 2x for posts.
Compared to 1x for a PR and 1/16x for Github comments.
Resetting these to 1x each, activity seems to be reasonably constant.
On top of that I think a lot of value of recent activity is in the blind spots of our current measurements.
I’m wondering if we actually have a hoarding problem at all. Or just blind spots.
So having a few metrics to know what’s going on, and more coverage of the known blind spots, I think would help here
The ‘total amount’ of cred is actually independent of the edges in the graph. Right now every Discourse post is worth (say) 2 cred, and thus 2 cred is minted regardless of what that post is connected to. (In the future, I want most cred minting to happen based on community-evaluated value, e.g. initiatives and boosting, and not just based on raw activity.)
Every node has an implicit connection that flows cred back to the “seed vector”, where the seed vector corresponds to which nodes minted cred. If there’s a node that doesn’t have any edges out, then all of its cred would just reset to the seed vector
When a node does have edges out, the alpha parameter controls how much cred flows back to the seed vector, vs. how much flows to the edges out. It is possible to get a “cred black hole” when you have the following structure:
A gives cred to X
X gives cred to Y
Y gives cred to X
Then A’s cred will tend to seep away to X and then “get stuck” bouncing between X and Y. If alpha is high, then this won’t be a big issue as it will pretty quickly all flow away to the seed vector. If alpha is low, however, then X and Y can crazily high cred scores.
Also, this construction can be made even simpler if X simply has a loop edge from X to X. Currently there’s no way for users to generate loop edges to themselves, but the two-step cycle happens all the time (I AUTHOR a post, and the post IS_AUTHORED_BY me).
Early in the CredSperiment, I increased alpha 4x precisely to mitigate this issue, you can read about it here.
I would really like us to build some tools (observable notebooks maybe?) that make it super easy to create little cred graphs and experiment with the cred flows. Then we can all get a good intuition for how cred really works, and make changes as necessary. See this initiative: Cred Analysis Notebooks.
Yeah, maybe we should switch the weights to put a little more love on GitHub and less on Discourse.
@Beanow would you be willing to come up with a proposal around weight changes, and then we can do some cred-weighted voting? Nice opportunity to keep testing our governance approach.
This was mainly what I was pointing to. I think there’s just a general bias towards zero-sum thinking and loss aversion. Onboarding new users will need to require educating them as to what SourceCred is, but also how to play the SourceCred game.
Also agree that this is one of the most interesting challenges and opportunities for SourceCred
Agreed! Data is empowering. Also, as discussed in reputation vs anonymity, for the game to work the system has to be transparent. Then players need to be able to engage to change the game to better reflect their values. Being able to easily visualize SourceCred would really help with this
Might be true! I mostly (only) hangout here so I wouldn’t know lol
TBH I’m not qualified to weigh in on this. Still don’t understand all the mechanics and how everything fits together. Seems like a PR, esp for many of the Initiatives in progress, would be as useful as a post so that makes sense. Can’t weigh in beyond that, however, as I don’t know what the exact numbers should be.
This is most unfortunate and I’m glad we’re working to fix this
I don’t know if we have a hoarding problem or not. Felt like there was a possibility, however, so created this thread. Then started thinking that we should incentivize sharing Cred to make the community feel more welcoming, engaging, and rewarding.
Thanks for clarifying that
I too would really like that!
Do we currently have a governance system beyond TBD?
Nothing formal, but I intend to start having (non-binding) cred-weighted votes on any changes I make to the system or parameters. So we’ll start getting experience with and confidence in cred-weighted voting.
I’ll probably ask for people to vote in a Discourse thread, and then I’ll make an Observable notebook tallying the resultant outcome. Not unlike how we do Grain distribution right now. Hopefully before long we’ll automate it better though, I’m getting tired of all the manual notebook publications I need to make.
Anyway, I think using Discourse as the voting tool works for experimenting, but for the long run should be done through our own tool. As using Discourse would exclude the Github users and vice versa. And having both at the same time would allow double voting. So the most sensible to me is having 1:1 user mapping to what our SourceCred instance produces after the identity plugin merged Github and Discourse users.
Makes sense! We could use an Aragon DAO if we wanted, but someone would have to make sure that it’s token balances were updated to reflect the latest Cred scores. This could be a different token in the same DAO (DAOs can have multiple tokens), or it could be a completely separate DAO just for voting and signalling, but not financial transactions.
There’s also probably lots of other tools that could help too.
Discourse polls would be OK if we could get the identity of who voted for which outcome–that way we could cross reference it with cred scores and grain totals and produce a proper cred-weighted vote. The double-voting issue @Beanow mentioned wouldn’t really be a problem, everyone who wanted to vote would need a Discourse account that is identity-deduplicated with their GitHub account, but that’s OK.
However, AFAIK there’s no way to get the user->vote mapping from Discourse polls, so they’re a non-starter.
Added our conversations here to the Cred Weighted Prioritization initiative. Described what we talked about, how it contributed to Cred weighted prioritization, and inlcuded links. Please update the initiative, however, if you feel like it could have been described better or would fit better somewhere else
