> _This is a Bisq Network proposal. Please familiarize yourself with the [submis…sion and review process](https://docs.bisq.network/proposals.html)._
_ATTN @bisq-network/contributors: this is on short notice, but I'm requesting that everyone who plans to submit a compensation request review this proposal prior to our upcoming May voting round a couple days from now. See my more detailed comments about this at bottom. Thanks._
## Introduction
In this proposal, I want to draw a distinction between work that is IN PROGRESS and work that has been DELIVERED, and to make the case that contributors should submit compensation requests only for work that has been DELIVERED and that stakeholders should always vote to reject compensation requests for work that is still IN PROGRESS.
## What it means for work to be "delivered"
It means that the work in question has been made available to users. It means that users have the work in their hands (or _can_ have the work in their hands at will) and can realize for themselves immediately the value that the work brings.
This is the same meaning of the word 'delivered' as it applies to a shipment from Amazon. If you order a pair of shoes from Amazon, you cannot realize the value of those shoes until they have been DELIVERED at your doorstep. Before the moment of delivery, you have realized NO VALUE, and after the moment of delivery, you are able to realize at will all the value those shoes can provide.
The same holds true for a bug fix or new feature in a given Bisq software component. Until there is a release of, say, Bisq Desktop available that includes that work, users cannot realize its value.
Furthermore, a user cannot realize the value of a given unit of work if they do not know how to use it or do not know it exists in the first place. This means that for work to be delivered, it must also be **discoverable**. In most cases, this means that the work must be **documented** and **announced** and/or **promoted** in some appropriate way, e.g. via release notes, Twitter, Reddit, YouTube, etc.
So, **delivered work is work that:**
- users can use immediately because it **has been released**
- users can figure out how to use because it **has been documented**
- users know exists in the first place because it **has been announced and promoted**
> NOTE: there are exceptions to the above, and I'll cover them in sections below.
## What it means for work to be "in progress"
Work is in progress up until the moment it is delivered. Discussions about the work, writing code to implement the work, submitting pull requests for and reviewing the work are all equivalent to that work being "in progress" from the user's perspective.
Even when a pull request has been merged to `master`, the work is still "in progress" from the user's perspective. Nothing matters to (the vast majority of) users until there is a release available to download and run.
(So yes, this means that I am proposing that no one gets compensated for their work until that work is actually released. Getting a PR merged is not sufficient. I'll talk more about this below.)
## Compensation requests and the significance of BSQ requested
As we have discussed elsewhere, the amount of BSQ requested for a unit of work in a compensation request represents that contributor's best estimate of what their work is worth to Bisq and its users, i.e. it is an estimation of how much value that work adds to the network. It is NOT an estimation of how much effort that contributor put into the work. (Note that the latter can be a useful _reference point,_ i.e. a way to come up with an _initial_ estimate, but ultimately the amount of BSQ requested must be aligned with value it adds to users).
With this in mind, I present the following logic:
- The amount of BSQ requested for work reflects the value of that work to users
- Work that has not yet been delivered is by definition of NO value to users
- The correct amount of BSQ to request for such work is therefore ZERO
- Submitting a compensation request for zero BSQ is absurd and wasteful, so:
- Compensation requests should be submitted only for work that has been delivered
And from there it naturally follows that compensation requests for anything other than delivered work should be rejected by voting stakeholders.
## Further reasoning
At the risk of belaboring these points, I want to drive home why we need to do things this way.
First, with regard to requesting BSQ based on the value work provides to users instead of basing it on the time and effort the worker expended, just think about it from a Bisq user's perspective. As a user, you know that the BSQ you spend on trading fees essentially creates a transfer of value from you to the contributors who perform work that makes Bisq more useful and valuable to you. You do **not** want to pay for someone's time and effort, because that's not what is useful to you. You want to pay for utility! In many cases, the amount of BSQ requested in a given compensation request may be fairly close to what it would have been if it was calculated as a function of the contributor's hourly rate, but it's important to users' confidence in BSQ that we don't model it that way, and that we model it instead on the utility / value that work delivers. This way, users really feel that they're paying for the value they get, and not paying for a bunch of different people's arbitrary hourly rates. People's hourly rates can vary a lot with different geographic locations and other factors, whereas Bisq's fees do not vary between users at all. When we all work together in the compensation request and voting process to reach consensus on what work is worth to users, we eliminate the variability of individual contributors' skill levels, geolocation, etc. It greatly simplifies things, and makes it possible for us to build a meaningful, increasingly objective shared mental model of how much various kinds of work are worth to users over time.
Second, with regard to compensating only work that has been delivered, I argue we must do so, because **if we compensate work that is in progress, i.e. not yet delivered, we are literally incentivizing contributors NOT to deliver.** This is hugely important as we continue to grow. The bar must be set HIGH for compensation. What you're working on must be shipped, delivered software, sitting in users' hands, actively delivering value in order for you to get compensated for doing it. If we do anything less, than we will begin compensating untold numbers of projects that will wander off into the woods, never ship, and never add value. This too will quickly erode user confidence in BSQ and will put all our efforts at risk.
We must incentivize what we want, and dis-incentivize what we don't.
What we want is software shipped early and shipped often, such that it benefits from lots of feedback and continuously delivers new value into users' hands.
What we don't want is long, meandering efforts that never ship or ship only after a long time, without the crucial benefits of early feedback and validation.
The proposal above to compensate only work that's been delivered and to reject compensation requests for work that's still in progress puts the incentives right where they should be to realize these goals.
## Examples
I should mention here that in large part we've already been operating this way, i.e. that many if not most compensation requests have been requests to compensate delivered work, and where they haven't been, that's OK. We're figuring things out as we go, and assuming we have consensus on and enact this proposal going forward, there is no problem with the fact that we've been compensating some in-progress efforts up until this point. What matters is that we correct course as soon as we see that we need to. That's what this proposal is about.
There are two main examples of compensating in-progress work that I want to call out here:
1. @mrosseel's HTTP API work. This is now getting close to an initial release, but for all the reasons above, until it is released, in users' hands, and accepted into the @bisq-network GitHub org, we should hold off on any further compensation.
2. @ManfredKarrer's BSQ / DAO implementation. I imagine everyone will agree with me when I say that this is the most important work we have underway, but until its initial production release, it is adding no value to users and we should therefore hold off on any further compensation.
By contrast, the work that @blabno and co have been doing on `bisq-mobile` has not yet been released, has not yet added any value to users, and no one on the team has requested any compensation for that work yet. This is a good example of how it should be. I am a bit concerned at just how _much_ work is being done there without early feedback, and I would have preferred to see a more minimal v0.1.0 that could get validated by users, but I trust that @blabno and co understand the risks they are taking by investing this much time and effort prior to an initial release, and they are free to manage their efforts in any way they see fit.
It's worth mentioning here that contributors may sometimes want to hold off on an initial compensation request for their work even after they have released it, in order to gather initial feedback, build up an initial user base, and to clearly demonstrate the value of the work they've done. If for example, a contributor builds a brand new Bisq component, ships a v0.1.0 release of it, and immediately requests compensation for that work, it may not be obvious to voting stakeholders what the value of that new component actually is to users, because users haven't had any time to use it yet. If instead the contributor ships v0.1.0, gets initial feedback, folds that feedback into a subsequent release or two, and collects various metrics along the way to demonstrate that the component is in fact being adopted, is in fact of value to users, it will be that much easier and that much more objective for the contributor to request a given (possibly higher) BSQ amount for that work.
So while this proposal sets delivery as the standard for when work becomes _eligible_ for compensation, it remains at the contributor's discretion when _after_ that point they choose to submit a compensation request. Generally speaking, the bigger, more ambitious and more uncertain a unit of work is, the more the contributor will benefit from introducing a gap between the initial release of that work and their initial compensation request for that work. The contributor is putting their time and effort at risk by doing this, but they increase the chances of that risk resulting in a significant payoff because they allow themselves time to incorporate feedback and to find a product/market fit for their work.
Contributors who are more risk averse and wish to be compensated more promptly for their efforts should in general shy away from bigger and more ambitious efforts, and should focus on delivering smaller units of work that have a higher degree of certainty as to their value. For example, bugs that everyone already agrees are important to fix, or other minor, non-controversial improvements to existing components.
## Non-development contributions
So far, I have focused on _development_ contributions. This has been intentional, because in the end, the most important kind of contributions to Bisq are software-related, but the proposal that we should compensate only delivered work applies equally to all kinds of contribution under the Bisq DAO.
If for example, you are a forum moderator/administrator, you are delivering value to the network every time you respond to a user post, every time you create a backup, etc.
If you are a YouTube Administrator, you are delivering value every time you upload and categorize a video, etc.
And so forth for all the many different non-development roles under the DAO.
I wrote above that "delivered work is work that has been **released, documented and announced/promoted**". Those terms are strongly connoted with development work, but they map onto non-development work just fine.
When you perform some valuable function, like answering questions on the forum, that is the moment of "delivery". Your work has, so to speak, been "released" when you click the submit button. It is "documented" and "discoverable" in the sense that your answer is there for everyone to see in future search results, and it is "announced" or "promoted" in the sense that an email notification has been sent to the user you were responding to. I realize that it's a bit contrived to map these things in this way, but I think the exercise is worth it. The point is that we should always be evaluating work on the basis of whether it has really been delivered to the intended user(s) in such a way that they can actually realize its value. If you stay true to that principle, I think it's pretty easy to determine whether a given compensation request represents delivered work or work that's still in progress.
## Exceptions
Not everything needs to be documented in the sense of updating a manual. If you fix a bug, you don't need to update the documentation, because the definition of a bug is that some component is behaving contrary to its documented / advertised behavior. In the case of bugs, the bug report and the commits that fix it are the documentation. Bug fixes of a certain magnitude should still be _announced_ via release notes, however.
## What ifs and yeah buts
> "As a contributor, I control my work up until the point that it gets merged by a maintainer. If I can't submit a compensation request for that work until the a maintainer ships a new release, then I might wait a really long time to get paid! This is unfair, and that's why I think we should consider a merged PR to be a delivered PR."
This was how I thought about things until recently as well. I think I'm even on record in a live stream saying something very similar to the above. I've changed my mind, though, and again it has to do with aligning incentives.
The premise of the concern above is that maintainers might take a long time to ship the next release of whatever Bisq component it is that you've contributed to. This of course may happen for any number of reasons, but what we should be striving for as an organization is to release new versions of Bisq components regularly and often. We often say that our goal with Bisq Desktop is to ship roughly once a month. We don't want to ship much more frequently than that, because it can become burdensome and irritating for users to deal with frequent upgrades, and we want to avoid the situation where they get desensitized and start ignoring or indefinitely deferring upgrades. We also don't want to wait too much longer than one month, because that's just a very long time to wait to deliver important new functionality and bug fixes to people. In any given month, there is almost always some fix or feature implemented that is really worth getting into people's hands. And a monthly release cadence is furthermore ideal because we submit and vote on compensation requests once per month, too. So when we hit this release cadence, we eliminate the situation where contributors are left with an "unfair" gap between getting their work merged and getting compensated for that work.
But let's assume for a moment that, for whatever reason, we're NOT hitting that release cadence. That Bisq Desktop releases are sporadic, that sometimes months are going by without a release, and that in turn, contributors are getting frustrated and restless about it. This is a GOOD thing, because it puts direct peer pressure on maintainers to get their shit together and start shipping more regularly once again.
Users want regular releases because they want regular delivery of ever more useful software into their hands. Contributors want regular releases because they want regular compensation for their work. Maintainers want regular releases because they too want regular compensation for their work, but also because they want to avoid unhappy contributors and unhappy users. This is what I mean by aligned incentives.
Of course there can always be extenuating circumstances that throw release schedules off course, but over time, these should be the exception, and everyone should be prepared to deal with those problems as a team, to pitch in to get things back on track, and to do whatever it takes to keep the machine running smoothly.
We DON'T want a culture where contributors get their work merged, get paid straight away, and then have no further incentive to see their work get into users' hands.
We DO want a culture where everyone has skin in the game, and no one gets paid until users get value.
Getting this stuff right as early as possible means building the strongest foundation possible for BSQ leading up to its production release. I think it will matter a lot to users to know that we've gone through these kinds of deliberations and that we've established high standards for what gets compensated. I think it will be powerful for people to know that every BSQ earned is equal to value being created and that every BSQ burned is equal to value being consumed.
## On the timing of this proposal
I had intended to write this proposal immediately following our [Apr 4th–6th voting round](bisq-network/compensation#56) in order to give plenty of time for consideration and discussion, but as it turns out, I am submitting it now, just a couple days prior to our scheduled [May 1st–3rd voting round](bisq-network/compensation#58).
I'd appreciate it if everyone could take the time to review this before submitting their compensation requests, such that we can be aligned on this topic as soon as possible. If we have a clear consensus among the 6-8 contributors who have been regularly submitting compensation requests over the last months, then everything is easy and we can just move ahead with this proposal. If it's not so quick and clear, that's fine too; I don't want to rush anything. In that case, we can move ahead with compensation requests and voting as per the status quo in this next round, and we can let this proposal mature over the next two weeks as per [the usual process](https://docs.bisq.network/proposals.html#process).
Thanks, everyone.