There’s some improvement there, but TL;DR I’m still rather concerned with this. Because of:
- Parameter choice
- Gatekeeping, centralization and bottlenecking, without enough justification
- Switching from one invisible group to the next
First about the plugin budget cap. I’d like to echo @META_DREAMER’s question there.
When the budget for a given week is reached, what happens to additional cred? Does the 5000 just get spread thinner or does the plugin stop minting cred after 5000 cred has been minted?
Assuming it gets spread thin, I think this is only effective at curbing this escalating recency bias when it’s saturated most of the time. So using the 5k Cred from the CredCon anomaly seems like a very high threshold. It’s also an approach that’s sensitive to the overall weights, as that influences the “typical” absolute Cred inflation rate. For example, with the baseline chart ~1k Cred would saturate Discord most of the time this year. With the proposed-1 chart that would be ~2-3k Cred. So every weight change we’d have to fix this parameter as well.
Also, I think the goal here should be to preserve “the signal” when looking at these limiter functions. A ‘good contribution’ during a busy time shouldn’t be worth less cred than that same contribution would have had during a quiet time. A hard cap doesn’t do a great job in scenarios like these.
If we could do a two pass system, it would be interesting to see what the median reaction weight per post is per time window and mint Cred relative to this. That would offer a way to make like-minted Cred fairly constant and easier to set parameters for. And would award Cred that makes sense for the community size at that time. (e.g. a 10 out of 20 people react would be a stronger signal than 10 out of 200).
I’m not sure my suggestion was clear. What I’m proposing is:
| Weight | Current | Proposed | Counter proposal |
|---|---|---|---|
| role weights | |||
| no role | 1x | 0x | 0x |
| lower barrier role (optional) | 1x | 0x | 0x / 1x |
| @ community | 1x | 1x | 1x |
| @ contributors | 1x | 2x | 1x |
| @ core | 1x | 3x | 1x |
Although even for this, I think a strong argument is (perpetually) necessary to justify increased gatekeeping.
The existing hierarchy (community/contributor/core) doesn’t need to be removed. They can be used for access-control and social hierarchy as they are. The new role would be an easier to obtain one, between no role and @ community. But only if necessary to lower the gatekeeping threshold.
Sure enough, having an important role should mean increased trust (given they have increased authority and executive power). But I still expect them to be humans with human-like discernment and biases, with limited time on their hands. Transparency and accountability (while important) can’t resolve this.
In my mind, part of SourceCred’s overall premise is to use algorithms to support a set of values (using whatever governance), while simultaneously insulating from personal bias enough it consistently recognizes contributions that fit those values, in a way that can scale to outperform traditional models.
Given that we’re also relegating ‘automatic Cred’ to obscurity with these weight changes, we’re looking to be leaning heavily on the social recognition now. So I’m alarmed by a centralization of the Cred-minting power.
About that “limited time on their hands” this is not just gatekeeping / centralization, but also a review bottleneck. You’re losing out on substantial Cred when core doesn’t have the bandwidth to evaluate or simply missed your contributions. So ‘everyone’ is going to want core to review ‘everything’. Which I’m not expecting to scale properly, so it would amplify their biases because they are forced to decide what they’ll spend time on reviewing.
Sure Eternal September is a real concern, plenty examples exist in open source projects alone. However at the same time SourceCred’s culture isn’t finalized, it’s still in need of being challenged, refined, etc. Echo chambers and amplifying biases with financial consequences are equally a thing to fear for the culture’s health imo.
Overall it just seems like a regression to me. It’s a heavy measure that needs substantially more justification than a “while we’re at it” / “go big or go home”. If we absolutely need this centralization crutch, I’d like to see a much stronger clarification.
If this was a vote, this issue is why I’d vote against.
I’d also just like to point out we’re intentionally switching, from one undervalued group to a new one. The proposal is an uncomfortable choice between which bias is the lesser evil.
I’m not so worried about devs now having an “equally bad” experience of having to self-promote. I’m worried for those who struggle to do this. Social anxieties, conflicting moral values about shilling, or the higher noise and stress levels of Discord (full disclosure: this describes me atm). I think the #props channel alone will not be enough to support them. This could apply to the creditor as well.
Their situation before wasn’t great either. Only if they were comfortable working on GitHub (Discourse weights are currently not that high) would they have an alternative source of Cred. But by making socially-earned Cred the only viable option, I’d predict the new structural bias will be between the socially adept vs the quiet.
So for the future I really hope that we’ll find a well balanced mix of systems (or silver bullet!) for a wide audience, rather than hop from one invisible group to another.
Yes, and :]
Unsexy ones were already at a disadvantage because the sexy ones are easier to double-dip with. Having GitHub Cred at a reduced weight has been a useful baseline so they’re not left empty handed, but the unsexy problem probably needs special attention.
It’s an industry-wide deeply rooted issue (whether proprietary or open, paid or volunteering). It’s much easier to just churn features all day, even if they’re unfinished and buggy (assuming it gets approved), because there’s only so many people that read the code to call out poor hygiene, but a lot of people that can be hyped about a new feature.
Sadly even with a half-arsed job, features win the popularity contest hands down, because the audience is orders of magnitude larger.
It could even be a type of attack, where you try to get away with as many experimental features as the community will let you, and leave someone else to clean it up (with the opportunity cost of not doing sexy things during that time).
But a baseline Cred doesn’t solve it completely, and the unfairness of not having such a baseline outside of GitHub is clear.