Role owners should itemize compensation on a per-role basis in monthly compensation requests

[cbeams]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Since we began submitting and voting on compensation requests more than 9 months ago, @bisq-network/role-owners have taken various approaches to requesting compensation for their efforts.

Generally, those who have "hard costs" such as hosting fees always request that amount as part of their overall compensation request, but the "softer costs" of time and effort involved in carrying out the duties of their role have not been well-accounted for.

I have just published a new 'Roles' in bisq-network/bisq-docs#46 that lays out specific instructions for how role owners should account for these costs as part of their monthly reporting and compensation requests. These instructions can be found in the https://docs.bisq.network/roles.html#compensation section. Please read this section and respond here with any questions or clarifications. As per usual, please also react to this proposal with a 👍, 😕 or 👎 as appropriate.

The goal of getting this document and proposal out now (July 10th) is to be able to start following this new practice in next month's Aug 1st–3rd compensation voting.

For those who play a repository maintainer role, please also see the https://docs.bisq.network/roles.html#maintainer-duties section and pay special attention to the "Maintainers are not Developers or Reviewers" admonition. Separating PR development and review from the strictly defined work of maintenance is an important part of keeping role compensation accounting simple and largely repeatable from month to month.

As a final note, I want to acknowledge the overhead that dealing with compensation requests and monthly reporting causes for people, especially those who still own a large number of roles. My goal is to refine these processes until they are as smooth and efficient as they possibly can be, but doing so requires constant attention and refinement along the way. It's extremely important to the future of BSQ that users understand and have confidence in the way we account for our efforts as contributors and role owners. Thanks everyone for helping to achieve this goal. Please provide whatever feedback you think will accelerate or improve the process.

[ripcurlx]

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.

[ghost]

+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.

[cbeams]

@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?

[cbeams]

@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.

[sqrrm]

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.

[ghost]

@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.

[ripcurlx]

@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.

[cbeams]

@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.

[cbeams]

@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.

[cbeams]

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.

[ManfredKarrer]

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.