[bisq-network/proposals] Implement budgeting and improve reporting (#158)

Sat Dec 21 23:58:56 UTC 2019

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

Bisq's current contribution dynamic is a free-for-all with almost no constraints and almost no analysis. 

This worked well while the contributor group was relatively small, since the work required roughly matched with the labor supply—people could do almost whatever they wanted and it was sufficiently productive.

But as the project has grown and matured, imbalances have emerged:

* certain functions are **under-allotted** (work required exceeds that available from the labor supply)
* certain functions are **over-allotted** (labor supply exceeds that of work required)

What is the correct allocation for each function? What is an acceptable level of overall spending for a cycle? Was the drastic inflation in the last cycle warranted? No one knows, because the project lacks micro-level goals/budgeting and macro-level analysis.

This proposal suggests an approach to accomplish this with the following aims:

* maintain the decentralized spirit of the Bisq contribution model
* **adapt** existing processes people are already accustomed to (e.g., compensation requests and monthly role reports)
* avoid using third-party infrastructure and dependencies that probably aren't a good fit for Bisq anyway (e.g., project management tools)
* avoid the hell that is middle-management and paper-pushing (avoid busywork and crap incentive structures)

It was inspired in part by julianknutsen's [proposal from earlier](https://github.com/bisq-network/proposals/issues/150) and conversations with other contributors.

## Concept

I suggest the following:

1. Establish network-level budgets and goals, and update every cycle.
  * What is the **maximum amount of BSQ** the network should issue in the next cycle, based on how much BSQ was burned in the last cycle? Trading volume is too volatile to make projections so these figures probably need to be backward-looking for now.
  * What are the **overall goals of the project** in the near-term, mid-term, and long-term? These may not change a whole lot from cycle to cycle, but project-wide goals should be clearly stated and easy to find.
2. Establish per-function budgets and goals, and update every cycle.
  * What is the **maximum amount of BSQ** the network should issue for each function in the next cycle, as a percentage of (1)?
  * what are the **most pressing tasks** within this function?
3. Aggregate past contributions, per cycle, separated by function, to show spending over time.
  * Would be great to connect spending data (_inputs_) with practical results (i.e., _outputs_ like software downloads, trade volume, etc) to determine ROI...but that's a much more complicated task that will need more thought and time to implement.

All this information should be collected and visualized for contributors and maintainers to refer to whenever needed, so that:

* maintainers can better route energy to critical work, or discourage energy going into less-critical work
* contributors can determine how to be helpful quickly without guesswork
* stakeholders have a basis for rejecting requests to compensate non-critical work
* the whole network can better control inflation

## Implementation

I don't think we need dramatic change to implement this. The following suggestions might seem janky, but we don't need a solution that's scalable to 1000 active contributors...just one that works for a couple dozen active contributors and role owners. There's no need to overengineer or overthink it.

The basic idea involves establishing budgets through quick meetings every cycle, standardizing compensation requests and role reports so they can be parsed, and aggregating all data on a single page for convenient access.

Concretely:

1. **Establish stewards for major Bisq functions**. These would be people who can best represent the interests of each significant function. So there could be one for the website, one for infrastructure, maybe two for development, etc. These would not be official roles, could be rotated among different people, and the people would have no real authority aside from participating in (2). 

_No additional work...just pick someone._

2. **Hold meetings every cycle so stewards can establish budgets and allocations**. Stewards should determine maximum BSQ issuance for the upcoming cycle, set allocations for their functions, and adjust project goals as necessary. Only stewards would participate but anyone could watch. These numbers could go into a simple JSON file that lives in the website repository, so it can be accessed by (5).

_Should not take more than 30 minutes per cycle._

3. **Standardize compensation request format**. So that they can be parsed and aggregated programatically for detailed issuance information over time. Everyone making a compensation request already separates their items by function, so this isn't a big leap. A linter could alert people of malformed requests.

_No additional work...just require a more uniform format for what we're already doing._

4. **Standardize role report format and add budget/goal information**. So that they can be parsed and aggregated programatically for per-function analysis over time. Budget information would come from (2). Role owner would specify goals. As for analysis, how did the function do in the last cycle relative to previous goals and budget? Overspend? Underspend? Was it productive?

_Again, this is more about applying a uniform format. Good role reports already do most of this._

5. **Collect and visualize information from (2), (3), and (4)**. With all issuance data and role reporting in standardized format, we could aggregate all project/function budget targets, project/function goals, reports, and analysis onto a single page every cycle. Perhaps it could be the new bisq.network/stats page.

_Write a script and design a new web page._

## Results

1. By looking at one page, anyone could see how the network did relative to its targets in the past, and what its targets are for the current cycle. New contributors could see all the major functional goals on one page, get an idea of where the highest-priority needs are, and see what the corresponding budget for them are.

2. Role reports will allow existing contributors and stakeholders to better see if the function is living up to its goals and budgets, giving them better grounds for replacing under-performing role-owners Right now there isn't much of a basis to get rid of someone other than prolonged absence or malicious activity. That might be a problem.

The practical ongoing work required to make this happen is almost nothing: just one quick meeting per cycle, and a little more effort into writing role reports.

## Ancillary Results

1. I think having stewards for major functions would give the project the nudge of leadership it needs to prevent stagnation without establishing "bosses". Budgets and goals could serve as guidelines to provide rudimentary management in place of human managers.

2. Having budgets would help pave the path for work with non-obvious, non-immediate results. Creating thoughtful blog posts and social content, for example, or even providing support—these are jobs that take a lot of time but don't have obvious results in the short-term. They're not compensated well (or at all) by the existing compensation conventions. We'd have to fine-tune the process to discourage complacency, but that's a separate challenge and a separate discussion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/158
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191221/c4779c5c/attachment.html>