Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Change policy for compensation requests #38
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.
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
On this topic, I think that Bisq navigates between 2 reefs/worries :
Both reefs are problematic, but the second reef is imo much more problematic than the first.
Paying too much is bad, but :
Everyday other devs are working on other projects.
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.
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.
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:
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:
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
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.
First, let me apologise for going on a tangent in my earlier reply. This proposal was on the topic of
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?
For this proposal I think there is agreement that getting merged to master should be enough to file a compensation request.
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?