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

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.