What are Supernodes? Artifacts and Initiatives are Supernodes that are manually boosted. How exactly this works is still TBD.
- Initiative: collects activity towards a goal. Clear goal and a specific moment in time.
- Artifact: ongoing thing we care about that creates value. Keeps track of all the work across time that goes into creating and maintaining a thing.
How do we interact with Supernodes? Currently we’re using Discourse to manage Initiatives and Artifacts. To make the UX (and Cred flow) of writing posts and reading posts simple, we will include as much information in the Artifacts as possible. This way there’s a single source of truth for people to view and link to. In the future we will have a dedicated UI for Supernodes, and at that point the characteristics and UI/UX of Supernodes (including Initiatives and Artifacts) will most likely change.
How will Supernodes affect the flow of Cred in the future? Currently we’re tracking raw activity across GitHub and Discourse. This works great for individual repos or forums, but it gets quite complicated when comparing contributions across multiple platforms and multiple types. We would like to move towards a system where SourceCred mechanisms are first class citizens in the protocol and become the primary method of measuring Cred. As we do this, we also want to ensure that SourceCred works “out of the box” for people who just want to try it out without investing hours or days setting everything. To achieve the best of both worlds each new instance of SourceCred will create a top level Artifact for the thing it’s being run on. Initially this will include GitHub repos and Discourse forums, but in the future might also include many other platforms as well. This way if you create a SourceCred instance Cred will flow from that Artifact to raw activity on the platform, but if you want to customize your experience within the platform or link to other platforms Artifacts are built in as first class citizens. This makes SourceCred work as is, but also easily up-gradable.
With any complex system or protocol, there is always a risk of people charging off in different directions. This can be due to “blind elephant syndrome” where everyone interacts with the system in a different way and thus has a different understanding or view of it. This can also be due to misaligned incentives. When it comes to codebases if the logic of a contribution does not mesh with the codebase it simply won’t work, thus pull request reviews are standard practice. Oddly enough, however, outside of software development this practice is virtually unheard of.
In order to ensure that everyoen in the SourceCred community is on the same page and that we move forward together we would like to instill a culture of reviewing things. This could be for changes to wikis, completion of Initiatives, or changes to Artifacts. Initially this could be a manual process with TL4 users, but in the future Cred weighted voting might be used. More discussion is needed as to how exactly we can implement a review process into the contributor experience.
Discourse is not built for code review. GitHub is not built for managing non-code data. The UI/UX of Discourse favors non-technical folks while GitHub favors those already familiar with the GitHub workflow. This is difficult for us. To better understand the tools available to us we will A/B test writing documentation on Discourse vs GitHub to see which works better for our community.
We need an easy way to keep track of art and media related to SourceCred. We explored using an Art GitHub repo, but that didn’t seem to be working to well. Now we’re going to try creating an Art Archive artifact for all SourceCred related art. There will be a public SourceCred folder that Trust level 4 SourceCred community members have write access to and the public has read access to. SourceCred community members will add art to the folder and then link to the art in the Artifact for the Art Archive adding the appropriate author credits.
- Art Archive Artifact created
- Shared SourceCred Art Archive Google Drive folder TBD
There’s an Initiative for this in play so I’ll just link to that here: