Changing the CredSperiment weights

[s_ben]

You raise some interesting questions @burrrata. As I said on the Spontanious Community Call (thx for the great writeup on that btw!), I’m OK with the new weights. They make sense to me, even if my share has gone down (for now).

I need to think more on some of these issues, but just thought I’d share my 50,000 ft view of some things:

1. Cred scores =! lifetime value contributed, yet. While that’s the basic goal, I sense that they are being used as a lever to adjust incentives until Incentives and Boosting are live (@decentralion correct me if I’m wrong). This was why when @burrrata joined the project and quickly had more cred than me (even though I’d been contributing for months), I was a little surprised but OK with it. I didn’t think @burrrata had already generated more value than me. I thought they were being “boosted” to incentivize them. Which it appears to have done:) Similarly it feels like like @anon60584824 may be being boosted? Or not, I also only saw the widget and didn’t realize all the other work on containers, etc. This is just a a problem generally we’ll see again. It’s impossible for any one person, even the project lead, to have visibility into everything, especially as the project grows. I think that for now, we do need a TBD (Temporary Benevolent Dictator) that can make decisions quickly and steer the plane as it’s being assembled as it flies though a mountain pass in a storm. I’m also keen on seeing incentives and boosting implemented so we can start using those to steer. I will also point out that, since I’m the only one that has sold Grain (~$3.5k worth (plus $2k for an earlier contract with @protocol to write an article)), I have realized infinity more dollars than any other contributor. It’s important to realize that there is non-zero counterpary risk here, dependent on a number of factors outside of our control. I absolutely trust all parties are acting in good faith here, and believe Grain will be valuable (probably more than the price I’m selling at!), but my experience in VC-backed startups and crypto have taught me that counterparty risk is a deep, complex issue, and I factor that into my decisions.
2. Decentralized governance is hard. We’re exploring a lot of new territory here. As I’ve said before, we’re grappling with some big, unsolved issues in decentralized governance. While I’m happy we’re focusing on this, and glad we’re not just going the easier route of relying on a typical startup model, I worry about scope. Are we going to reinvent reputation systems, solve the open source funding problem and solve decentralized governance? Probably not all three. However, I think it’s very valuable to wrestle with these fundamental issues as we dogfood, as they will inevitably arise again and again in other projects that adopt SourceCred. It will also inform the design of incentives and boosting (key to making this work at a project level and acrue value to Grain), and help us come up with an alternative “story”/model to present to investors, who might have other ideas anyway btw; it’s not 2017 anymore, investment in the space has dwindled somewhat and drifted towards traditional equity models, and if we want to shop a new token model, it had better be solid. I think we are very fortunate to have @protocol as a seed investor/partner here. They’ve given us a lot of trust and freedom to experiment with new models, and seem value aligned. But as we start raising capital from other investors, we should be ready for hard questions, negotiation and compromise.

@anon60584824

I’m curious - is SourceCred can be simplified to an algorithm, and you basically need to do operations over APIs and generate metrics /plot, why aren’t there different implementations to make it easier to use? If there were a Python implementation, it would be hugely easy for data scientists / researchers to use, for example. Docker helps a bit, but only for those that understand containers. I’m wondering if it would make sense to first create a language agnostic “Sourcecred algorithm” document to build other tools from.

So @mzargham built a python implementation early on in sourcecred/research, which he used when exploring designs. However I believe it’s fallen out of sync with the main repo, which has seen big changes.

Python is the only language I’m half fluent in actually, and have had lots of ideas for tinkering with the scores. Just need to find that time…

@burrrata

Currently, however, GitHub is for work on the code while Discourse is a catch-all for everything else. This catch-all includes art, business development, documentation, protocol design discussions, fundraising and strategy discussions, community calls, Initiatives, Artifacts, and much more. We’re using Discourse to manage our project level operations, design and dogfood SourceCred mechanisms, and onboard new contributors. Seems important. Building the code for the protocol to work is also super important! We need to find a balance between the two.

Yeah…Discourse may be overvalued except that we’re kind of relying on it for all non-code work. Until we have incentives, boosting, and other platforms for strategy, biz dev, documentation, etc. etc. etc., it’s difficult to value it. We also want to be compelling to developers, who are scarce…Don’t have strong opinions, just wanted to input some info into the process.