What do you mean by this?
In its current iteration, SourceCred gives the maintainer(s) the ability to manually assign weights to pulls, issues, etc. My intention is to make good use of this tool (along with public justification). So the rewards will have a fair degree of intelligent oversight.
This is a really interesting idea. I feel like there are probably some interesting real world analgoues? I brought it up on the SC office hours call and I believe @mzargham had some thoughts in response to share.
I agree that this could be a watershed. I’m not sure that I want to work too hard to encourage fast virality, though–my mantra for growth lately has been “slow and steady” (aka deep before wide). Running this experiment on SC will kind of be “easy mode” because we’re a small community that are all bought into the idea of SC and have a lot of context and want to make it work. If SC grows by 100x, it amps up the difficulty in a way that we may not be prepared for.
So, my inclination is to let the experiment be what it is, and let SC interest grow organically by word of mouth, as it “earns” the organic growth through being a genuinely useful and promising technology, rather than by hacking on the virality coefficient. Once we have a basis for more grounded confidence in the product/algorithm itself, we can start experimenting with creating positive feedback mechanisms around project growth. (That said, we will build tools like dashboards and metrics because we’ll need and want them, and other early adopters will need and want them. And we should/will publicize the experiment, esp. once it’s done, and post about how it went and whether we encourage others to follow. I’m more saying, let’s not rush into things like creating cred incentives for people to recruit more people into SourceCred before we are ready for the consequences.)