Roles are the way contributors take responsibility for Bisq network resources and processes.
- 1 Background
- 2 Properties
- 3 Infrastructure
- 4 Types
- 5 Common duties
- 6 Bonding
- 7 Processes
There are many resources and processes vital to the operation of the Bisq Network that require ownership by individual contributors. For example, someone must merge pull requests into the
bisq repository, someone must manage DNS for the
bisq.network domain, a group of people must maintain critical infrastructure such as seed nodes and price nodes, etc.
This document defines the system of roles used within the Bisq DAO to enumerate, define and track each of these responsibilities. The system is designed with two major goals in mind:
- To maximize role owner autonomy in order to achieve Bisq's decentralization goals
- To maximize transparency so that DAO stakeholders can effectively review and vote on role owner compensation requests
The following are properties common to all roles.
Duties are actions that must be performed for a certain resource or process to function normally.
For example, a repository maintainer’s duties include merging pull requests in a timely fashion, and a website operator’s duties include keeping the site available at all times.
Rights are special permissions or other access required to perform the Duties of a role.
For example, a repository maintainer’s rights include write permissions to their repository, and a website operator’s rights include administrative access to site hosting infrastructure.
Owners are contributors who have the Rights required to perform the Duties of a role.
One owner is designated as primary and any other owners are designated as secondary. The primary is responsible for performing the Duties of the role, while secondaries stand by, ready to take over for the primary at any time.
The following infrastructure is used to define and manage each role.
Each role should be documented here on https://bisq.wiki in a document of its own, ideally linked to the larger resource or process it's related to.
Each role’s documentation should specify the role's:
- GitHub team
- GitHub issue
- bonding requirement (if any)
Each role has a dedicated GitHub team where each of the role’s Owners are members. The team is used to manage access to GitHub repositories that the role is responsible for and to send notifications to role owners with @mentions in GitHub issues and pull requests.
|GitHub teams are visible only to GitHub organization members. To join the @bisq-network org, see the contributor checklist.|
The primary role owner is also assigned as the maintainer of their role’s GitHub team, such that they may manage the team without requiring the intervention of a GitHub admin.
Each role has a dedicated GitHub issue in the bisq-network/roles repository, wherein:
- The Assignees field is used to track role ownership.
- The Description field is used to link to the role’s wiki article, team, and primary owner.
- Comments are used for reporting and feedback.
See the [Compensation Maintainer https://github.com/bisq-network/roles/issues/86] role issue for an example.
Most roles fit into one of the types below.
A Maintainer is a contributor responsible for enforcing process in a given GitHub repository.
- Merging or closing pull requests after sufficient review
- Tagging releases
- Triaging incoming issues and keeping them organized over time
A maintainer is not a developer or reviewer.
Submitting and reviewing pull requests is something any contributor can do; neither are maintainer duties per se.
This is particularly important from a compensation perspective. If you are a maintainer, do NOT group your development and review activities together with your maintainer role in your compensation requests. Rather, account for them separately like any other contributor would.
The goal is to have as many competent contributors developing and reviewing as possible, not to load everything on the maintainer. C4 is the inspiration here—it’s worth (re-)reading.
- Write access to the repository they are responsible for
An Operator is a contributor responsible for keeping a given resource running and functioning normally.
- Keep the given resource online and functioning normally
- Keep the resource up to date with latest version
- Maintain backups as appropriate
- Report on any incidents
- Administrative access to hosting infrastructure
- Ownership of any domain name used
An Administrator (often referred to as 'Admin') is a contributor responsible for managing a given resource.
- Respond to change requests
- Access to the administrative interface of the resource in question
The following duties are common to all roles.
Primary role owners should report once a cycle in the form of a comment on their issue. The report should contain whatever information the role owner believes would be valuable to other users, contributors, and stakeholders.
The comment should be formatted in Markdown as follows:
## Cycle 21 Report Description and/or list of contributions, accomplishments, or other notable occurrences since the last role report was posted. /cc bisq-network/compensation#421
/cc part should reference the GitHub issue for the contributor's compensation request for the cycle corresponding to the role report.
Most roles involve special rights that, if abused, could cause damage to the Bisq Network. For this reason, role owners must put up a bond in BSQ commensurate with the amount of damage that could be caused. In the event of a role owner turning into a bad actor or being grossly negligent, this bond can be confiscated through a Bisq DAO proposal for confiscating a bond.
The following are some common roles-related processes.
Proposing a new role
Typically, proposing a new role is one part of a larger proposal to introduce some new resource or process.
- Discuss the idea informally with other contributors, e.g. via Keybase
- Follow the proposals process to formally suggest the new resource or process
- Draft documentation for the new resource or process, including an article about the new role as a wiki article
Adding a secondary role owner
A primary role owner may add a secondary owner with the following steps:
- Add them as a member of the role’s GitHub Team.
- Add them as an assignee to role’s GitHub Issue.
- Announce the change via a comment on the role’s GitHub Issue.
Transferring role ownership
A role owner may transfer ownership to another with the following steps:
- Get the new contributor added to the role’s GitHub team.
- Get the old contributor removed from the role's GitHub team.
- Have the role’s GitHub issue updated to reflect the new primary owner.
- Announce the change in a comment on the role’s GitHub Issue.