[bisq-network/proposals] Change policy for compensation requests (#38)

Tue Sep 11 14:55:28 UTC 2018

_TL;DR: I'm open to shifting to shifting the definition of [delivered](#19) to mean "merged to master", but I am not open to compensating partial work (save in truly extraordinary situations)._

First, I want to acknowledge that this we're addressing a very difficult problem here. A major reason that firms (corporations) exist, hire employees long-term and pay them salaries is to avoid the steep transaction costs of figuring out how much each individual unit of work from each individual employee is worth, when that amount should be paid out and so on. Firms make a big fat tradeoff here. They do a lot of up-front vetting (interviews, CV reviews, etc), then they engage in a (hopefully) long-term contract with that employee, but they reserve the right to fire that employee at any time if they aren't performing satisfactorily. To get away from having to evaluate every unit of work, they evaluate the person instead, and then do periodic "performance reviews", etc. And generally speaking, this is the right tradeoff. We know that because it's how virtually every firm works, and they do so of their own choosing.

Now consider Bisq. It is not a firm in any traditional sense. It is not a corporation. We do not (cannot) hire or fire. Worse, we cannot even prevent people from contributing if we think they're sub-par. Everybody is free to submit pull requests, and we are stuck, one way or the other, with the transaction costs of evaluating these individual units of work. This is highly inefficient compared to the modern firm, completely different from the modern firm, and requires thinking and designing things differently than the modern firm.

My position thus far has been to put as much these transaction costs as possible on the individual contributor. That may sound like a terrible idea at first, but the alternative is far worse. The former can scale, while the latter cannot. Let's reconsider what I wrote in my definition of [delivered](#19) in proposal #19:

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

With this high bar in place, individual contributors know that it's _on them_ to meet the requirements above, and that if they don't, they're not going to be compensated. As I mentioned above, this approach can scale, because all that's left for stakeholders to do is evaluate whether those criteria have been met, and whether they believe the work to be of value. If partial work is being submitted for compensation on a monthly basis, that does not meet any of these requirements, the calculus for stakeholders is much more difficult. Votes will end up being [delegated](https://github.com/bisq-network/proposals/issues/34) to whomever stakeholders think is most in the know, and will just ignore whether value is really being created as it is in many cases impossible or just too difficult to evaluate partial work.

Beyond the scalability problem, there is the incentives problem, which again I wrote about in proposal #19:

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

Again, please remember: we are not a firm, and that means there is no threat of firing a contributor for non-performance. We can express a vote of no confidence by voting down all contribution requests from a given contributor, essentially telling them to go away, but this is a brutal process, and one that I argue no one wants to do and few will ever do in practice. I argue it is better to keep a high bar on what qualifies for compensation in the first place, so that everyone has a level playing field.

This arrangement clearly will not be for everybody. But it should be of quite some interest to developers who are capable of cutting up their work into "bite sized" pieces that can be delivered incrementally (adding real value with every increment), and for those who want to work with high standards and maximum autonomy. That's who I want to work with. I want to stay far away from "managing projects" and "managing people" as possible. We should collaborate with and indeed compensate each other based on clear contracts. That's what I've tried to put together with the definition of _delivered_ as presented in proposal #19.

Now: I would be open to the idea of changing the definition of delivered to mean "merged to master" vs. "released in a new version of Bisq", so long as the other aspects of the definition of delivered above are still respected: that any documentation has also been written and merged to `bisq-docs:master`, and that there is some plan for how to get the word out about that new feature (assuming we're talking about a feature; these bits don't apply to bug fixes and other minor stuff).

I get that this would help align compensation with monthly boundaries, and help cut down on there being "too much to evaluate" in a given compensation request, because, e.g. it's been two months since the last release. **The key thing for me is that we do not open Pandora's box by allowing compensation for partial work.**

Please hold aside a long-term project like BSQ / the Bisq DAO as a special case. I would also be open to compensating partial work on such an effort—as an exception—because it is so deeply fundamental to our mission, and because we are so clearly committed to it. But the bar for such exceptions must be very high. My default position would always be "no" to compensating partial work unless there is an extraordinarily good argument for doing so.

What I have tried to optimize for in my efforts thus far is creating the right set of incentives to encourage high quality contributions from new developers, while minimizing the transaction costs on existing Bisq developers with regard to managing, evaluating and voting on those contributions. I'm open to tweaks, but don't want to see that contract fundamentally compromised.

I encourage everyone to re-read proposal #19 in its entirety. It expresses everything I think about this topic in the best way I could, and I still feel the same way about everything I wrote there. Thanks.

-- 
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/38#issuecomment-420303532
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20180911/0d5becb3/attachment-0001.html>