Project management

This article documents the project management process used within the Bisq DAO.

Purpose

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.

Philosophy

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

Non-examples include:

• 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

Project owner

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

Team leads

@bisq-network/team-leads are responsible for prioritizing accepted projects by allocating budget to them.

Contributors

Contributors are responsible for performing the tasks necessary to deliver a project.

Resources

Projects repository

Projects are managed as GitHub Issues at https://github.com/bisq-network/projects/issues. The issue template there defines what a well-formed project proposal should include.

Project boards

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.

Process

Overview

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.

Proposal

To create a well-formed project proposal:

1. Create a new issue in the projects repository
2. Choose the Project proposal issue template
3. 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:proposal and needs:triage.

Triage

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 needs:triage label,
• add the needs:approval label and
• add a corresponding comment.

If a proposal is not well-formed, the triager will:

• add the needs:info label and a comment asking the submitter to provide the missing information, or
• add the was:invalid label and close the issue immediately with a corresponding comment.

Approval

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 contention.

Once consensus has been achieved, a member of the project management committee will:

• remove the a:proposal and needs:approval labels
• add the has:approval or was:rejected label as appropriate
• add a comment indicating the status change
• close the issue if rejected

Budgeting

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

Starting work

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 is:blocked or is:stalled.

Stopping work

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.

Requesting help

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.

Review

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.

Closure

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.

Compensation

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.