Cred/Grain Dynamics

To address this dichotomy of experimentation, growth, and trust data is made freely available. This creates a “trust, but verify” model. Everyone has access to the underlying SourceCred data, and everyone can run the SourceCred algorithm. This puts pressure on the project maintainers to act honestly otherwise the community will fork and/or leave.

1 Like

In fact, because both the underlying data and the SourceCred algorithm are open source an ecosystem of 3rd party applications and features are possible. This could involve extending the current SourceCred model or even aggregating data from multiple communities. Compared to the walled gardens of web2 platforms, SourceCred has the potential to achieve network effects at scale while also being open and permissionless.

1 Like

This whole thread is a great summary. Makes many things fit in brain.

I’m still working out the details of the donation system. Please consider it a “tentative experiment”; I don’t recommend that anyone donate to SourceCred in expectation of receiving Grain at the moment.

Some feedback @burrrata on this experiment:

  1. I quite like it. I’m finding this a valuable resource for explaining the project to others; just now I’m on this thread because I’m going to send a link to it to a collaborator.
  2. I think this would be better as a single wiki post. Having each new post as a thread means:
  • We can’t re-order them (e.g. I think your post with the link to Grain should come after the post that gives 1 sentence explanations)
  • We can’t easily remove outdated bits
  • Folks’ commentary (about the experiment) gets interspersed with the reference materials

Would you be game to re-collect the references into a canoncial wiki that we can keep maintaining? We could make a new “docs” category for such documents. E.g. having a wiki post with a deep dive on how the SourceCred algorithm works in detail could be great. (I can sign up to write it :slight_smile: )

1 Like

Agreed. It’s a living brainstorm of ideas for people to dive into, expand, branch, and do whatever with. It highlights a core narrative, but does so in chunks so that people can dive in or build on top of it. It’s meant to be a living ongoing conversation.

Docs are very very different than the spotlight/narrative idea. While docs would be great for SourceCred, docs aren’t as fun/engaging to write. Also, traditionally, documentation work has been paid less and been less appreciated than general discussions, design, or development. Having contributed to documentation for several projects, I’m hesitant to continue in that direction due to the reasons listed above.

If we were, however, sketching out and designing the incentive/token models of SourceCred and then needed to formalize that into a spec, I would be intrigued…

The great thing about SourceCred is we’re explicitly building a tool to let us solve incentive alignment problems like this. I agree that docs are a lot of work and are under-appreciated, so it makes sense that you’re hesitant to commit to them. However, I am personally committed to building systems in SourceCred that amply reward documentation work, and using the SourceCred community (“CredCore?”) to model new ways of valuing documentation work.

If you’re willing to take the leap of faith and start writing docs even though we don’t yet have the system for valuing them, you have my assurance that:

  • we will build systems that recognize documentation contributors, and reward them for the difficulty and disproportionate value of writing good docs
  • you’ll have a seat at the design table when we’re building the system that rewards documentation work

Right now, I’m prioritizing an “experimentalist” vs “theorist” approach to the incentive/token models. Which is to say, I’m pretty darn sure that ideas like Cred Bounties will be really important, and I know that we can make a very simple / obvious implementation and start getting some good results and data. Once we have a few more of these systems working experimentally, I’ll be more interested in taking the step back to try to spec our how they shoud work. It feels like we’ll be better equipped to have those discussions once we’ve experimented with prototyped versions for a few months.

That said: a great thing about permissionless open source projects is that people are free to contribute value in whatever way calls to them. If you want to champion WIP living spec exploring the cred/grain dynamics, I’ll be happy to support you.

1 Like

Ok cool! I’ll actually be catching up on some documentation stuff for 1Hive really soon, so as I do that I’ll think about if/how to apply that process to SourceCred and/or what would be the best way to go about it.

@s_ben You do documentation work too right? Do you want to collaborate with me on this and/or are there any examples of inspiring documentation in the wild that that we could draw off of for inspiration?

Also agree on experimentation > theorization as a design process, but it would be cool to document the experiments as we go so that everyone can be on the same page and then we can clearly see how the experiments evolved.

2 Likes

Would be down to collaborate on docs stuff. Like yourself, I’m hesitant to commit to documentation tasks. Mainly because that’s been my main gig for a long time, it can be really tedious and unrecognized, and I’m trying to transition away from that and towards more development actually. That said, it is important, and it’s an area I can solidly contribute to. Would be cool to collaborate with you as well @burrrata.

To give some honest feedback for the CredSperiment, this is something I would generally need more cred/grain/$$ to be incentivized to do. Otherwise, might as well do something that’s more fun/engaging.

As for the project’s doco needs, I definitely sense a need for things like this summary thread. I’ve had less bandwidth the last few days, due to a crash in the price of the crypto I get paid in reducing my savings, getting sick (barely cognizant as I type this), etc. And already it’s already getting hard to follow some of the developments on Discourse, GitHub. Lots of work going on! I also imagine the technical documentation on GitHub is drifting out of date (true @decentralion?). But it’s tricky documenting a moving target. You don’t want to document processes that are are still in flux. I am also a fan generally of video for some things. E.g. this video of doing conviction voting in Aragon.

Not the best example, as it could use a voiceover. But things like this can be documented much quicker, and sometimes better, with video.

A newsletter could also be something useful. Though tbh, have tried multiple times to get excited about that but can’t seem to motivate. Possibly because I’m doing similar work elsewhere and needing other types of work to balance it.

2 Likes

The struggle is real. I really appreciate your honest feedback. If you’re not into the idea of writing even more documentation than you already do (totally understandable!) then no pressure. Much better to focus on things that are fun and drive towards your goals :slight_smile:

A wiki and/or docs would be helpful because, as mentioned, there’s simply too much for anyone to track and information is all over the place. Would be cool if there was an easy way to see the current state of SourceCred at any time. This is easier said than done, however, without it being someone’s full time thing. A newsletter would also be cool, but again, someone has to do the heavy lifting. Good writing takes time. Richer media like infographics and video could also help considerably, but those often take just as long, if not longer, to create.

I really enjoy sythesizing data because it helps me refine my thinking and illuminates assumptions or hidden truths in data that I would otherwise overlook. That’s why, in addition to the encouragement and support voiced by @decentralion, I’m thinking about how to best contribute to this effort. That being said, I’m incredibly busy atm and documenting a moving target is quite challenging, so still not sure how to best proceed.

This brings me back to the idea of “spotlight narratives.” In an ideal situation these would be a broader community driven discourse that builds a narrative vs a wiki maintained by a few. Many hands make light work. Also, many eyes looking at data reduce errors and biases #wikipedia #open-source. Finally, humans are social creatures and documentation is lonely and unappreciated work. Refining and organizing ideas in a social context could make it much more engaging and rewarding for participants.

While “spotlight narratives” would be really cool, it suffers from an infrastructure and bootstrapping problem. Discourse isn’t currently optimized for this use case, but even if it was there’s no evidence that people would actually engage and participate. It would only be fun if lots of people did it.

So with all this in mind, still not sure how to make documentation fun, engaging, and rewarding. As @s_ben mentioned, there would need to be monetary rewards. In addition, I think there needs to be a social aspect, but not sure what that would look like… If you have any ideas at all whatsoever please share. All ideas are better than no ideas!

2 Likes

What if we used the Discourse wikis as documentation sources of truth, and modified the Discourse plugin so that everyone who edits a wiki gets cred in it (perhaps proportional to the # lines changed or added).

This wouldn’t scale forever, eventually people might game it by making meaningless edits and we’d have to reconfigure it and get smarter. But it might work for the near term where we’re a tight knit community doing the initial work. And we could use the new cred bounty system we’re building to give a lot of cred (and thus $) to the documentation pages.

1 Like

That sounds like a great idea. In addition there should be a “meta-wiki” that lists all the various wiki posts in one place so people can find them.

  • We could start by creating the meta-wiki to determine the things that need to be documented (aka important things to keep track of).
  • Then we could create new threads/wiki-comments for those items, but with placeholder text and/or a spec detailing the things that the first draft of the wiki should cover.
  • We could then “boost” those threads/comments so that people are incentivized to start work.

While this doesn’t address the social aspect of docs, it would provide a framework and incentive model that makes it much easier for anyone to jump in and get started.

1 Like

Thinking about this more in the context of boosting and it’s really too bad that we don’t have that system set up. Almost makes me want to wait to do documentation work (and really everything) until after it’s setup, otherwise I’ll totally miss out lol

That being said, that would be boring. The main “perk” or SourceCred is that it’s fun so def not going to do that. Interesting to think about, however, because incentives should be directly correlated to value creation, not just timing and/or what happens to be getting measured and managed (at least in a perfect world…).

1 Like

A post was split to a new topic: SourceCred Timing Questions

Boosting works retro-actively. For example, as soon as we enable boosting, I am gonna go back and boost initiatives/pulls related to the initial buildout of the Graph module, since it’s one of the most vital pieces of SourceCred. :slight_smile: So you can start working now, and keep track of what you want to boost.

1 Like

Great!

Would also be cool if there was a token curated list of all the initiatives ranked by the amount of Cred flowing to them (via boosting or engagement). Then contributors would know what’s valuable and curators could hunt for under appreciated cool stuff and then boost it to get it on the leader board.

1 Like

Should be pretty easy to add once the initiatives plugin is merged. The UI already supports filtering arbitrary types by highest cred.

Adding an integration to Discourse, so that we could sort-by-cred, would be really interesting.

1 Like

Awesome! Added this idea to an “Initiatives Wishlist” so that when the initiatives plugin is merged someone can adopt this idea (if they want)

I think the fact that you enjoyed synthesizing data as part of your process is really useful actually. One thing I keep coming back to is the potential of SourceCred to value work that people just feel like doing. Because often, like with your recap thread, people do end up doing work that isn’t glamorous, just because they know it’s valuable. And those contributions, in aggregate, are often enough. Open source is taking over, it seems, in spite of not having enough traditional documentation. It just needs enough to get the job done. There’s also often degeneracy. Not in the bad sense of the word, but in the sense that it has redundancies. There are multiple paths to the same information, in different formats (thread, GitHub README, blog, video, etc.). What is important is just that the path to understanding is robust and not too painful.

That said, someone making a concerted effort to put it all together in useful, more complete docs, is also clearly valuable. This is where something like Champions would be useful. I would brainstorm more about how to collaborate here, but actually am getting pulled into my normal tech writing gig here, which is going to keep me very busy for the next couple weeks. Between that and the podcast (which I’m championing), should probably not commit to any more right now. But going to be chewing on issue in the meantime.

2 Likes

Been thinking about this so much lately. The idea that it “just works” is amazing. Focus on what you love, do the work, and forget about everything else. It’s a dream come true :slight_smile:

I feel like we should really explore, emphasize, and advertise this as one of the core value props of SourceCred.