Compensation requests should be submitted only for work that has been delivered

[cbeams]

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

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

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.

Thanks, everyone.

[ghost]

Just adding some discussion that happened in the slack channel #proposals.

diogorsergio
What about design? Our work is “delivered” before going into the users hands. Do we assume delivered once we pass it on to developers? or once developers implement the design and has shipped to the users?

cbeams
The latter. This is essentially equivalent to to the scenario I laid out toward the end of the proposal in which a contributor gets a PR merged but can only submit for compensation once a release has been shipped that includes that change. This is why I chose the term “delivered” here: to emphasize looking at things from the user’s point of view. Your work as a designer may be “finished” or “complete” well before delivery, but delivery is the gate that any and all work must pass through in order to become eligible for compensation.

cbeams
At every stage and for every participant in the process, this creates incentives to ship early and often, to avoid big bang rollouts, etc. The idea is to minimize risk for everyone by keeping everyone invested in getting work delivered to end users. Because that’s the only thing that actually matters in the long run.

diogorsergio
Yeah, it makes sense. I was just thinking because design will always depend on someone else to pick up the work and implement it. So in a way designer will be at the mercy of developers to get their work delivered. Of course it brings incentive to developers, but its not a self sufficient role.

cbeams
I think there are two ways of looking at it. (1) designers are at the mercy of developers, or (2) designers have strong incentives to work closely with developers to design the right stuff at the right time in order to minimize waste and lag between completion (of the design) and delivery (of the component being designed). (edited)
In so many ways, the Bisq DAO is designed to encourage “pro-social” behavior. These sorts of arrangements encourage everyone involved to work closely together to get stuff done, instead of throwing things over the wall, saying “my work is done”, and all the other dysfunctional, anti-social kinds of behavior that typify most organizations.
Going from employment-based compensation to task-based compensation really does change everything. Requires everyone to re-examine at every step what feels normal and conventional. Basically, if it doesn’t feel strange at first and require some adjustment / acclimation time, we’re probably doing it wrong!

diogorsergio
Yeah will do. What I was thinking then was a developer work that is more focused on the interface shouldn’t be considered delivered if it hasn’t implemented a design spec, and no issue or task should be released to master without design. So that way it encourages both devs and designers to work together, and it minimises the design inconsistencies. Since we now have people working actively on both ends, this just needs coordination from both parties.

cbeams
The normal review process should be able to address what you’re talking about here.

Everyone is free to work on whatever they want at any time. Bisq is designed for maximum autonomy and total permissionlessness. @pedrogoncalves’s design proposal is a perfect example of this. We didn’t know him from adam. He just showed up with some valuable work and said “what do you guys think?“. This is how it should be.

But just because you do some work and submit it doesn’t mean that it’s going to find it’s way into a component. Indeed, the default case is that no one is going to care about what you work on at all if you aren’t going about it in a pro-social fashion, i.e. if you aren’t being a good actor / good collaborator, etc.

Just because someone (some developer, let’s say), comes along with some change to the UI, doesn’t mean that it’s going to get merged. It doesn’t even mean that anyone is going to spend one second reviewing it. And if no one reviews it, no maintainer is going to merge it. This is the flipside to the “work on whatever you want” rule: nobody is obligated to review or care about your work at all, unless you’ve somehow convinced them that it’s worth spending time on.

And, anyone is free to review anyone else’s work. So if our hypothetical developer comes along and submits a PR changing something in the #bisq-desktop UI that is a total departure from what Bisq’s #design contributors have been working toward in terms of direction / standards, etc, then one or more of those contributors should review that PR with a NACK and an explanation why it should not be merged. The #bisq-desktop maintainers will wait for reviews to settle down, figure out what the consensus looks like and then act accordingly, i.e. merge or close that PR as appropriate. And of course our hypothetical oblivious developer is in the mix the whole time, getting educated about what passes muster around here, and (if they’re a good actor / somebody worth working with), they’ll want to further patch up their PR to get it into shape, in line with #design standards etc.

Process is really everything, and the goal is to have as few rules as possible, invite as much contribution as possible, and craft a culture over time where everybody knows that getting stuff into Bisq means clearing a HIGH bar.

Think about Bitcoin Core today. No one but the most blinkered fool would think that a sloppy PR is going to get merged. Everyone’s expectation is—especially if this is their first PR—that their work is probably going to be ignored, and if not ignored, is probably going to get shot down in flames during the review process. They’ll be positively elated if their PR does make it in, though, possibly after having been changed beyond all recognition during review. You see this happen frequently on Twitter: Some first-time Bitcoin Core contributor proudly proclaiming “Oh my god, I got a patch merged, hooray!” … THAT is the kind of culture we want to build around Bisq. I don’t think it comes through having stuffy rules around specifications or other rigidly proscribed rules about how to collaborate with whom at what time. It comes from crafting a culture where everyone knows that nothing gets in without going through the gauntlet of review, and that in the end, only that which is rock solid and a match for the project’s values and standards makes it.
So I say empower the review process. Dedicate yourself to reviewing work that comes in. When you find yourself repeating stuff to people in the review process, write those things down so that you can point people to it in the future and say RTFM instead of wasting your time repeating yourself. What emerges through that process is a needs-driven documentation of style guidelines and standards and so-on. This is what you see emerging at https://docs.bisq.network now, btw. See also https://github.com/bisq-network/style/issues for an example of stuff that (so far only) I’ve been writing down as I go through reviews with people and find myself repeating things.

cbeams
And by the way, it may be the case that what emerges through this review process over time is exactly what you suggested above, that significant changes to the UI don’t happen without up-front interaction with the design team first. My point is that the only thing we need now is the normal C4 review process, and that we can and should let everything else emerge from there. People will gravitate toward the process that is most effective over time. Try to avoid proscribing too much up front, because it’s virtually impossible to get process right that way.

diogorsergio
Sounds good and I think its the right methodology of doing this type of work. And you are right, the review process should help a lot ironing this questions.
I was just trying to convene the idea that there needs to be some sort of design checkpoint in the workflow, and yeah i think review process can be place for it.

[cbeams]

@ripcurlx and I just had a chat in Slack regarding how this and other recent proposals like #13 affect how contributors should request compensation for the various roles they play.

The short answer is that this is an imperfect situation right now, and until we get bonding and interest payments on those bonds in place, we have to take the same best effort approach we've been taking over the last month. So nothing changes here. In particular, if you’ve been asking for lump sum compensation that includes your efforts across multiple roles in past compensation requests (like @ManfredKarrer, myself and @ripcurlx) have been doing, just keep doing so for now, and don’t change anything there until we get consensus on a new approach.

If you have further questions about this, please ask them here, or probably better, ask them in #compensation first, so that things don't get too noisy here. Then we can reflect whatever the outcome is here in a comment like I did with this one.

[cbeams]

Closing as approved with 5 👍 and 0 👎:

Thanks everyone for ramping up on this so quickly during last month's voting round. It was on short notice then, but I think everyone adapted to the changes quite well. Let's keep it going this month in bisq-network/compensation#70.

Note that I plan to write up a Compensation document soon under the new docs.bisq.network site that will capture this and other recent compensation-related decisions into a single, easy-to-follow document on how to submit compensation requests. In the meantime, the instructions at https://docs.bisq.network/dao/phase-zero.html#how-to-request-compensation are still the best place to go.