Establish project management process

[cbeams]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

At the time of this writing, an effort to establish a project management process for the Bisq DAO has been underway for a couple months. It is now in good enough shape to make a proper decision to adopt it, thus the creation of this proposal.

In reality, we've already been managing a number of projects under this process. The experience has produced a lot of real-world feedback, and the process has been refined in response to it.

The process is documented at https://bisq.wiki/Project_management. Please read it and provide feedback here as usual in the form of comments and emoji reactions. I do not intend to put this proposal through a formal DAO vote unless there is a clear need to do so. The intention here is to get broad awareness of the effort and a rough consensus to go forward with it.

As a convenience, I've also created a brief screencast that goes over the most important parts of the process. It is available within the Bisq Keybase team at keybase://team/bisq/2020-03-06%20Project%20management%20process%20screencast/zoom_0.mp4.

See also bisq-network/projects#1, the project to establish this project management process.

[m52go]

How would this workflow affect this repository (proposals)? I believe you indicated on the screencast that it makes sense to continue using it for clear-cut items like parameter changes, but would it be acceptable to continue using this repository to gauge interest in less well-developed ideas, perhaps as a preliminary indicator of whether composing a project proposal is warranted?

In general I think the proposals repository is often a medium for thoughtful exchange, and although it might be more messy and less actionable overall, it could complement projects well.

[cbeams]

@m52go wrote:

How would this workflow affect this repository (proposals)?

For reference, this is what I wrote about it in the description of bisq-network/projects#1:

Projects are related to, but distinct from Proposals. Proposals have become overused and in many cases, even when approved formally or informally, are effectively unimplementable or otherwise unmanageable because they do not define work and outcomes in enough detail. Going forward, proposals will continue to serve their function as a decision making mechanism within the DAO, but projects will be the favored approach to managing efforts that require tasks, resources and time to accomplish.

... back to what @m52go wrote:

I believe you indicated on the screencast that it makes sense to continue using it for clear-cut items like parameter changes, but would it be acceptable to continue using this repository to gauge interest in less well-developed ideas, perhaps as a preliminary indicator of whether composing a project proposal is warranted?

Indeed. If we look at the current set of open proposals, I would say they fall broadly into two categories:

1. ideas looking for interest and feedback
2. concrete, immediately implementable proposals that need consensus

We could label issues that fall into the first category as an:idea to make it clear that they are not (yet) an actionable proposal; that what's needed is interest, feedback and discussion. As a result of that feedback, such issues might later become projects, for example.

With regard to the second category, it seems like most concrete proposals are either regarding parameter changes (e.g. reducing maker fees) or changes regarding roles (e.g. promoting a support intern to L1, putting up a bond).

In general I think the proposals repository is often a medium for thoughtful exchange, and although it might be more messy and less actionable overall, it could complement projects well.

Agreed. I think it would go a long way to simply introduce the an:idea label and make it clear that ideas with a lot of interest can move on to being fleshed out as a project proposal if appropriate. This should make it cheap and easy to "just bring something up" without having to go through a lot of effort to spec it out, make a case for it, etc. I think we can also have these sorts of conversation in GitHub discussions, but the proposals repository is already well-established, so let's carry on there with a clear distinction between projects, proposals and ideas.

To get the ball rolling, we can retroactively apply the an:idea label to existing open proposals that seem to fit that category. It's an open question what should be done with idea issues that run out of steam, i.e. when they should be closed, etc. If an idea "becomes" a project, it would be closed as superseded by that new project proposal issue. In any case, this is all stuff that can and should be written down in the https://bisq.wiki/Proposals process documentation as it becomes clear.

[m52go]

Sounds good. As a practical matter, I like the idea of keeping discussions for ideas here, since there's already a corpus of searchable history and interconnectedness that I think would be valuable to continue building.

[cbeams]

This proposal has been out here for a while, and I'd like to see about getting it approved and built-in to how we work. A number of folks have begun engaging with the process already (@freimair, @dmos62, @wiz), but what's missing is the review process. I originally wrote the following at https://bisq.wiki/Project_management#Review:

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.

I'm thinking twice about this now. This bi-weekly call hasn't come together primarily due to time constraints, and may simply be too much to ask at this point / not worth the overhead. I'm open to the idea that we try to manage things as asynchronously as possible through comments, much as we do with the existing proposals repository. Perhaps a once-a-month project review meeting would be a better fit. Feedback welcome.

In any case, if you're for managing projects as has been laid out in the documentation linked above, please give this proposal a 👍 and provide any additional comments you may have. Thanks.

[freimair]

imho, the bi-weekly review is the most important thing in the process. That is the very mechanism to keep up interest and focus on ongoing projects. Not sure if it is necessary to have a general call though. Maybe one-on-one's for now? Or just reports + call on demand?

[dmos62]

I'll share a few impressions of the new project management process. Overall I think it's great.

The Master Projects Board let's me see what's happening currently on the level of projects in DAO. What people are paying attention to, what's been deffered, etc. These bigger picture features easily get lost in the ephemerality of Keybase or even the main issues thread, so I find it valuable to have this overview.

Further, the new project proposal template is a big improvement. I've recently put together a proposal (as in the old kind), but then remembered about the new project proposals (this) and rewrote it to suit the project proposal template. Importantly I had to think about things that the looser structure of the old proposals let me ignore, like criteria for delivery or measures of success. The structure improves discussions: you can refer to an element of the template saying "you didn't explain why the project should be done now" or "your measures of success are underdefined". Smoother discussions and definitions will go a way to make implementations smoother as well, I think.

Edit:

Concerning bi-weekly calls, I'm in favour. I'd probably find the calls useful as sanity checks and I like the idea of scheduled status exchanges generally. A bi-weekly report on the project's github issue thread would work as well for me. It would have some advantages over a call (disadvantage too though).

[freimair]

amendment to my previous comment:

Having regular reviews is also very important to review project proposals and decide on them.

• Having a mandatory headline "Why now?" and a creation date "4 Weeks ago" does not go together well.
• Also, not deciding on (or at least discussing) such proposals leads to no movement at all. And by design, these projects are about something bigger than gui changes, they kind of shape the mid and long-term future of Bisq. Granted, they might not be as easy to decide on as a gui change, but not deciding on them results in Bisq getting stuck (again).

So in order to keep Bisq "moving", I would suggest a bi-weekly call to discuss the proposals.

[cbeams]

Closing as approved; this proposal has remained open for quite a while, and at the time of this writing has 9 upvotes and no downvotes. It never went to a DAO vote, as it appears unneccesary to do so.

Thanks all for the feedback around bi-weekly reviews. It's clear that folks find doing them to be of value, and all that remains is to implement it. I believe we have a nice opportunity to use the newly-proposed regular Bisq dev calls (#231). It is not yet clear whether those calls will be weekly or bi-weekly (every two weeks), but in any case, they may be just the right place to do project reviews, i.e. to let the master projects board drive much of the agenda for those calls. I'll comment more fully on this on proposal #231 and bisq-network/projects#1.

[wiz]

Great work on establishing this new project management process.

However, one critical thing that seems to be missing is the election or process for how we will decide who gets to be on the Project Management Committee - obviously no projects can be "approved" until we fill the committee.

I suppose we could just make DAO proposals to nominate people like we do with the other "election" process for team leads, or perhaps we could make a proposal to have all team leads make up the Project Management Committee...

[cbeams]

Thanks, @wiz. As discussed in our team leads chat and most recent weekly call, I think it probably makes sense to rename @bisq-network/pmc to @bisq-network/projects-maintainer and treat it as a normal rules-based maintainer role, i.e. where the job is straightforward an non- or minimally-subjective: do triage on new projects to ensure well-formedness, mark project issues as approved or rejected based on feedback, etc. This can be a single-owner role, and all other, more subjective decision making like prioritization can happen as a function of the dev calls and the process around them. Budget allocation has to be worked in too, but that would remain the domain of the team leads as it already is.

The projects maintainer role duties would/should also include maintaining the process itself, i.e. keeping the docs up to date, working with contributors and team leads to make sure the process is working well. It's an important role that we need someone well suited to take on. It's not obvious to me who that should be, but in the meantime, the process is at risk if that role isn't filled. It can easily become an "everybody owns it, so nobody owns it" kind of thing. I'd just keep moving forward on the dev calls and getting that in order and make it known that we're looking for someone to own the project management process and be its maintainer.