Comments (3)
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.
from proposals.
@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.
from proposals.
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.
from proposals.
Related Issues (20)
- Application to become a mediator for Bisq 2 HOT 4
- Application to become a moderator for Bisq 2 HOT 7
- Bisq2 Release Manager HOT 3
- Application to become a mediator for Bisq 2 HOT 3
- Bisq2 Release Manager HOT 5
- Application to become a moderator for Bisq 2 HOT 5
- Bisq2 seed node operator HOT 5
- Bisq2 oracle node operator HOT 4
- Bisq2 Security Manager HOT 3
- BSQ trading fee update on Cycle 53 HOT 4
- Plan for Projects Maintainer role: First Stage HOT 4
- BSQ trading fee update on Cycle 55 HOT 13
- Proposal for @solomon1923 to assume Growth Lead role HOT 1
- Application to become a bonded pricenode operator HOT 3
- Show a Warning for potentially misconfigured network settings
- Reduce max. trade amount via DAO voting HOT 5
- Restore mempool fork HOT 2
- Reduce max refund amounts HOT 1
- Single Transaction Multisig Protocol for Bisq using UTXO swap HOT 12
- Application to become a bonded price node operator HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
đ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. đđđ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google â¤ď¸ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposals.