Compensation requests should be submitted only for work that has been delivered #19
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.
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:
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
(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:
And from there it naturally follows that compensation requests for anything other than delivered work should be rejected by voting stakeholders.
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.
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:
By contrast, the work that @blabno and co have been doing on
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.
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.
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
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.
The text was updated successfully, but these errors were encountered:
Just adding some discussion that happened in the slack channel #proposals.
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.
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.
Closing as approved with 5
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