Change policy for compensation requests

[ManfredKarrer]

After discussions and feedback from various contributors I think there are several good reasons to rethink our current policy that requests are only done for shipped code.

As we have seen with the long lasting projects the current policy comes with several drawbacks.

• Waiting long time will make valuation harder as the contribution is further back in memory. To evaluate a huge chunk of work would also take then much more time as not all is remembered as fresh as at the end of a one months work.
• Having a monthly compensation gives higher motivation to contributors as it would be if the compensation comes after several months
• Adding up a lot of such requests can end up in a very large request which will be harder to evaluate
• It is less risky for both sides if requests are done earlier with smaller amounts in case expectations are different for any of the sides.
• Code which is in master is accessible for those who run from source code, so the shipping definition is not constrained to the binary shipping only.

I would suggest that we change the current policy from "being shipped" to "being merged to master". I think that still holds the goal that we don't spend funds on work which might never lead to value for a user but reduces delays, gives more motivation and reduces risks.

@cbeams What do you think?

I retain 2 words from this proposal : higher motivation
The rest is imo also ok.
But the great point is motivation.

On this topic, I think that Bisq navigates between 2 reefs/worries :

• paying too much for contributions is one reef
• lacking developers/contributors is the second reef.

Both reefs are problematic, but the second reef is imo much more problematic than the first.

Paying too much is bad, but :

• we do that just for one month. At worst it's a one month error. And the loss can be immediately cut the next month
• there's a french saying (badly translated) "money wound is not fatal". That's the case.
  Lacking developers/contributors is a much more dangerous reef.

Everyday other devs are working on other projects.
Everyday we don't move forward, we lose part to competitors.
This is far more dangerous than losing money for one month.
And Manfred's proposal is btw very reasonable.
I don't think it's throwing money thru the windows.

[sqrrm]

I tend to agree with @HarryMacfinned on the risks. It's a bigger risk to not attract, or outright lose contributors at this point. The reward given is at the moment a future promise of a token, it won't ever be worth anything without contributors. I think the original thoughts are valid on aligning reward with shipped code, but at the moment it's not as important as just getting things done, minimizing obstacles and getting to a state where it might be more relevant to be more strict.

[chirhonul]

I agree with the proposal and the comments made above - currently we have very few committed contributors, and if the project is socially centralized, i.e @ManfredKarrer and few others do all the work, the project will fail, so while we are navigating between two reefs, currently we are more likely to sink due to the lack of contributors.

Comparing working on bisq with a normal day job shows difficulties in the current model - if developers had to explicitly specify the value they produce and make sure it was delivered to the company's customers continuously before getting paid, compensation would be more stressful and less predictable. Even for consulting jobs, there is typically an up-front negotiation for a contract for certain number of hours, or a specific delivery.

Apart from the specific proposal here, I would also consider ways to create proposals with expected BSQ compensation that pay small percentages of the expected amount for milestones for larger projects like the redesign or DAO. Maybe even worth considering "patronage" models where there is a semi-centralized fund, which ideally stakeholders can vote on for the DAO, which can issue time-limited grants to contributors to supplement their compensation apart from any specific project. I do understand the motivations behind the current model, but it also needs to be empirically validated in terms of what actually causes people to show up and do the work.

[cbeams]

TL;DR: I'm open to shifting the definition of delivered 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 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 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.

[chirhonul]

First, let me apologise for going on a tangent in my earlier reply. This proposal was on the topic of change the current policy from "being shipped" to "being merged to master". I suggest we focus the discussion here on that topic, since it seems we are mostly in agreement on that being a reasonable thing to do.

Second, thank you for your characteristically detailed and thoughtful reply @cbeams. I agree bisq is quite different from a regular company, and I do appreciate what you are expressing in terms of the potential assymetry between transaction costs placed on bisq maintainers, and bisq contributors. I however also think that empiricism is a virtue. If we are finding ourselves several years into a project where almost everyone who understands it agrees that it is genuinely novel and a promising and potentially crucial "second financial layer" on top of Bitcoin as a base "economic layer", in @ManfredKarrer's terms, but despite this we still find ourselves with less than a handful of committed contributors, we may need to consider not just tweaks but indeed more radical adjustments to the incentive structures we have. Perhaps a reasonable model to discuss something like that would be a temporary suspension of principles we all deeply believe in during critical times, similar to how Lincoln suspended habeas corpus during the American civil war? If the project dies due to being socially centralized on 1-3 individuals, the principles we hold may not matter much.

So as mentioned, perhaps it's best to continue any discussion that's outside the specific scope of this proposal in a separate forum, like a separate proposal?

[ManfredKarrer]

Thanks for the thoughtful reply @cbeams.
I re-read #19 and I would like to continue discussing it at an appropriate place - maybe to re-open the #19 proposal or to discuss it on the Forum.

For this proposal I think there is agreement that getting merged to master should be enough to file a compensation request.

[cbeams]

My apologies for the delayed response on this. @ManfredKarrer and I met by phone to discuss this matter, and agreed that, with all the discussion above in mind, submitting compensation requests for contributions merged to master is acceptable, so long as it is complete, finished work.

We also agreed that work on the Bisq DAO and BSQ system is an exception to this rule, and that going forward, partial work on that effort may be submitted for compensation; I defer to Manfred to determine what is reasonable there.

As I final note, I think this compromise is going to make things more difficult and more muddy over time, but I can't simply sit here and say "no" when there is a strong consensus to the other side. I hope I'm wrong! In any case, we'll need to remain diligent about finding what actually works, and this change seems like a fine experiment to take toward that end.

I'm fine to close this proposal as accepted now, and to make this the new rule going forward (including for the current compensation period). @ManfredKarrer, you too?

[ManfredKarrer]

@cbeams Yes we can close that. Thanks.