SUPERALGOS PROJECT
Planning the November 2021 Superalgos (SA) Token Distribution
Governance process schedule, about maintainers and teams, governance definitions, and proof of work reports.
The next distribution event is almost here. The governance process keeps evolving with lessons learned from past events. We’ll review some of the changes and the workings of the upcoming event.
Bootstrapping the Market
But before we start, there’s an important reminder I need to deliver first.
As explained in my post about Bootstrapping the Market for the Superalgos (SA) Token last month, the community is making significant financial efforts to bootstrap the liquidity pools in PancakeSwap.
An open group of community members has added liquidity to these pools from their own pockets. Remember, the project does not sell tokens and does not have a budget in any asset other than the Superalgos token.
The community must be very careful about how tokens are distributed during the bootstrapping phase. We do not want people cashing out their tokens too early!
Because there have been a few untimely and damaging cash-outs already, the community is wary about distributing generous incentives among newcomers at this stage.
If you are a new contributor or have a new User Profile ready to start participating in governance, please make sure you read the original post. We need you to be on the same page as the rest of the community!
Governance Process Schedule
Governance is a process. It starts with the publishing of Teams’ Proof of Work Reports and culminates with the distribution event. The process is carried out in stages, so that different actions may be performed in a logical order that makes the distribution easier to understand, more predictable, and fairer.
You are expected to submit your profile with each type of vote by the corresponding dates on the schedule. The community-wide agreement is to not modify each type of vote after each of the corresponding deadlines.
The schedule is an experiment attempting to fix issues experienced in previous sessions. If it works out well, it may be enforced systematically in the future.
Nov 30th — Closing the Workspace With Existing Profiles
The last day of the month is the last day available for incorporating new User Profiles into the Token Distribution Superalgos workspace. New User Profiles submitted after Nov 30th 23:59:59 UTC will be accepted in the repository, but will not make it to the Workspace. Profiles that don’t make it into the workspace may participate in the distribution event corresponding to the following month, but not the one closing.
If you haven’t created and submitted your profile, you have until tomorrow!
Dec 1st — Proof of Work (POW) Reports
The deadline for publishing POW Reports is the end of the first day of the month, that is, December 1st 23:59:59 UTC. Find more on these reports further down this post.
Dec 2nd — Weight Votes on Pools
On the second day of the month, the community places Weight Votes on the Pools hierarchy. This is the first stage of the voting process. This is when the community decides how to distribute token rewards among the different distribution pools.
During the same day, and after the POW Reports are published, the Positions hierarchy is updated to reflect the existing teams.
Dec 3rd — Weight Votes on Positions
On the third day of the month, the community places Weight Votes on the Positions hierarchy. This is the second stage of the voting process when the community decides how to reward each of the teams.
Dec 4th — Contribution Claims
On the fourth day of the month, contributors place their claims on the positions defined within the teams each contributor may have worked with, according to the POW reports.
Dec 5th — Claim Votes
On the fifth day of the month, the community votes for the claims placed by contributors. This is the final stage of the voting process.
Dec 6th — Anomalies Revision & Complaints
The sixth day of the month is reserved for the community to review the distribution logic as expressed by the final voting the day before. In case severe anomalies are reported, we may need to make adjustments, or allow for individual profiles to be updated.
This is not meant to offer an opportunity for the community to fine-tune or improve their profiles. Only grave issues will be dealt with.
Dec 7th — Distribution Event
The seventh day of the month is the day the distribution process is executed.
About Maintainers and Teams
Let’s clarify and disambiguate some of the aspects of the workings of teams and projects as defined in the Multi-Project Roadmap post by Luis Fernando Molina and my own How to Contribute to Superalgos post. The following considerations supersede the notions proposed on those earlier posts, which will soon be amended accordingly, as part of the regular maintenance of onboarding tools.
Maintainers
The codebase is divided into multiple projects, and each project may have maintainers. The concept of maintainers with responsibility for certain projects, or even individual assets, for instance, the README file in the repository, is not to be confused with the concept of Teams.
Maintainers are high-reputation members of the community who take responsibility for sensitive aspects of the collaboration, like merging code and reviewing pull requests. These are people that, through their long-term involvement with the project and valuable contributions in specific domains, have earned the trust of the community to perform these kinds of sensitive tasks.
Teams
Teams are groups of contributors freely associating to collectively present their work to the community. The concept of team is therefore related to the governance dimension of the collaboration.
Contributors may spontaneously decide to form teams when they feel that associating with other contributors may foster synergies, or be rewarding in whatever manner. Superalgos is a community-centric project, and being able to freely choose who to work with is a crucial aspect of the social fabric we wish to develop for the project.
A horizontal organization of autonomous teams contributes to the scalability of the collaboration. Members may freely decide how to organize the team (for instance, in a flat collaboration among equals, in hierarchies of any sort, etc.), how to recruit new members, and how to distribute the token rewards allocated to the team via the governance process.
Governance Definitions
The Positions hierarchy within the Token Distribution Superalgos workspace features the definitions for each of the teams that presented proof of work reports for any given distribution period.
By default, a single position for Team Members is defined. This is in line with the attempt to simplify the governance process.
Under the default definitions with a single position for Team Members specified within each team, the community is expected to place Weight Votes on a single position per team, and team members are expected to place claims on that single position.
In a scenario with hundreds of contributors and tens or even hundreds of teams, no community member will be able to track the work of all teams, let alone the work of individual members within teams. Instead, community members will tend to track the work of teams that work in areas of the project that they may be particularly interested in.
That is why simplifying definitions is important!
We shouldn’t expect the average community member to vote for the claims of individual contributors. The most likely scenario is that it will be team members within each team voting for each other’s claims. In a way, this is a natural outcome of the free association implied in the formation of teams: team members will likely agree on how to distribute the tokens awarded to the teams, and vote for each other claims accordingly.
If a team is not able to agree on how to distribute token rewards among team members, then members should consider parting ways, joining other teams, or maybe forming their own for the next governance period.
Custom Position Definitions
If a team wishes, for whatever reasons, to have more elaborate position definitions of the team structure in the governance workspace, the team should send the structure of nodes to @luis_fernando_molina by the first day of the month.
No Features or Assets Definitions
For the time being, we will not be using definitions of assets and features. Contributions of any sort should be incorporated in the POW Report of the team and claims placed on positions only.
Proof of Work Reports
Teams must present a POW Report to the community before the voting starts so that everyone is aware of the value that has been added to the project by the different teams, and so that the community may make informed decisions as to how to distribute rewards.
Let’s take a minute to analyze what is the best approach to writing these reports.
The first thing to consider is that we will — eventually — have many different reports from many different teams. Brevity is a desirable attribute so that the more engaged community members may afford the luxury to read as many reports as possible, if not all.
Please be concise and go straight to the point.
Teams on a mission are highly inspiring. Make sure you give your team a meaningful purpose and use your proof of work reports to show the community how you have advanced in the desired direction.
People will want to learn about the value added to the project during the corresponding governance period. What happened in the previous period or what may happen in the next one is not relevant.
Only work that has already been merged in the development branch should be mentioned. If the work hasn’t reached the repository yet, then leave that for the next governance period. The same goes for work that doesn’t involve code or assets that go in the repository, for instance, marketing or business development work: only mention work that has produced tangible, measurable results. If your work is still in progress and hasn’t realized any tangible outcome yet, then leave it for the next period too.
Partial work that is already implemented may be claimed in the current governance period if it’s ready for people to engage with it, at least to try, test, or verify the work has been done.
If your team is small, very focused on a narrow scope, or has taken care of a few “things”, a simple bullet point list of achievements may be sufficient.
If your team is large, covers many different project areas, or has done lots of work, a post with one main title for each area of work may be necessary.
Assume that people reading the report don’t know what you’re talking about. Adding a little context may help. Also, feel free to “sell” why your work is important and how it helps the community, users, or whatever stakeholder may benefit from it. If appropriate, include a brief note explaining how people may use, try or experiment with the new feature.
POW Report Format
Let’s make my work easier by delivering a finished post, with few if any editing requirements. We need to make the presentation of the post beautiful; something people will want to engage with!
You may take the Devs Team Proof of Work, October 2021 post as a model.
We will standardize the format of the header.
Kicker
SUPERALGOS GOVERNANCE
To add a kicker, place the cursor before the first letter of the title, hit Enter, write the kicker SUPERALGOS GOVERNANCE (all caps), and format it with the T2 (title 2) style. When you do, Medium turns the line into a kicker.
Title
[teamName] + “Proof of Work,” + [month] + [year]
Example: Education Team Proof of Work, November 2021
Subtitle
Succinctly enumerate the topics covered in the post.
Example: Project extractions, governance simplification, bug fixes, improvements on data-mining infrastructure, new packaged application.
To write a subtitle, place the cursor after the last letter of the title, hit Enter, write the subtitle and apply the T2 style. Medium will turn the paragraph into a subtitle.
Illustration
Immediately after the subtitle, add a cool picture to illustrate your post. You may find royalty-free images on unsplash.com
Title Case
Please use a consistent title case format on all internal headings and the main title of the post. Different publications have different style guides and may follow slightly different criteria. We won’t get into the specifics, but lets at least be consistent throughout the post.
Example: This is Proper Title Case for Headings and Title
New Contributors
If you are a new contributor and have been producing valuable work during this governance period, you will need the support of a Team to delegate you some Token Power and help you bootstrap your first few claims.
Joining a team while starting contributing to the project is highly desirable.
That is how you present your credentials to reputable members of the community. This mechanism is a natural anti-spam, anti-scam filter — a feature of the collaboration that makes us stronger and more resilient.
Join the Superalgos Token Telegram Group
During the governance process, the community may participate, discuss, and ask questions in the Superalgos Token Telegram Group.
Let’s talk governance!
