An Overview of Grain: an initial overview of Grain. While this Grain design is an open design space, this sets the foundation for many of the resulting conversations around Cred/Grain dynamics
So first, what is Cred and/or Grain? This has not always been clear. In the past the terms “mana” and “grain” have been used interchangeably. This led to confusion for all parties involved (mostly me). This thread unpacks that in further detail. The TL;DR: is:
- Cred is a non-transferable token based on your contributions to the SourceCred community
- Grain is derived from Cred and minted in both “fast” and “slow” payouts
Note: SourceCred itself is called Cred (capital-C). The fungible token in SourceCred-systems in general are called grain; grain in SourceCred itself is called Grain (capital-G).
Ok great! So how does one get Cred, and thus Grain?
By contributing to the SourceCred community of course. More concretely, SourceCred is running a “CredSperiment” to mint Cred and Grain for the community on a weekly basis. There’s a lot to unpack in the CredSperiment category, but the introduction is a great place to start.
How’s the CredSperiment going so far you might ask?
Week1 and Week2 have not been unsuccessful. Unlike most scientific experiments, both the data (SourceCred community contributions) and the model (the SourceCred algorithm) are shifting here. People are not upset about this. In fact, contributions and conversations seem to be picking up steam. SourceCred is one of the first games that you can both play and design at the same time. Exciting times!
In the near future community contributors will be able to use their Cred to vote on the SourceCred roadmap. This makes sense as contributors to the community would know what’s important and what they want to contribute to.
In addition, “Initiatives” have been created. Initiatives are things that the SourceCred community wants to do. Soon people will be able to use their Grain to “boost” initiatives and drive more Cred to that topic. Think of it as a +1 mushroom that boosts all activity around that initiative. (@decentralion is that more or less accurate or do you have a better explanation?). The Initiatives Plugin is under active development (at the time of writing). If you want to help make it happen and earn some Cred jump in!
So what’s next?
On the one hand, there’s talks to infuse more capital into the SourceCred ecosystem (thus creating a “market” and price for Grain). On the other hand, SourceCred is still managed in a centralized database and managed by a “benevolent dictator”. This allows SourceCred to quickly experiment and iterate, but it also places an incredible amount of trust in the core team (mostly @decentralion).
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.
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.
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:
- 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.
- 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 )
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.
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.
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.
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
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!
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.
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.
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…).
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. So you can start working now, and keep track of what you want to boost.