SourceCred Voice

[s_ben]

@rpp63

While I onboard with your vision, the execution, i fear, is likely to be quite complicated. How would one ascertain is a piece of writing has the SourceCred voice? Who is the arbiter of this standard? Who is responsible for getting a piece of writing tuned up to meet these standards you laid out?

Agreeing with @decentralion that the easiest way to do it is to just have have a small group of maintainers making that call. Only because while I like these more democratic ideas on paper, I think will be more complicated and may not work so well in practice, for reasons I go into below. I do think that there are ways to address the issues raised within the existing framework, and that some of these ideas can be implemented in different forms.

@rpp63

One possible method could be defining a a set of community roles akin to an editorial team at a news paper. An interesting possibility of developing this kind of role would be a more nuanced method for assigning grain/cred for content created (if a member of the editors “guild” likes something, it generated more grain/cred), this would outperform the simple emoji system, particularly with the inevitable increase in the size of the SC community.

I think this is basically how it would work with a small group of maintainers. If the content doesn’t fit the voice–and the author can’t get it to standard with help–then the PR doesn’t get merged, and Cred doesn’t flow. I do agree we can do better than the emoji system, and that having more nuanced weightings is desirable. A “guild” makes sense. I think this is partially just due to the GitHub plugin still being mostly just activity based (in contrast to the Discourse plugin, where likes (i.e. review) determine Cred minting). I believe a long-term goal is to move the GitHub plugin away from being too activity-based. I can also see the Initiatives plugin being used here. We could, for instance, create a SourceCred Voice initiative, where Cred is minted to all contributions that corrected the Voice in another contribution. Another way a “guild” type system could be accomplished is by only allowing certain members (the editors) to mint Cred in certain domains. We’re implementing something similar for Maker where Cred can only be minted if you’re attained L2 trust level on Discourse.

@Bex

GitHub works really well for the editing portion of reviews, however there’s lots of waiting involved. What if we had a line of people who would send it to each other in a certain order? That way, everyone would start a doc, even just the bare bones, and then the contributions, ideas, and revamps would come piecemeal yet quickly.

Not exactly sure what’s being proposed…So let’s say I create a doc. Then it’s automatically sent to @Bex next? Then when Bex is done she sends it to @benoxmo, and so on? I fear that would only lead to more waiting. People come in and out of OSS projects a lot. They may have day jobs, go on vacation, hop from project to project, or just lose interest. In practice, I wish it weren’t this way. But having one person (or a small group) of committed people with the authority (and responsibility) to do this work is the only way I’ve seen this work get done in practice. That’s why I think Champions make sense (essentially what is being proposed here). Perhaps I’m misunderstanding. I think what you may be getting at is permissionlessness? I think we have this already built in generally. Anyone can submit a PR to rewrite content, or submit a review on a PR, make a comment, etc. All of which flow Cred.

@benoxmo

my splitting Cred would be more 70%(creator)/30%(reviewer). It takes a lot more to produce than review.

This split feels about right to me…unfortunately, while that might be the average ratio, in practice it could vary a lot. For instance, let’s say a new contributor shows up whose PR needs a ton of work. I could spend way more time helping them that I could just rewriting it. Or, someone could submit something that only needs a couple minor changes. In this case the creator did maybe 98% of the work, and deserves more than 70%.

I think just using the paired with: @username as @decentralion suggests is a workable solution for now.

tldr; I think basically we can accomplish the desired aims using some combination of the typical OSS software development model we use on coding repos, plus the existing Chamption model and Initiatives plugin, plus creative hacks/social norms, plus new features down the line (which can be informed by data from our experience here).