This article documents the project management process used within the Bisq DAO.
- 1 Purpose
- 2 Philosophy
- 3 Roles and teams
- 4 Resources
- 5 Process
The purpose of the project management process is to ensure we:
- work on what's most important,
- finish what we start,
- stay within our budget, and
- don't spread ourselves too thin.
Most work is project work
Many efforts under the Bisq DAO require multiple tasks to be carried out by multiple contributors, possibly across multiple teams and a span of time. Such efforts are best managed as projects having a beginning and an end, with clear criteria for delivery and a strong owner who takes responsibility for its success.
Identifying candidate projects
Good examples of candidate projects include:
- Adding a new feature or making a major enhancement to the Bisq client
- Introducing a new process within the Bisq DAO or significantly changing an existing one
- Typo fixes
- Minor enhancements and bug fixes
- Carrying out the regular duties of a given role
It is ultimately a judgement call whether a given effort should be managed as a project. Here are a few rules of thumb:
- Does it require multiple tasks? It's probably a project.
- Does it require people other than yourself to take action? It's probably a project.
- Does it require documentation and/or promotion to make sure people know about it? It's probably a project.
Work that starts out as a single task may evolve to become a project, and that's fine. But by thinking ahead a little, we can often identify projects up front and better manage them as a result.
Good project management scales
A primary goal of the project management process is to help the DAO scale. We want many contributors collaborating on many efforts in parallel with minimal management. To achieve this, the process must have a bottom-up aspect in which any contributor can propose a project and any stakeholder can participate in approving it, and it must also have a top-down aspect for allocating budget to the most important projects. The approach laid out here is designed to strike that balance.
Roles and teams
A project owner:
- is responsible for the delivery of a given project
- is usually the same contributor that proposes the project
- attends review meetings and reports on the project(s) they are responsible for
Stakeholders and users
DAO stakeholders and Bisq users are responsible for providing approval feedback on project proposals.
Project management committee
The @bisq-network/pmc is responsible for the overall project management process, including:
- triaging new project proposals
- accepting or rejecting proposals per stakeholder approval
- leading project review calls
@bisq-network/team-leads are responsible for prioritizing accepted projects by allocating budget to them.
Contributors are responsible for performing the tasks necessary to deliver a project.
An approved project may have its own dedicated project board at https://github.com/orgs/bisq-network/projects for the purpose of tracking individual tasks. Otherwise, tasks may be tracked as simple checkboxes in the project issue description or by whatever means the project owner sees fit (e.g. an external kanban board); in general, however, it is preferred that everything is managed within GitHub Issues.
Master projects board
The master projects board is available at https://github.com/orgs/bisq-network/projects/3 and provides an overview of all projects and their status.
Anyone may propose a project so long as they are prepared to own it. Each new proposal goes through triage and, if well-formed, moves on to stakeholder approval where it is accepted or rejected on its merits. An accepted project is allocated budget according to its priority and is subject to regular review until the project is closed as delivered or aborted.
To create a well-formed project proposal:
- Create a new issue in the projects repository
- Choose the
Project proposalissue template
- Adhere to the format of the template and fill out its content according to the instructions within
New project proposal issues are automatically labeled as
A member of the project management committee will add each new project proposal to the
Backlog column of the master projects board and assess whether it is well-formed according to the issue template.
If a proposal is well-formed, the triager will:
- remove the
- add the
- add a corresponding comment.
If a proposal is not well-formed, the triager will:
- add the
needs:infolabel and a comment asking the submitter to provide the missing information, or
- add the
was:invalidlabel and close the issue immediately with a corresponding comment.
Like any DAO proposal, anyone may add comments providing feedback on a project proposal and may react to the proposal issue description with thumbs-up, thumbs-down or confused face emoji to indicate whether they believe the project should be approved. The goal is to arrive at a rough consensus whether to approve the project. Taking a project proposal through formal stakeholder voting should be avoided unless there is significant unresolved contention.
Once consensus has been achieved, a member of the project management committee will:
- remove the
- add the
was:rejectedlabel as appropriate
- add a comment indicating the status change
- close the issue if rejected
Acceptance of a project is distinct from allocating budget to it. Acceptance indicates that a project is worth doing; allocating budget indicates that a project has priority. Team leads are responsible for reviewing accepted projects and adding the
has:budget label when budget has been allocated.
Work may be started at any time on a project, even prior to approval and budgeting, but contributors should have no expectation of cooperation or compensation until the project has both.
In any case, when work starts, the project owner should move the project to the
In progress column of the master projects board and add a corresponding comment.
If work is being resumed after a period of inactivity, the project owner should also remove any labels such as
When work stops for an extended period the project owner should move the project issue to the
Backlog column with a corresponding comment. If the project is blocked in some way, the
is:blocked label should be applied. If work has stalled due to inactivity, the
is:stalled label should be applied.
If a project cannot progress because a certain skill set is not available within the current team of contributors, the project owner should add the
needs:help label with a corresponding comment that explains what kind of help is needed.
UPDATE: These bi-weekly calls may not be the way to go. We might end up doing things more asynchronously through issue comments and perhaps a once-a-month project review call. See https://github.com/bisq-network/proposals/issues/182#issuecomment-621167017 for ongoing discussion.
Approved projects are subject to a bi-weekly (once every two weeks) review call in which each project owner provides a brief summary of their project, including whether it is on or off track, blocked for any reason, at risk of exceeding its scope or budget, etc. See the events calendar for details.
Closing as delivered
Projects that meet their criteria for delivery will be closed with the
was:delivered label and a corresponding comment.
Closing as aborted
Projects may be aborted prior to delivery for a variety of reasons, including abandonment by project owner, consensus that the effort is no longer worth pursuing, exceeding allocated budget, being blocked by external factors, and so forth. Such projects will be closed with the
was:aborted label and a corresponding comment.
Closing as deferred
Projects that are blocked or stalled for an extended period of time may be closed with the
was:deferred label and a corresponding comment. Deferral is appropriate if the project is something that we'd still like to do, but see no near-term path to actually working on. A deferred project may be reopened when it becomes feasible to work on it, but any prior budget allocation should be assumed invalid.
Closing as superseded
Projects may be closed with the
was:superseded label when another project becomes a more appropriate vehicle for getting the same or similar work done. When closing, a comment should be added providing a link to the superseding project.
Ideally, compensation should be requested after a project has been closed, but this is not always practical. A contributor may request compensation for work on a given project prior to that project's closure assuming that the work in question has itself been meaningfully delivered. For example, if a Growth Team project involves creating and publishing an instructional video, the video creator may request compensation for their work assuming the video has been published and promoted to its intended audience even if the larger growth project is still in progress.