Skip to main content

Ritual of Ranks

Living Governance Document

The DAO Masons rulebook is a living document that may change significantly in response to internal governance.

Do you see a way these docs could improve? Click the Give feedback button at the top of this document or join the DAO Masons Discord to let us know.

Essence​

Ritual of Ranks is how we keep track of member accomplishments. We primarily track completed projects, awarding a badge for the roles that were filled during the Project.

At the beginning of a project (proposal phase), we create outlines for each role needed for the project. When the project is over, the Project Lead mints/records (spreadsheet for now, eventually through SBTs) the role as a badge. This works as an internal reputation system for DAO Masons and could be tied to compensation in the future. For instance, a proposal could be made to award Loot Shares to past Project Leads or role fillers for particularly successful projects.

Current Implementation​

We are currently in the unimplemented/manual stage for this ritual. We are currently using a spreadsheet to keep track of all the roles that each member has filled, as well as some other useful metrics.

  • Project Worked
  • Time Spent on project
  • Value Level avg of project(if there was a rubric used in a Ritual of Light system for that project. If not then it's a mid-level 3)

Why?​

In order for Project Leads to make informed decisions about their team during the selection process, it might be helpful to have some sort of information about how many projects each member has completed, and how many they have completed under a certain role.

For example, if a Project Leads is looking for a designer, it would useful to have some sort of resource to identify who has done the most design work within the DAO.

What problem are we solving​

  • We sometimes don't know who to choose for a project
  • Team selection is opaque, can sometime create tensions without an objective selection metric.
  • Without clear divisions of labour, we risk conflicts and redundant work.
  • As projects close, we lose track of who made which contributions.

Why is this a good solution​

  • Helps inventory skills within the DAO and helps team leads make informed decisions
  • Creates a clear division of labour during production
  • Can provide transparency over why certain DAO members are selected over others.
  • Creates an additional non-financial reward for Contributors

Downsides/Risks​

  • Not purely objective.
  • Some projects are longer than others
  • Some projects are harder than others
  • Some roles are more difficult.
  • Some people may work longer than others and still recieve only 1 token.
  • It's hard to distill all the extra things we do down to one role, and people may feel that the times when they went 'above and beyond' were not recognized.

Mitigation: Perhaps a system where we add a score value into the metadata of a token will be able to solve these problems. However, we will need a system to aggregate that score from a variety of metrics.

Roadmap​

Next Step​

Try recording the aforementioned metrics for some projects and see if it's useful. Try calculating scores for overall contributions as well as for each job-type (ex. designer, developer, etc.)

If we feel the data is useful, then we should begin to work on a way to automate the input of this data to reduce the overall time a team lead spends on this ritual.

Endgame​

We need to understand more about the use-case about the data that we are collecting before migrating to a tokenomic system.

To encourage widespread adoption, it's crucial to minimize friction for team leads when using the system and ensure that the data they need is easily accessible.

Once those barriers are effectively mitigated, we should move to a fully on-chain system that automates this process once a project is completed or has reached its review period. This system should include all relevant metrics in the token metadata and should be easily queryable.

Details​

Further reading:

Boiler(Chris) has spent a good amount of time thinking about this system and has a lot of ideas about how to implement it.

Current Stage of Development​
  • Unimplemented
  • Manual
  • Systemetized
  • Partially Automated
  • Fully Automated/Passive

Current State of This Page​

  • Empty
  • Rough Draft
  • Editing passes: 0
  • Final Draft
  • Ratified