SourceCred Discord Plugin

[decentralion]

@wchargin

Hmm… my intuition/strawman here—what do you think about it?—is that helpful and informative Discord posts usually create value by influencing the trajectory of other things that are more documented. If my comment about floating point numbers was useful to someone because they’re porting some JavaScript code to Python, the relevant PR description could include a “thanks” edge. If a comment shapes the development of an initiative, the “References” section of that initiative could include a “thanks” edge. We encourage these kinds of attribution, anyway.

It doesn’t require self -promotion—anyone can add the “thanks” edge, and I was actually imagining that most thanks would be added by the thanker rather than the thankee.

I’m ok with the idea that Discord comments receive cred only when they get an explicit “thanks” interaction, assuming one of the following:

1. We make this extremely low friction, e.g. by making the “add thanks” interaction correspond to adding a reaction in Discord
2. We apply this “need an out-of-band thanks edge to receive cred” consistently across the project, i.e. GitHub issue comments or reviews don’t receive cred except through the same process.

Remember that not everyone in this project has the same amount of privilege. Right now, GitHub contributors have a lot of privilege–they have high weights in the CredSperiment, and their contributions automatically mint cred. In contrast, contributors on Discord experience very little privilege, as their contributions quickly evaporate, and we don’t yet award any cred.

The proposal that Discord contributors will receive cred only by doing extra work, while other contributors recieve it automatically, means we are putting extra burdens on the people with least privilege – and that would not be aligned with our values.

@wchargin

A critical part of “the paradigm” is recognizing where and how the paradigm should be applied. We need to lean into that, too.

Sure. In this case, we lean into that by (experimentally) extending into the uncomfortable areas of the paradigm. If we get burned, then we can dissuade others with confidence.

@wchargin

Discord is not an open platform (more closed than GitHub, as the entire content space is login-walled)

I don’t see any reason that plugins should only be written for fully open platforms. As a community, we could have chosen to use a different (more open) platform, e.g. Keybase or Matrix, but Discord had the features that we need and so we’re using it. If it’s good enough for us to depend on as critical community infrastructure, it’s good enough for us to write a plugin for.

@wchargin

implementing this would require a significant amount of work.

It’s a significant amount of work, but also a different kind of work. A lot of the work in the project requires “trailblazing”, which tends to bottleneck on context transfers from 1-3 people who really know the system. IMO, it’s those context transfers that are the real development bottleneck. Since we have several good examples on how to write a plugin, it’s not trailblazing, and can be done in parallel with other work streams.