Envisioning the Creditor

What is the Creditor for?

SourceCred, at its technological core, is a system for assigning scores to contributions. For SourceCred to be able to do that, it needs data on contributions: what they were, how they relate to each other, and which ones were important.

So far, our approach has been to discover contributions by automatically importing data from platforms like GitHub, Discourse, and Discord. This has some major advantages for SourceCred. This has some big advantages, most notably that it’s easy to turn on for existing communities. However, it has some big flaws, too:

  • It misses all the contributions that don’t occur on platforms
  • It “becomes hard to see the forest for the trees”; interesting projects or achievements usually correspond to dozens or hundreds of individual contributions
  • Because the data is overwhelming, it’s hard for humans to meaningfully review or provide feedback on what was really important

The Creditor is an attempt to fix these issues by building a flexible and powerful tool for humans to collectively improve the Cred graph. Basically, it will allow a community to review the contribution graph, add missing contributions, and organize contributions into higher-level meta-contributions that reflect what the community really cares about.

What capabilities will the Creditor have?

Some of the core functions of the Creditor include:

Adding new contributions that aren’t already recognized.

For example: suppose that someone did a great job presenting at a meetup. By default, this will go unrecognized, because we don’t have a “physical meetup” plugin.

The Creditor will solve this problem by allowing people in the community to add new contributions to the graph.

Specifying the relationships between contributions

Consider a partnership, like our partnership with MakerDAO. If the partnership goes well, we’d like to be able to flow more Cred to everyone who helped out with it. However, the partnership is successful thanks to hundreds or thousands of individual contributions: writing proposals, organizing meetings, adding requested features, et cetera. Right now, we don’t have any structure for keeping track of those relationships between contributions.

The Creditor will solve this by allowing people to specify the relationships between contributions. In general, this will mean adding new edges to the graph. As an example, we might make a “MakerDAO partnership initiative” as a new node in the graph, and then have it flow Cred to every individual contribution that helped the partnership.

Over time, that will become a bit overwhelming, so we can keep re-organizing it into smaller and smaller pieces. For example, we might have “MakerDAO: adding requested features” and “MakerDAO: trial administration” as seperate nodes, and flow Cred to both of those from the overall partnership nodes.

Determining what contributions the community finds valuable

One of the most important decisions in SourceCred is where to mint Cred. Whatever mints Cred is ultimately the “source” of positive rewards from SourceCred. Currently, plugins are responsible for these decisions, and because they only have raw data, we use heuristics to decide where Cred gets minted.

The Creditor can solve this by putting the community directly in control of some Cred minting. For example, imagine that every month, the Creditor is going to mint 500 extra Cred. People can vote throughout the month on what high-level contributions were valuable, and the Cred will get divided based on the voting.

(We will put a lot of thought into thinking about how this system could get gamed.)

Who will have control over the Creditor?

The Creditor will be a powerful and complex tool. It will need moderation: to keep it orderly, to remove spam contributions, etc. However, the people who are in charge of it will have a great deal of power. For example, if I am the moderator of our Creditor instance, I’d have the power to mint extra Cred for my friends, make more contributions flow Cred to my initiatives, etc.

I think we should focus on decentralization and transparency in how we operate the Creditor. Anyone should be allowed to propose changes, like adding a new contribution, re-organizing existing ones, etc.

We can use Cred scores as an input to decision-making throughout. For example, maybe rather than needing a moderator approval to make big changes, we would just require a the change be upvoted by people with a certain amount of total Cred.

If we have an issue with people spamming bad contributions or changes, we could require that participants spend a small amount of Grain to make changes with the Creditor. (But we should be sure to make it a small amount just to discourage spam, not something that gates access to the Creditor based on personal wealth.)

One thing I’d like to do is make governance power in the Creditor “local” to the part of the project being edited. If I’m voting on how Cred should flow within a design initiative, my voting power should be based on how much Cred I have in design, not based on my Cred in SC as a whole.

Some example usage of the Creditor

To make things more concrete, here are a few examples of how the Creditor could be used within SourceCred.

In Software Engineering

In the software engineering side: we make a Creditor node representing every feature that we’re thinking of developing, and a node for every bug that needs fixing. Then, people could vote on which features and bugs they want to flow Cred to. The team would focus on the highest-Cred features and bugs (which they would want to, if only for selfish reasons!). This would democratize and decentralize decision making about feature prioritization. Also, if someone really wants a particular thing to get worked on, they could Boost it.

Once someone works on a feature, we would use the Creditor to have the feature flow Cred to their contributions. This would include both “automatic contributions” like pull requests, but also “manual/Creditor contributions” like visual design work, usability audits, etc.

Also: suppose there’s a highly demanded feature, with a big Cred bounty, and someone “rushes” a half-baked solution. So it implements the feature, but it’s buggy and unreliable. Other people would need to do more work to fix it, and the Cred from the feature would get diluted between the initial work, and all of the future fixes. So there’d be an incentive to build it right the first time.

In Docs

In the docs branch, every individual document would be represented in the Creditor, with links to the contributions of writing and reviewing the document. As we re-organize docs, we could keep track of the relationships between them. For example, if one doc splits into three separate docs, each of those child-docs could flow some Cred back to the original.

Then, we could embed little <3 buttons onto the official SourceCred docs page. Each time the <3 button is pressed, it would direct a little bit more Cred towards that doc from the Creditor, meaning that the readers of the docs would be able to reward the best docs. (We’d need to think about how to ensure this wouldn’t get spammed or gamed, of course.)

In Ecosystem

We could create a node representing each co-community. Every week, when that community flows some of their Grain back to us, we could treat that as a boost of their node, increasing the amount of Cred that they get to flow within SourceCred. The co-community would have a lot of say in how that Cred flowed, giving them the ability to advocate for the features and improvements they need.

Next Steps

The Creditor is an ambitious undertaking. From a design standpoint, we need to build a novel and powerful UI and make it accessible to everyone in the community. From the software engineering perspective, we need to build a lot of infrastructure around the backend, identity verification, etc.

To start, I think we should first come to alignment within the community on the overall vision for the Creditor. This post is a step towards that, I’d love to hear others’ thoughts on how this could be used or how it should function. (In particular, I haven’t thought a lot yet about how the Creditor could improve Cred flows within the cultivation branch, and would love to learn how it ca help!)

Once we are aligned on overall vision, I think we should try to scope out a “minimum viable Creditor”. One that may not have every feature we’ve envisioned here, but would be a step in the right direction. Maybe to start, we would just allow tracking new contributions, and voting on which ones are important, without having support for re-organizing the edges in the graph. In that case, it’d be like a formalization of the #props channel on Discord.

Given the complexity of the overall tool, we’ll be well served by starting very simple and then growing from there.


PS: I want to work to make my writing more engaging and accessible, and welcome feedback on this post. Did you find it easy to read and understand?

10 Likes

First off, so happy you wrote this up. For being such an apparently pivotal part of the project, I don’t think there’s a lot of visibility into what the Creditor is, what it can do for us, and what progress has been made. This topic is easy for me to parse, and opens up a conversation about what I think will become a critical focus for us across the project in the coming months.



Some reflections on Creditor use cases:

This could be really useful for internal docs operations too. Participants could propose docs (by filling out a Docs Proposal Template or something with basic information like title, description, etc.) and those doc ideas would go on a list of potential docs to be picked up by a participant on an Authors Team of some sort and written.

Then we could internally (and maybe also externally?) use likes/boosting/hearts/whatever to boost which docs we’d like to see written and let that aid in governance around which docs get picked up by authors and, once written, move through the review and approval phases. ( @Bex )


One thing that comes to mind is that I’ve had multiple requests to create a small workshop for those who want to improve their ability to host/lead meetings. Right now I don’t have the bandwidth to really put that together, and there’s no mechanism or incentive for a new contributor to step in and do the work of organizing that so that all I’d have to do is show up.

However, if the first person who had brought me this idea had been able to create or request a new node for “Meeting Leadership Workshop” and each consecutive person who’s asked me about it had been able to just go boost that node, I’d have a solid way to direct a newcomer (I literally have someone in mind for this) into their first project! This would facilitate the community having its needs met, the (lucrative) onboarding of a new participant, and best use of my bandwidth. Huge win.


I also imagine that each Branch within Cultivation will eventually be spinning up projects (with teams and a champion/pm) related to their goals. It would be amazing to be able to create nodes for these projects and input data like who the champion is, who the participants are, what contributions were created, what contributions were relied on, etc.

Reviews of these nodes with accessible data about what/who relied on what/who would create a great opportunity to reflect on gratitude and give specific opportunities to props-boosts the participants you’re relying on (perhaps on a weekly basis regarding nodes you’ve connected to recently). I have more ideas on the execution of a regular cred-props mechanism, but don’t want to bog down this reply with tactics since we’re obviously not there yet.



Like I said, I’m so happy we’re talking about this and I’m starting to see the Creditor as the next big piece of the puzzle that so many other things rely on.

For example:

Due to the conversations and decisions around Comms and outbound recruiting of participants and user communities, Cultivation has been evaluating what would need to happen before our internal community could be ready for a large growth in participants. The first step of that plan turned out to be get more bandwidth in Cultivation Trunk. And the first step of that plan turned out to be; reward the existing Cultivation participants more accurately. And the first step of that plan is, of course, build a good Creditor.

I get the feeling that the Creditor is actually a required milestone for a lot of different goals throughout the project, and frankly, I propose that we all turn our eyes towards the Creditor and contribute to its creation from our respective fields of expertise. It’d be interesting to get everyone in the project working on this fundamental part of our technology/culture and contributing to it until we have something solid. Then we’ll be able to build our separate parts of SourceCred on top of this foundation the Creditor will create.


What do other folks think?

4 Likes

Ok, so questioning an initiative that both @decentralion and @LB are behind feels kind of like stepping in front of a moving bus, but I feel obliged so here we go:

  1. Cost benefit analysis

The creditor sounds like a considerable investment. As managers you have a responsibility to at least ball park the figures… say, 2k human-hours on the low end to an mvp? Now in terms of grain, it obviously matters specifically who will be working on this and how much cred they have but maybe 50k G? Perhaps half of which will be redeemed immediately. How does this impact fractional reserve ratio, burn rate, runway…?

Since grain outlays are currently fixed, the question really becomes about opportunity cost. Is the creditor the most important feature to move the project forward? Maybe it is… as you both pointed out, a lot of important contributions currently fall through the cracks. But I’ve got to wonder: will maker dao care? Will other paying clients care? Currently, SC isn’t even being run on Maker’s chat… I dunno, this fees kind of like a really expensive premature optimization. Which as a programmer I get off on, but as a business manager I cringe. It’s also hard to estimate impact on revenue without access of your books (balance sheet, income statement etc), not sure if this is open source?

  1. Centralization

This could be a massive step towards centralization, and avoiding that with the various voting mechanics you describe will add a lot of complexity. Yes, we need to reward meetup presentations and stuff, but I don’t know if this is the best way.

Anyways, just being honest, please don’t hurt me :v::stuck_out_tongue_closed_eyes::sweat_smile:

1 Like

Yes, I think so, both from a co-community perspective and from the perspective of our own needs.

Co-community: 1hive has been having major issues with the Cred scores getting gamed by sybil attackers. Fundamentally, I think the issue is that our Cred minting tends to be based on automated signals from the plugins (Discourse likes, reactions, etc) which are easy to game with sybil accounts. My goal is to move Cred minting into explicit governance (within the Creditor) where people are voting on which meta-contributions (projects, etc) should mint Cred.

Basically, the Creditor will give communities much better tools to express what they value. Rather than “I value Discord emojis” (which no-one really values intrinsically) you can express “I value building the Creditor” or “I value the work the cultivation team is doing hosting our calls” or “I value the Maker partnership”, etc.

The Creditor could be a more scalable version of the dot voting that 1hive was using initially.

Our needs: We’ve identified that one of the blockers for growing the project is that we need more community cultivation bandwidth, and that a blocker for growing the cultivation team is that the algorithm currently misses their contributions. So improving our ability to fairly flow Cred to the cultivation team is a blocker for overall project growth.

Yeah, it’s important that we build the Creditor in a way that is progressively decentralizable. We’re investing a fair bit on the infrastructure side there.

At a big picture level, the Creditor is about ensuring that the Cred graph meaningfully represents contributors’ view of what’s happening in the project. A graph of discord emojis and forum posts is kind of unintelligible, and misses both the forest and the trees, in favor of seeing individual leaves. We need a Cred graph that can incorporate the high-level things that really matter to the project: partnerships, features, etc.

2 Likes

Awesome :wink: this feels like a major pivot though right? From “automated comp” to “community comp” (via governance). I checked the honey thread you linked but am still fuzzy on how the voting would work.

I’d like to know what the planned UI is for the Creditor. One feature that would be useful would be to know how much Cred you would generate from completing certain tasks, so you know if you want to undertake them. This would be a tool that helps with transparency and understanding of how Cred flows. To be clear, this would not allow everyone to add nodes willy nilly, it would be part of the UI available to everyone, that would update with the actual Creditor, but not change the Contribution Graph of the project.

I’d love to hear a more in-depth explanation of your idea of local governance power. I feel like it would involve setting up nodes for all past contributions in order to be accurate in how much weight each contributor’s vote would have in a project. For example, a lot of my top Cred activity comes from props and didathing, on Discord. If the props/didathings were all about things I did for Community Cultivation, they would need to be manually linked, or else I would have little voting power in a trunk where I’ve been quite active.

Whose responsibility would it be to make sure contributions not caught by the plugins are added to the Contribution Graph? This person wouldn’t have to actually add them, but just make sure they are added. This could be the responsibility of the person who feels they “created” that node, such as the person who did a great job presenting a meetup. I personally feel that relying on the person who made the contribution to make sure it is added would create the least extra work for others.

In regards to docs, I would love to make sure that varying levels of contribution could be recognized. For example, there’s authoring, co-authoring, in-depth reviews where you write part of the doc, jams, and basic GitHub reviews. This is one of the holes I see in our current system, and something made rather difficult on GitHub. Definitely a need that could be filled by the Creditor. :ok_hand:

Have you considered using LB’s How to Start a New Project in SourceCred post to tackle some of the more nitty-gritty details, such as governance?

Also, I found this writing accessible, although I definitely skimmed through the software bit. Thanks for asking for feedback and modeling accessible writing on a complex topic :smiling_face_with_three_hearts:

1 Like

Me too! I view this as one of the outputs we’re hoping for from the upcoming design sprint.

As a general idea, I’m imagining a UI kind of like Reddit, where every “post” represents a particular contribution. Upvoting the contribution corresponds to Boosting it, which causes it to recieve more Cred. Contributions can link out to other contributions, which would be kind of like when a Reddit post has child posts that it contains. When you upvote the child comment, you’re Boosting it in the context of the containing post, which then flows some Cred to it.

Unlike in Reddit, when you upvote something you would choose the intensity of the upvote. So you could upvote something 1x, or 2x, or 3x, or 5x, 8x, 13x, etc (I like fibonnaci scales) to express how strongly you support it.

This’d be really cool to have. It’d be complicated to get this right, though. I don’t think it’ll be in the v1 for the Creditor.

Actually, I would like to allow almost everyone to add nodes willy nilly. (We’d just need to add some spam prevention, like maybe you need to pay 0.1 Grain to create a node.) However, those nodes would start off disconnected, and other people would need to boost them before they earn much Cred. To continue the Reddit example, anyone can make new posts, but since they start with 0 upvotes, they won’t be super visible until others vouch for them.

This feature won’t be in the v1 for the Creditor, and you seem to have a good handle on it, so I’m going to save an in-depth explanation for later. You’re right about the implications; the local governance will be important when the community is a little bigger, and will function best after the Creditor has been working for a while. I do want to make it easy to manually link props and didathings (and discourse posts, etc) into the Creditor. For example, we could manually link the “Creditor Initiative” to flow some Cred back to this Discourse topic.

Good question. I was thinking of it as a shared responsibility, but also one that is incentivized. I.e. creating the node in the Creditor to track a contribution is itself a contribution that merits some Cred. Something like: whoever creates the contribution in the Creditor gets a small %age of the Cred that flows to that contribution.

That post seems like a good fit for high-level posts (like this one) more so than nitty-gritty details.

Glad to hear it!