Role owners should itemize compensation on a per-role basis in monthly compensation requests about proposals HOT 14 CLOSED

@HarryMacfinned, this is becoming a different conversation now, and I'd prefer to take it offline from this specific proposal thread. I don't understand what you mean by "running things (nodes/repos/etc) in an unsafe way".

If this is about non-mission critical infrastructure that surrounds Bisq, such as YouTube, please keep in mind that it is completely optional for both users and contributors to interact with. We must strike a balance between "going where the (potential) users are" with tools like YouTube and Twitter and being perfectly decentralized, perfectly private, perfectly "safe". We could set up videos on DTube (or whatever) instead of YouTube, we could use Mastodon instead of Twitter, we could set up our own GitLab instance, etc etc, but all of this is a giant waste of time when what we need is to attract users and developers to Bisq. We need to show up where people are, such that they know we exist in the first place. Most people in the larger Bitcoin space still have no idea about Bisq.

Anyone is welcome to set up a Bisq presence on some YouTube alternative, anyone is welcome to start tweeting on Mastodon, etc. These things don't require permission from anybody. In the meantime, regarding contributor safety, what matters is that those contributors who wish to remain pseudonymous can. We have had several pseudonymous contributors who have contributed meaningfully to the project, and YouTube, etc were never a showstopper for them. The bottom line is that people need to be able to use GitHub. Everything else, at the end of the day, is optional.

If you have a specific proposal about changing infrastructure, please submit it as you see fit. If there's something I'm missing about your concerns, please take the time to make a clear case for them elsewhere. In any case, I'll look for interest and consensus from other contributors about this topic before I weigh in further about it.

from proposals.

I think it is a good idea to make it more transparent how compensation is structured for each role, that's why I give a 👍. But for me it wouldn't be possible to do so properly for next month's voting as I haven't tracked efforts in detail for each role this month already. So I'm up to do it as suggested during September's voting.

from proposals.

+1 with ripcurlx, I think also it's a good idea to formalize things, and also to do it early. Thanks to @cbeams for this useful work.
Reading the document I don't see problematic points on this rather administrative level.

There is however one point which worries me a bit.
I had a look on all the special nodes roles
... and my feeling is that the number of running nodes is rather low.
Maybe this will change nextly ... but atm the numbers are rather low
and this could be considered as a risk for the bisq network.
Maybe there should be a discussion :

• on how much the community estimate the costs of those risks if they unfortunately materialize
• on how much the community values owning nodes and is ready to pay to reduce infrastructure risks by increasing the number of nodes

I will try a comparison with what I know :

Support : There seems to be atm a consensus considering 2000BSQ/month as a right cost (and compensation) for the support role.
I didn't browse in detail how much is asked as a whole for the support, but if not wrong, this is at least 4000BSQ/month, and maybe more (the role is still tagged with "help wanted").
So it may well be 6000BSQ/month at least.
I tend to agree with such amount, imo those are well allocated BSQ.

Nodes : On the other hand, let's try to estimate the nodes costs/month for the bisq network :
If I'm not wrong, one node is reimbursed 50BSQ/month and there are roughly 30 special nodes.
So the total allocated sum is : 1500BSQ/month.
Given that the nodes are quite important for the network (its infrastructure) and that the numbers seems rather low (since a long time), I wonder if the incentives to run nodes are sufficient ?

I don't want to push for inflation, but :
6000BSQ/month for the support, 1500BSQ/month for the nodes, is this a good balance ?

There is more to say, but I'll stop here atm.

PS1 : I apologize if such discussion already happened and I missed it.
I apologize also if the numbers above may be too approximate (or wrong)

PS2 = disclaimer : I myself maybe interested as being a node(s) maintainer.

from proposals.

@ripcurlx wrote:

it wouldn't be possible to do so properly for next month's voting as I haven't tracked efforts in detail for each role this month already

Let's dig into this. It's exactly the kind of discussion I think we need to have. Could you give an example of a role you own where you would need to "track efforts in detail"? And what does "tracking in detail" mean for you? Literal time tracking?

My hope here—and I don't know for sure if it's feasible, that's why we need to have these discussions—is that we can make most if not all roles simple enough in their duties to make it possible to estimate time and effort on a monthly basis, and ideally to request the same, or roughly the same, amount every month.

Let's take @bisq-network/seednode-operators for example. Each operator's hard costs are generally going to be the same from month to month, perhaps with slight variance depending on their hosting platform's billing model. Soft costs (time and effort) will usually be quite minimal, probably entailing one or two version upgrades and redeployments. So most months, each seednode operator will probably request roughly the same, if not exactly the same, amount of BSQ for that role.

The above is an easy example. Let's take something more challenging now, like being one of the @bisq-network/desktop-maintainers. The primary duties of this role include merging pull requests after sufficient review, triaging incoming issues, and performing releases. If, as the roles doc stipulates, we separate out development and review activities from this role, and itemize them as normal (non-role) contributions, do you still feel it would be necessary to "track in detail" your efforts on this role? Would it not be reasonable, at the end of the month, to estimate this figure, relative to previous months?

I'm asking these questions, because I'd like to avoid setting a precedent about time tracking or anything else that causes people to have to go out of their way on a daily basis to account for their activities. Time tracking has always been a nightmare in my experience with it in many organizations, and it introduces a level of bureaucracy and even mistrust that I'd like to avoid institutionalizing in any way within the Bisq DAO.

And "time and effort" is really just a first approximation / heuristic for "value added to the network" anyway. What I care about as a voting stakeholder is not whether you tracked your efforts in detail, but whether the amount of BSQ you're requesting for that effort is commensurate with the work done and the value that work adds to everyone involved. In order to be able to make that assessment, I need to be able to see what you did, and this is why itemization of efforts is important, but so long as I can see the work you did (or read your description of it), then I can judge whether the amount of BSQ is reasonable. I'll be making that judgement based on previous compensation requests for the same work, other contributors' compensation requests who do similar work and play similar roles, and so on.

My whole point here is that I think we can converge over time on the correct amounts to request without doing a lot of "tracking efforts in detail". I think it's enough to do an end-of-the-month GitHub Issues query that allows you to review all the issues and PRs you participated in, to gather them up and to request compensation for them, and for anything that didn't leave an explicit issue or PR "paper trail" (i.e. certain role-related duties), I think it's enough to offer a well-considered estimate of your time and effort on those duties and to request reasonable BSQ compensation for it.

What do you (@ripcurlx) and the other @bisq-network/role-owners think?

from proposals.

@HarryMacfinned, I think what's important is that node operators request the amount of compensation that's correct for them, and that the "right amount" emerges over time. I wouldn't want to try to budget or allocate a certain amount of BSQ for this work; rather I would try to keep pushing for our decentralization goals, i.e. having as many different trusted/trustworthy contributors as possible running seednodes, pricenodes, and btcnodes and to institutionalize the idea that operators should request BSQ compensation for their efforts that cover both hard and soft costs. Then we trust operators to honestly assess these values and request the right amount. If an operator is perfectly content being compensated to the tune of 50 BSQ / month for their soft costs, then so be it. If another says that their time and effort is worth not less than 100 BSQ, then we should evaluate that individually as voters and cast our vote as we see fit. If another operator requests 1000 BSQ for essentially the same work, it's reasonable to expect every voter would reject the request. Where is the "right" number above? I don't pretend to know, and I would prefer if we don't collectively pretend to know either. A major goal of mine in writing the roles document was to make it clear to role owners that they should request compensation for their efforts in a comprehensive way, not just for their hard costs. I think it's good to have this conversation, but I'd advocate for letting things play out from here for the next few months and seeing how it goes.

from proposals.

I support efforts to reduce overhead and having a clear and standardized template for how to create compensation requests will definitely help. I can't really tell if this is the best way forward but let's try it.

from proposals.

@cbeams wrote :

Where is the "right" number above? I don't pretend to know, and I would prefer if we don't collectively pretend to know either. ... I think it's good to have this conversation, but I'd advocate for letting things play out from here for the next few months and seeing how it goes.

I don’t pretend to know the number either.
But I think :
1/ - we should collectively try to estimate the number of safe special nodes necessary for having a safe infrastructure, which in turn may, or not, lead to a better estimate of a budget to reach the objective.
I may be wrong but it seems that the number of nodes is low, the number of safe nodes is very low, the number of nodes is increasing rather slowly.
Of course we may let things play out by themselves for another new bunch of month, but the tunnel could also be digged from the other side. Ie directly increase the allocated budget (which may well be a necessary but not sufficient condition) and see what happens. If in october 2018, Bisq has 50 pricenodes because offered compensation is too high, nothing is engraved in stone, and the allocated budget may be reduced.
2/ the number should be the same for an exactly similar task. If we want to converge to automatizing compensation, this seems rather necessary. (Some standardization may also help to reduce the comp. request burden).
3/ in order to estimate the number, there is not only the hard cost + soft cost. There is also the risk cost + the safety costs. At the moment the mood seems to be that everything is fine under the blue sky. This blue sky hypothesis is/was certainly a pertinent hypothesis to begin with (when Bisq is/was small), but if Bisq continues to grow, imo this hypothesis is fading, and the project should adapt accordingly.

from proposals.

@bisq-network/desktop-maintainers. The primary duties of this role include merging pull requests after sufficient review, triaging incoming issues, and performing releases. If, as the roles doc stipulates, we separate out development and review activities from this role, and itemize them as normal (non-role) contributions, do you still feel it would be necessary to "track in detail" your efforts on this role?

The problem is that I track my development efforts atm per release including the efforts as desktop maintainer (merging PR, issues management, release tasks) and reviewing PRs. So the issue is not so much about tracking the exact efforts of the desktop-maintainer role, but more on separating it from every other contribution in the bisq-desktop repository, as I'm working on multiple bug fixes & features in parallel. Of course we don't want to value work based on time spent, but it helps to put a price label on something. Doing it just after you've completed work, results in my experience in either under- over overvaluing of completed work packages.

And that is just one of the roles I'm having (of course it is the one which consumes most of my time). So for every other role I have to track the efforts there as well, to be able to come up with a proper valuation. Of course maybe we can find a monthly compensation value for each role, which would make it easier to create compensation requests each month. I just didn't used a flat fee each month for each roles so far as the time that I'm able to contribute varies a lot between months atm.

from proposals.

@HarryMacfinned, re (1), the main problem right now is not having "more nodes". We don't need dozens of seednodes, and we don't need dozens of pricenodes or btcnodes either. What we do need is for the nodes we have to be better distributed amongst trustworthy contributors. Right now, a small number of people are running most of those nodes. Fundamentally what we need are more dedicated contributors to take on these trusted roles.

Re (2), it is not obvious to me that "the number should be the same for an exactly similar task". People have different hosting costs and different estimations of the value of their own time and effort. Over time, it is reasonable to expect that compensation for multiple contributors playing the same role should converge toward the same amount, but it may never be exactly the same. This is a feature, not a bug. If the amount must be the same, then there must be some authority for role owners to appeal to in order to change that fixed amount. There is no one doing such budgeting here. There are only stakeholders voting on whether the amount requested for a given unit of work is reasonable to them. In this way, the amount that a given role is compensated can change over time in a decentralized way, as a function of what stakeholders are willing to green-light with their votes, as opposed to changing based on central planning.

Re (3), I am fine to consider risk and safety, i.e. "hazard pay" as part of "soft costs". It just serves to underscore the point above, which is that different contributors will have different estimations of what running a trusted node is worth. We should continue to let contributors ask for what they see fit, and let things get sorted out on their own through the normal voting process. And with regard to your comment that "At the moment the mood seems to be that everything is fine under the blue sky", I disagree. A very large amount of effort is going into developing processes and technology that support a scalable decentralized future for Bisq funding, governance and network operations. Everything we're doing toward this end is in anticipation of a much more adversarial future. This is made clear in the Phase Zero document. Indeed, if anything, we are putting too much effort toward decentralization right now, given that our primary constraint continues to be lack of developers.

from proposals.

@ripcurlx, that all makes sense. Happy to see this change get phased in over the next couple compensation request votes as people are able to do it. I'm sure it will be a process to refine it. Thanks.

from proposals.

@cbeams wrote :

Everything we're doing toward this end is in anticipation of a much more adversarial future. This is made clear in the Phase Zero document. Indeed, if anything, we are putting too much effort toward decentralization right now, given that our primary constraint continues to be lack of developers.

I respectfully globally disagree.
Yes we are putting great effort toward decentralization for bisq-core and bisq-desktop.
And that's very ok.
But, on the other hand, for convenience reason, Bisq is surrounded with far too many unsafe and unsecure tools.
I'll compare Bisq with a flower chalice ... surrounded by dangerous petals.
And those petals are often an access (or first access) to Bisq.

We should work on adding safe petals to Bisq and even replacing the unsafe petals when possible.

I believe also that, given that what Bisq's users search is safety, the unsafe tools, how popular they are in the main world, have in fact a negative impact regarding Bisq's user world (which is different from main world).
So they are in fact slowing down the growth.

On the related point of
"Fundamentally what we need are more dedicated contributors to take on these trusted roles."
I'll add the fundamental qualifying safe.
As so many sad examples proved it, a contributor who is exposed is not only of no use in the long-run, but may (and often is) even used against other contributors.
Running things (nodes/repos/etc) in an unsafe way is practical atm, but may hurt very deeply in an adversarial future.

I know that all of this has costs (less convenience etc), and that we are few,
but we should better deal with it too early than too late.
Each day Bisq grows, each day the risks grows also.

from proposals.

My two cents. I'm not looking for Bisq to protect me. I make it my responsibility to enable the desired privacy and security measures for myself. Any exposure potential with Bisq is very well communicated from my prospective. Most people don't have a clue or a concern about using the internet anonymously. Simply put, you can't fix stupid.

from proposals.

I've labeled this as approved, but am leaving it open for comment as the current compensation request voting round is the first time (some of us) are trying this and there may be further feedback.

from proposals.

I think it is ok now to close. If we see contributors not following the advice we can point them to the closed issue here as well.

from proposals.