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.
Origin
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.
thank you.
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 “
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.