About Champions and Heroes

So, I brought up a term “Champions” and it’s been floating around for a little bit. This is to figure out what it is exactly and what we can do with it.


I originally got this idea from this talk:

Very much worth a watch, but something he didn’t do is give a concrete term like champions. There are bits and pieces of it spread around in the talk. Part of it is me taking his ideas and filling in the term. Especially later on, he mentions heroism as well.

You don’t want heroes, that’s a tragedy. You want champions. I loved how hilariously arbitrary that distinction sounds without any context, which encouraged me to figure out the differences and why to prefer champions.

What’s a hero?

Heroes are easier to describe, so let me start there.

When things are going wrong… in fact, it seems like total disaster is inevitable. Against all odds a hero shows up, puts in an impossible amount of work and miraculously, disaster didn’t happen. Things turned out alright.

“Everything is alright now. Why? Because I’m here!”

A bit more sober summary:

  • Without them, things would have gone wrong.
  • Their help is unexpected / surprising.
  • Their help is very substantial.

Examples of heroes on a dev team.

  • In the middle of the night, production servers are on fire, full outage. Someone on your team, who’s not even responsible for the servers, just so happened to notice. Works till 2 am to sort it out. Barely any customers noticed.
  • An important bug / feature on an open source project stalls, because there’s nobody there to work on it. Without any prior notice, someone in the community shows up as a first time contributor and implemented the whole thing in one go and submits a PR.

Why is this a tragedy?

If heroes show up, yes those heroes are amazing. We should be grateful to them. But when you think about it, having heroes is an unexpected positive outcome, when the expected result was bad. From a planning standpoint, your structure failed to prevent disaster. It worked out because of a selfless effort and luck.

What’s a champion?

“…that is what I’ve set out to do. And you can count on me to see it through to the end.” - the champion states in no uncertain terms. With a steady pace and clear message, the champion provides confidence and predictability to everyone involved. Regardless of setbacks or ethical dilemmas, the champion leads the charge, restores faith, and gets the job done.

Without dramatic effect, summarized as:

  • With a champion, people know what to expect.
    (manage expectations, follow process, communicate clearly).
  • They are marathon runners, focused on seeing something through from start to finish.
  • Their help is also very substantial.

Examples of champions on a dev team.

  • A team member who proposed a new feature. Finds out what problem it solves, how valuable it is, who would use it, gets feedback, works on or delegates implementing, gets it signed off, sees it deployed to production, monitors for problems and announces the changes in all the appropriate channels.
  • An open source contributor who commits to working on a particular component, goes through the process, same as above, and becomes the primary “maintainer” of that component.

How is that related to SourceCred?

As you might have guessed from my dramatic introductions. In terms of reputation, both heroes and champions deserve a lot of cred. However the incentives should promote championing more than heroism. Or that’s what I think anyway.

Which brings me back to this:

Both heroes and champions will currently be undervalued. However, I feel we should incentivize championing. As having heroes is tragic. And in extreme forms, incentivizing it could mean there’s incentives to wait for, or even cause disasters, so you can be a hero. It makes sense to me, to undervalue heroes a while longer and focus on champions first.

So, it starts with measuring champion-like behavior. To do that, we need to know what is champion-like.

Defining champion-like

This in particular I would like your thoughts on.

Things to do:

  • Make a proposal or take an existing one.
  • Scoping the work to set expectations.
  • Find out who would use this, and how valuable the work is.
  • State what you will be working on and what you expect to be able to do.
  • Provide structural support to get the work done.
  • Getting a sign-off on the work when done.
  • Offer post-release care and/or refinement.

Some other properties:

  • Creating confidence (means, commitment and subjective evaluations from others)
  • From start to finish (means, can only be measured in retrospect)
  • Setbacks and failure are possible. Communicating risk and “fail fast” approaches are good championing.

This is amazing. Spent the last few weeks thinking through how to promote this kind of behavior in the Aragon community. The way you summarized it is spot on. Thank you so much for bringing this to light in such a clear way :slight_smile:

Glad to hear @burrrata :smiley:

I would love to hear from you though in your words what “this kind of behavior” means. As the challenge is probably going to be in defining that first. I still have some parts about what is champion-like that’s vague.

So yeah, what sort of behavior are you thinking of encouraging?

1 Like

Champions, as you described, show up consistently. Not only that, but they have a high degree of integrity. Their goals are aligned with the goals of the platform/community. They start relevant discussions, they help shape those discussions into actionable goals, they contribute to doing the work, and they stick around to ensure that things get done vs just perpetually staying at the idea or prototype stage. In addition, they do all the menial things that no one else wants to do, but is essential to making everything run smoothly. These tasks/actions will be specific to every community, but the overall theme is that champions are aligned with the community and work to add value to the community, vs working so that the community can add value to them.

In the context of open source communities, there’s usually two sides of the funnel: technical work and meta-level work. It’s important that people do their best to meet in the middle. For people contributing to high level ideas and discussions (like me), it’s important to also explore the code, run the prototypes, and contribute feedback where helpful. For technical contributors, it’s essential to engage with the community to help shape discussions and understand how a specific app/widget fits into the overall goals of the community. That’s a really naive way to break things down, but I’ve noticed that these two groups (technical and non-technical) are often the main divide in open source communities. When devs share their work and get feedback the apps are always better. When community members actually understand how the tech works their ideas and insights are always better. Champions on either side do their best to engage with all stakeholders in the community so that everyone can work together harmoniously towards a shared vision and goal.

In the context of SourceCred specifically, on the forum we’re starting to think of ways to make ideas more actionable so that we can link Initiatives to GitHub activity. On the GitHub side, we’re trying to make SourceCred easier to use and explore so that people can understand it and provide feedback. This is an ongoing process that takes a lot of time and coordination, so really champions are the only ones who are suited to do this work. It’s cool that SourceCred has the slow payout category to reflect this so people who show up consistently get more weight than those who check in every once in a while. As Cred is used more and more for governance and/or incentives around boosting it will be essential that the long-term consistent contributors have more weight than those who just showed up.

I’m looking at this all and it’s still really vague. Does this make sense or should I go back through and try again? lol


That’s how I felt too, so that’s why I think this discussion is great :smiley: thank you.

About bridging the gap and meeting halfway between technical and non-technical. There’s some interesting points about that in the talk.

For example as he calls it, finding a user-side champion (confuses a bit with what I have in mind for the champions term, so maybe should find another word). But the point being, someone who plans to be a user of whatever you’re building from the technical side, and will put in the effort to represent the user side. To coordinate with them, and even get them to sign off on it when the work is done. This may be a little more difficult in an open-source project than when people on both sides are on payroll, but still sounds like a good practice to me.

Something interesting you and @decentralion seem to have in mind first is that “champion” is a person’s status based on their behavior.

I’m gravitating more towards looking at that behavior per unit of work to decide who “championed” it. So it isn’t a scale of how much of a champion a person is, but was this work championed and by who?

If you think about the life cycle to develop a large feature:

  1. Describe
  2. Propose
  3. Find out who cares about it and how important it is
  4. Describe even better
  5. Put it on the roadmap and commit to it
  6. Do work
  7. Get feedback
  8. Do more work
  9. Document
  10. Feedback
  11. Final touches
  12. Release
  13. Announce
  14. Post-release care
  15. Answer questions

There’s a lot that goes into the process. All too often that process falls onto a project maintainer, even if people are helping with the implementation. I would argue if someone just shows up to program (steps 6-8) and the maintainer does everything else around process and keeping the community informed, the maintainer championed it and delegated implementation work.

Conversely, if a contributor shows up to do all of this, I think it wouldn’t matter if the implementation was done by multiple people or if they delegated it and didn’t program at all. They championed it.

So I think one important aspect is, overseeing the process.

Why I believe it makes sense to do this per unit-of-work is that it’s a lot easier to agree on. The reputation of a person, I feel like should be what their cred score represents. So if we can agree who was the champion of some work, they can get extra cred from this. Repeating that will give you legendary scores.


+1 on all this! It’s incredibly time consuming (and sometimes emotionally intensive) work. The people best suited for it are those who show up consistently, understand the goals and pain points of the community, and work to make things better for all parties involved (often maintainers in open source projects). Identifying, supporting, and incentivizing this work is essential. As we keep saying, what gets measured gets managed. If we can agree who was the champion of some work or process, then we can reward that valuable contribution to the community. Again, this is incredibly important so thank you for starting this discussion!

@decentralion How can I boost this thread and/or flow more cred to @Beanow for starting this thread?

Also, circling back to earlier discussions around modeling and documenting cred/grain dynamics, are we ready to create a SourceCred User Guide yet? Would be awesome to have that as a reference, even if it’s a WIP living doc.


Like @burrrata, I can’t overstate how much I value this thread and concept. I feel like Champions (specifically technical champions) are exactly what SourceCred needs right now.

I’ll add another idea to the mix, based on a conversation @Beanow and I had over voice chat today. Champions need to credibly commit to the things they say they are going to champion. When someone says they will be a champion, they are taking on responsibility, and (implicitly) inviting the support and help from the rest of the community in achieving their goals. If they don’t follow through, they are harming the community, both by wasting others’ time and energy, and degrading the collective trust in champions.

Personally, I feel I’ve experienced this a lot in my maintainership of SourceCred. A number of times, people have told me they’re interested in getting involved in SourceCred and doing some implementation work. Many times, I’ve then invested a bunch of my energy in ramping them up on the codebase and practices, only to see them disappear without any follow through. It makes me reticent to invest in onboarding new contributors, because I don’t know if they’re really commited, or just “like the idea” of helping out.

Therefore: I propose that when someone becomes champion for an issue or initiative, they need to commit to a timeline, and stake Grain behind their commitment. The exact amount of Grain will depend on the size and scope and rewards/bounty on that particular initiative. If they follow through, they will get back their grain stake, along with extra cred and grain for successfully championing an initiative. However, if they never actually do what they promised, they lose their pledge.

With a system like this, we won’t have “fly by night” or “fair weather” champions. The champion needs to demonstrate their commitment to the issue, by being willing to stake some of their status within the community. I think this will give the community more confidence in rallying around champions, and increase the meaningfulness of the role.


We want to build explicit mechanism for boosting contributions, whereby people can burn Grain to increase the Cred of a contribution. This can be seen as participating in a kind of prediction market, since Boosters will get some of the future Cred (and, thus, Grain) that flows to the contribution they boosted. I think it’s plausible that this post will receive a LOT of long term cred, especially if we implement suggestions like this where people who create new systems within SourceCred receive a fraction of the future cred that flows through that system. So, we could imagine @Beanow receiving a fraction of all the future Champion-cred, for having developed this system.

(References on boosting: "Cred Historians" and Curators, CredSperiment System Overview)

However, boosting doesn’t exist yet, so unfortunately you can’t currently do that. :slight_smile: Rather than inventing an ad-hoc way of boosting this one thing, we should start planning how to build the boosting system. I think the first step is to write an Initiative describing how boosting should work and some general thoughts on implementation. There are architectural/technical questions here, but also UX questions. For example: how does a user actually Boost something? Do they do something like writing “@credbot: Boost [link] with 100 grain”? Or do we build a whole separate UI for people to boost things?

I think this would be really valuable. To get this started, it just needs a Champion. :wink:


Also :heart: this thread. I think SourceCred is going to need robust models such as this to capture these important dynamics. Doing it this way seems fairer than say, having a ‘maintainer’ role that gives one more cred per contribution. It gives genuinely good maintainers cred they deserve while also providing a path to being a maintainer, or simply being more “maintainer like”, and provide extra value through championing. Reminds me of corporate jobs where people “own” something. But there you’re typically valued by a performance review from your boss, which is suboptimal.

This is the best way I’ve heard this concept described. Makes total sense and is exciting. I keep seeing the idea of prediction markets emerging in different contexts. Apparently they have a lot of desirable properties.

Could be a good idea, but a little wary…introduces complexity and a barrier, and I’m not sure how much value it will add. In my imagination, this issue could be solved already if we have metrics/heuristics that value people that stick around. In other words, you don’t get cred for talk and piddling about. You only start getting meaningful cred when you say, become a champion of a little project, or help meaningfully in other ways. I think having to put in a significant amount of work for free (or relatively little) functions in a similar way. The general ‘work token’ idea though, which I’ve seen expressed before other places, could have legs. And typically this scheme has people stake tokens to purchase the right to work and earn cred, similar to bonded contractors or taxi medallions. I wouldn’t be surprised to see those ideas surface in OSS too.

Love this. And it’s pretty much exactly what’s in the talk as well at 9:07.

Commitment, What are you willing to stake your reputation/job on?

The value this adds, I believe is exactly like in the talk. “What can you plan around?” it’s not that change is unexpected. But you need something to plan around. When it comes to opportunity cost investments, like onboarding new contributors, or reliably being able to suggest another contributor to not do the same thing or talk to the champion, because someone already committed to it.

I think it’s also not a bad thing to have a barrier here. As I don’t imagine the goal is to have every contributor be a champion of something. It’ll be a subset of the contributors who are willing and able. But not only that, I think trusting and relying on someone’s self-proclaimed commitment in a social setting also requires you have some existing reputation with the community. To stake grain, I think is just a sourcecred way of expressing that.

I will say, it goes against traditional open-source wisdom, to lower friction for contributors as much as you can. But that’s again why I think it will only be a subset. With a healthy amount of champions, there shouldn’t be a need for every contributor to be a champion. In fact, I think this would again be a typical maintainer role otherwise. To tell non-champion contributors who put in a proposal: will that get priority, is it a #wontfix, when can you expect it to be worked on, who will work on it, what release does it go into? With a champion system in place and working well, it’s a lot simpler to answer. Is this the type of issue that needs a champion? If so, does it have a champion?

Complexity wise, I think by incentivizing enough in the form of cred, grain (and glory!), there’s enough positive reinforcement to work out those details. Similar to how a lack of nice tutorials and fancy user-interfaces wouldn’t stop people from mining crypto.

1 Like

Would this be related to the boosting feature, but rather than having boosting be a 1-way stream it could also be negative? Or are you thinking of a much simpler fixed deposit staking mechanism?

Still unclear on this. Does one need to explicitly proclaim that the are a “champion,” or this a subjective measure that the community awards to outstanding community members? Another way to think about that is do you have to earn the right to be a champion (like completing a marathon), or do you take the title of champion (like signing up for a marathon). In the context of staking to align incentives it makes sense that you would take on the “champion” role. In the context of champions as outstanding long-term members of the community, however, it seems like that should be something awarded by others and not declared by one’s self.

Right, but does someone elect themselves as a champion or does the community review a contributor’s performance and award them the title of “champion?”

Agreed. The UX and narrative around this is concerning. What if there was a threshold where if you contribute to more than 20% of the cred of an initiative you get a “champion boost” where your cred for that initiative is doubled or something? (could be any percentage, but I just picked 20% as it seems achievable enough to motivate engaement).

We already put in tons of work for free all over the OSS ecosystem. Enough is enough! Also, considering the early adopter risk of getting paid in “magic internet money,” I think that asking people to work for free or to spend real money to earn the right to work for “magic internet money” seems like a bit of a stretch. The UX should be such that anyone can start contributing right away and it’s a rich and rewarding experience for them.

Disagree. There’s only a handful of people here. Obviously the “glory” is not enough (although the level of interesting conversations definitely is!).

This is actually a huge problem in the crypto space and the next generation of apps that have good UX are completely crushing the apps that don’t have good UX. Good ideas aren’t enough. You have to also build something people want.

What if there was the option to stake cred to a commitment, but not the requirement? This really feels like boosting the more I think about it. You’re just booting your own initiative. If that goes well then everyone wins. If not, they you just spent a lot of cred. The boost signals the commitment, however, because you spent a rare resource to signal intent. On top of that, if there was a “threshold boost” built in to the Initiatives protocol then you would be rewarded to maintaining your position in an initiative as it evolves. Combining a regular boost (to signal intent) with a threshold boost (for actual contributions) could be huge, not just for the person “championing” the endeavor, but also the “senior” members engaging to help that champion (and thus getting the threshold boost themselves)

Just summarized my thought on the dichotomy of championship in the boosting thread. Will copy here though so that it’s here in the context of the above comment.

  • There’s a dichotomy between declaring championship and earning championship. Boosting allows someone to signal intent towards an initiative. From there, however, we want to incentivize ongoing and increasing participation. Threshold boosting would give a boost to contributors who pass the threshold contribution of an Initiative (say 20%). This incentivizes people to keep contributing as more people also contribute. This allows people to both declare that they intent to champion an initiative through boosting, but then also earn “champion rewards” for following through on that commitment and contributing throughout the lifetime of that initiative.

Thinking about this more, and as someone who’s curious about the inner workings of SourceCred, this is rather relevant.

  • First, I don’t want to waste time. I’m generally fully booked so I try to engage where I can, but not so much as to over extend myself.
  • Second, I have no idea how much time it actually would take to “onboard” to the SourceCred codebase. Having recently spent quite a bit of time exploring the Aragon codebase and dev docs, the learning curve was quite steep. Lots of docs were missing or outdated and the codebase was literally changing underneath you as you tried to learn how it works. This was not fun, and many people have left the Aragon ecosystem because the cost of staying up to date with things is just too damn high.

So with that in mind, what is involved in “onboarding” to the SourceCred codebase? Is it something a developer could do in a weekend? Is there helpful documentation? Where should one start?

To be clear, I don’t expect SourceCred to have robust documentation or tutorials (although that would be great). What I’m trying to say is that in addition to incentivizing champions to follow through on initiatives, it would also be good to make it easy for champions to estimate the scope of work involved before committing to an initiative.

1 Like

I’ve also experienced that in a recent project I lead. The main difference between me who kept going forward & the other persons who fell behind was that I had resources at stake - I had already invested a good amount of time, energy & money - so there was no turning back for me. A solution to that challenge that some friends use is that they ask contributors who take part in their project to financially contribute to the project’s expenses & if they want to pull out before a certain time they lose their financial contribution.

OK now I’m seeing @decentralion’s comment:

Which is exactly the same process. :slight_smile: I totally support this.

1 Like

A bit of context in my answer to this: two DAOs I’m part of have been created to support an open source project - much like SourceCred could create a SourceCredDao to support efforts made on SourceCred. As time went by I saw some patterns & ended up splitting the work/contributions into 4 categories:

  1. Buidl – code effort, specification, design, documentation…
  2. Community Growth – growth strategy, community chat support, weekly community calls, 1-to-1 onboarding support
  3. Operations – bookkeeping, proposal monitoring (delivery & funds), treasury management, soft governance
  4. Marketing – creation of events (online & offline), articles, podcasts & videos

Totally agree.

This is very related to the topics of responsibility & accountability. As in, if one has the responsibility of overseeing the process you most likely want to make that person accountable for the outcome (for the good & the bad).

Here is one of the most interesting article I’ve read on the topic:

Consistency seems to be key aspect in the “Champion” concept you guys described. The key here is that rewarding via Sourcecred is allowing rewards to be recurring & retroactive. Now if you add that staking layer on top (mentioned in my previous answer) then you get to incentivize predictable outcomes.

I like the fact that one can earn the title. A lot of projects have Ambassadors Programs that reward their top community contributors. And often one has to go through a first level of commitment to reach that status. i.e. you 1st are part of an Apprentice group & once you’ve reached certain targets you’re allowed into the Ambassadors group. SourceCred could have a Padawan group that one first joins & when some goals are reached one gets allowed into the Champion group where you have access to more challenging tasks, etc. Finally, there could be a “shortcut” to the Champions group based on some conditions established beforehand (i.e. voted to allow in by all Champions).

In these first steps, the only thing missing is decision-making. As in, “who gets to decide the priority of a task & when it should be implemented”. I don’t want to create a big debate about this in this thread coz it might just go off-topic. But that’s maybe something to consider clarifying (add a step in that list?).

1 Like

Cool! Which ones?

This is a rather good point.

Isn’t this determined by the amount of boost as well as engagement an initiative has?

You’re conflating contributing with championing. Anyone can contribute to SourceCred, and they certainly don’t need to stake Grain in order to make contributions.

Championing, as I see it, is different. Championing is stepping up and assuring others in the project they will take care of something–like @AdrienDLT said, they’re providing consistency and predictability, which is very valuable. However, that is only valuable if they actually follow through. Champions that don’t follow through actually destroy value, by decreasing the community’s trust in champions, causing people to invest in a failed effort, and possibly by preventing some other, more serious, champion from taking on the initiative.

Therefore, champions should demonstrate that they’re taking skin in the game by staking some grain. Someone who hasn’t yet earned any grain may not be a good choice to be a champion anyway; they should consider doing some work as a regular contributor before taking on the mantle of championship.

You’re attacking a strawman; @Beanow said “cred, grain (and glory!)”, not “just glory”. More generally, SC is still a young and small project. Even if it were only glory, I think the community could still grow; look at how big IPFS is, for example, and they don’t have cred or grain!

Boosting is independent from who does the work. Given that I boost an initiative, it doesn’t necessarily give me a huge added incentive to do the work personally, it means that I hope someone does it. Whereas, if I champion it (and have staked behind my championship) I have a very strong personal incentive to make sure the work happens.

There’s a big risk to “bystander effect” issues where everyone hopes someone else will take on the big task. Champions provides a way for us to ensure that a single person is directly responsible, which is a great pattern for getting results.

1 Like

The best resource for onboarding onto SourceCred is this code walkthrough; it’s fairly old but the fundamentals are still the same. I think if you watch it you’ll get a pretty good sense of what the codebase feels like.

@Beanow is in the process of onboarding so maybe he can speak to what his experience has been like.

Genesis DAO [supports the DAOstack ecosystem] & PolkaDAO [supports the Polkadot ecosystem].

I suppose you guys will have to decide how to do this. Decision-making regarding prio & timeline is probably not gonna depend “just” on boosting & engagement a task gets. I’m assuming that the bigger the project & the contributor community become, the bigger the more complex that process will become. Adding financial incentive on top (Grain) also changes the “game”, as in then engagement for a task may be because it’s well rewarded (vs it’s a feature one thinks really matters hence implements it). Anyhow, that’s getting a bit off topic. Just a point I wanted to mention.

At the risk of going off topic here, I’ll touch on onboarding briefly. Happy to elaborate in more detail elsewhere if interested.

The fundamentals, like the graph and pagerank algorithm are well documented and worth investing time to learn. Development wise, depends a lot on where and what you want to contribute to. Some examples for what I worked on,

  • Taking the sourcecred scores format and building from there (like widgets and payouts do) is easy. Scores’ documentation isn’t great, but because it’s just trivial CLI commands and a comprehensive json file, you can build prototypes in one or two hours.

  • Current work on Write the Initiatives Plugin has a high difficulty and needs some background on most of the internal systems and theory. It takes time to learn and I don’t see anyone but seasoned programmers being comfortable touching it at all.

For the short term this is in line with expectations for me. With the top priority being prototyping to get the CredSperiment to do well. When we’re looking to shift priority to broader adoption in open-source projects I can see it being an issue.