Establish compensation request review process

[cbeams]

Board: https://github.com/orgs/bisq-network/projects/13

@bisq-network/team-leads and @bisq-network/compensation-maintainers, please read and respond to this asap, as it deals with the orderly processing of Cycle 10 compensation requests, thanks.

Criteria for delivery

• All Cycle 10 compensation requests submitted by the Monday Feb 10th deadline have been reviewed by their respective team leads
• Review feedback has been acknowledged and applied by each contributor
• The Compensation board has been used to facilitate the review process
• The process is documented on the wiki and ready to go for Cycle 11
• The new process has been announced to @bisq-network/dao
• Existing compensation documentation has been updated to link to the process

Tasks

• @m52go to ask all contributors to submit their compensation request GitHub issues one week prior to the end of the proposal phase in order to allow for team lead review and subsequent adjustments prior to submitting the proposal via the DAO (Clean up roles and bonding #9)
• @cbeams to put together Compensation board
• @cbeams to assign compensation requests to team leads as appropriate
• @cbeams to write up proposed review process (see below)
• @cbeams to grant write access to bisq-network/compensation to all @bisq-network/team-leads such that they are able to transition issues on the Compensation Requests board
• @bisq-network/team-leads to review proposed process and provide feedback
  • @m52go
  • @ripcurlx
  • @wiz
  • @leo816 (with an eye toward taking over this aspect of the support team lead role)
• @bisq-network/compensation-maintainers to review proposed process and provide feedback
  • @MwithM
• @bisq-network/team-leads to review their respective team members' compensation requests per the process
• Contributors to submit proposals to dao per the process
• @bisq-network/team-leads to transition issues to Proposal Submitted as each proposal is submitted
• @cbeams to migrate compensation repo-level compensation board to new org-level compensation board and update links / documentation here appropriately (new as of Feb 17)
• @cbeams to close the old compensation repo-level board and add a comment here to explain the change
• Document this process on the wiki (Document compensation review process in wiki admin#32)
  • @cbeams to create https://bisq.wiki/Compensation article containing an outline of the process proposed below as well as transcription of several sections to get the ball rolling
  • @cbeams to ask @MwithM to complete writing that article in his role as compensation maintainer and create an issue to track that work (Document compensation review process in wiki admin#32)
  • @MwithM to follow up on that issue
• @bisq-network/compensation-maintainers to close compensation requests with appropriate labels when voting is complete (Close all Cycle 10 compensation requests when vote reveal is complete admin#40)
• @cbeams to announce the new process to @bisq-network/dao (https://github.com/orgs/bisq-network/teams/dao/discussions/4)
• @cbeams to update existing documentation at https://docs.bisq.network/compensation.html to reflect these changes
  • PR submitted at Document the compensation review process bisq-docs#194
  • PR merged

Proposed Process

Submit compensation request GitHub issues

Contributors who wish to request compensation for the current cycle should submit a compensation request GitHub issue no later than 1 week prior to the end of the current cycle proposal phase.

WIP (Work in Progress) compensation requests may be submitted with a [WIP] prefix in the title, e.g. [WIP] For Cycle 10.

When a contributor removes the [WIP] prefix from a compensation request issue, they should also add a comment stating This issue is ready for team lead review.

Add new compensation requests to the Compensation board

@bisq-network/compensation-maintainers should be watching the bisq-network/compensation repository, and upon being notified of a new compensation request issue, should add the issue as to the Compensation board, putting [WIP] requests in the In Progress column, and putting non-WIP requests in the In Review column.

When a compensation request issue is transitioned to the In Review column, @bisq-network/compensation-maintainers should also assign the appropriate team lead(s) to that issue. The compensation maintainer must actually look at the content of the request and determine which team lead or leads are responsible. A given compensation request may include dev and growth work, for example, and so both @ripcurlx and @m52go should be assigned to review. When in doubt, the compensation maintainer should simply post a comment in the compensation request issue asking which team leads are appropriate.

Team lead review

When a team lead is assigned to a compensation request issue, they should propmtly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as a appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should (a) transition the issue to the Review Complete column and (b) add a comment asking the contributor to submit their DAO proposal and to post the resulting TXID in a comment.

Submit compensation request DAO proposals

Once a compensation request has been transitioned to the Review Complete column, the contributor is free to submit their request as a DAO proposal per the usual process. When complete, the contributor should add a comment that reads DAO proposal transaction ID: <txid>.

When @bisq-network/compensation-maintainers or @bisq-network/team-leads see the DAO proposal transaction ID comment, they should transition the issue to the Proposal Submitted column.

Close compensation requests after voting

Per the usual process, when the vote reveal phase is complete, @bisq-network/compensation-maintainers should close each proposal in the Proposal Submitted column appropriately, indicating via comment and label whether the request was:approved or was:rejected.
When a team lead is assigned

Notes

When the above process has been completed, the Compensation board should be empty save for any new [WIP] compensation requests for future cycles that may have come in during the process.

The process above assumes prompt action from both @bisq-network/compensation-maintainers and @bisq-network/team-leads with regard to responding to issue state changes, transitioning issues on the board appropriately, etc. If anyone has doubts about their ability to do this in a timely fashion (same-day), please speak up.

[cbeams]

Note that the first two sections of the process:

1. Submit compensation request GitHub issues
2. Add new compensation requests to the Compensation Requests board

have already been completed for Cycle 10. What's needed to complete the process for Cycle 10 are the remaining three sections:

3. Team lead review
4. Submit compensation request DAO proposals
5. Close compensation requests after voting

[m52go]

This seems reasonable to me, but I don't understand the role of the project board. Could we achieve the purpose of the board with issue tags (i.e., in-progress, awaiting-review, etc)?

[cbeams]

The board is for better visual management and to make the process/workflow quite explicit. This reminds me to give team-leads write access to the compensation repository so that we can all transition the issues as discussed. I would say let's try it with the board this time around, and if it seems like overkill we consider dropping it in a later cycle.

[cbeams]

@bisq-network/team-leads and @bisq-network/compensation-maintainers, please check the box next to your name in the description comment when you've reviewed this and provided feedback (if any).

[wiz]

Great process. However, maybe we need to be more clear on who is approving/reviewing which line items in the compensation request. It would be cleaner to only submit one compensation request per team but that might be too much paperwork.

[wiz]

Also, for best practices please require contributors to post TXID of their DAO proposal as the final step in the process, to discourage impersonation scams. Remember, several of us have previously been impersonated in slack, email, etc.

[m52go]

@cbeams which team lead is reviewing compensation requests for support? Is it you?

[MwithM]

If there's disagreement on a rejected request, where should discussion occur? Here or Keybase #compensation channel? I was leaving rejected requests open for a week or so for discussion.
I suppose that rejected compensation requests will be very rare, as they will be already reviewed by team leaders, meaning it's a delivered task, but just in case.

[leo816]

Great process, this seems fair to me.

[cbeams]

@wiz wrote:

for best practices please require contributors to post TXID of their DAO proposal as the final step in the process

From the Submit compensation request DAO proposals section:

When complete, the contributor should add a comment that reads DAO proposal transaction ID: <txid>.

@m52go wrote:

@cbeams which team lead is reviewing compensation requests for support? Is it you?

Yes, me, with the goal that @leo816 takes over in a subsequent cycle. My assignments on the board should already reflect this.

@leo816 wrote:

Great process, this seems fair to me.

Great. I've checked the box next to your name on your behalf.

@MwithM wrote:

If there's disagreement on a rejected request, where should discussion occur? [...] I was leaving rejected requests open for a week or so for discussion.

Comments / discussion can continue on an issue even after it is closed. I'd say it makes sense to close it immediately on vote reveal as was:approved or was:rejected, as nothing is going to change that fact, but people are free to continue conversation about it on the original issue. Seems like the most appropriate and in-context place to do it in any case.

[cbeams]

@bisq-network/team-leads, I just made the following change:

You can see an example of how @wiz did this at bisq-network/compensation#481 (comment). It's important to add a comment to this effect, because otherwise the contributor won't get any signal that the review is in fact complete, which would likely lead to a delay in getting their DAO proposal submitted.

Note that I do NOT think it's important that we actually assign the issue to the contributor (as @wiz mentioned, but did not actually do, in his comment). Contributors know that the issue is theirs to manage through to completion and they don't need assignment metadata to make that clear. @wiz, you removed yourself as assignee when you transitioned the issue to Reviewed by Team Lead, and I think it's probably best to leave yourself assigned. It generally helps everyone know who was responsible for the review, and it also leaves that metadata in place for when you're doing GH Issues queries to figure out what all you did today / last cycle / etc.

[cbeams]

Heads up, I just renamed Waiting for Team Lead Review to In Review and renamed Reviewed by Team Lead to Review Complete.

The reason for the change to In Review is that issues in this column aren't always strictly waiting for the team lead. They may be waiting for the contributor to respond to team lead feedback. In any case, all such issues are "in review" until they're transitioned to Review Complete. See my latest edit diff in the description for details.

[cbeams]

UPDATE: I've just migrated the compensation requests board from being a project within the bisq-network/compensation repository to being an org-level project at https://github.com/orgs/bisq-network/projects/5. I have updated the relevant links and text in the description of this issue, and everything else process-wise remains the same. This change is part of a larger effort that I'll communicate more on later.

[m52go]

May I suggest we standardize the compensation request format such that parsing them can be automated?

I mention it here, because if we did it, ensuring each request conformed to the standard would be a part of this review process. But let me know if it's better discussed elsewhere.

It's time-consuming and error-prone to add issuances from each compensation request by hand, which is something we'll need to do on a regular basis for budgeting and reporting going forward. Even if most people tend to work within 1 function, some don't, and regardless, being able to quickly discern how money was allocated within a function will also be important.

[cbeams]

UPDATE: It looks as if the process worked well for us to get through reviewing Cycle 10 requests. What remains to consider this project delivered is to document the process on the wiki. I've started that process and have asked @MwithM to complete it in bisq-network/admin#32.

Thanks everyone for your participation, and if you have further feedback or tweaks to suggest, please keep them coming. Now is the time to get them in before Cycle 11's request submission deadline.

[cbeams]

@m52go wrote:

May I suggest we standardize the compensation request format such that parsing them can be automated?

Certainly. This is similar to what we're rolling out with support case tracking issues, to automate the process of extracting metrics from them.

In any case, it should be managed as it's own little project, because it'll be a multi-task effort, including:

• Writing the script to extract and parse compensation request issue data from the GitHub API
  • The script should query for issues titled "For Cycle X" in a closed state with the was:approved label.
• Defining a parser-friendly metadata format for compensation request issues that probably looks like key: value pairs, e.g.
  • BSQ_requested: <integer>
  • DAO_team: <[admin|dev|growth|ops|support]>
  • Note that the above are just a sketch, and not sufficient because it'll need to be BSQ requested per DAO team in order to effectively automate what you want to automate. YAML will work well as a format here.
• Testing that parser
• Publishing the parser code and determining when, how and by whom it is run
• Documenting this process change in the wiki page mentioned in my comment immediately above.
• Communicating this change to @bisq-network/dao when all the above are in place.

@m52go, feel free to create a project issue for this in the new https://github.com/bisq-network/projects repository, and follow suit with what I've been doing there. Not all issues are fleshed out yet, but generally, I'm doing three to four sections in the issue description:

• Description (a brief synopsis of the project)
• Rationale (why it's important to do this, what problem it's solving)
• Criteria for delivery (what outcomes / end state must be present in order to consider the project delivered)
• Tasks (a breakdown of specific tasks that must be carried out in order to achieve the delivery criteria)

I'll soon document all of this properly, but since it's a work in progress, I'm just sketching it out here.

The main point of this approach is to acknowledge that almost everything we do that is worth doing requires multiple steps, often from multiple contributors across multiple teams, and is therefore best thought of and managed to completion as a project.

In any case, I like what you're suggesting to do here with automation, and it's a good guinea pig for having someone else try out the emerging project management infrastructure and process.

I'll note that I don't think this is in any way required to get done in time for Cycle 11 compensation requests. Indeed some WIP requests have already been coming in. Having it rolled out by the end of Cycle 11, being ready for Cycle 12 requests seems more reasonable to me.

[MwithM]

When the above process has been completed, the Compensation board should be empty save for any new [WIP] compensation requests for future cycles that may have come in during the process.

Should Compensation Maintainer wait a few days before cleaning the board? Otherwise, the "closed" column is pretty irrelevant.
I would prefer to wait something like 5 days before cleaning the "closed" column.

I performed some additions to this process at the Wiki that I have to share:
I thought that it might be nice to announce deadlines for submitting reviews and submitting DAO proposals at Compensation Board, with a note at the "In review" and "Proposal submitted" columns, and that BSQ rates for the current cycle announcement will be a pinned issue at Compensation repository.
You can see how deadline announcements work at the current Compensation board with Cycle 10 data.

[cbeams]

@MwithM wrote:

Should Compensation Maintainer wait a few days before cleaning the board? Otherwise, the "closed" column is pretty irrelevant.
I would prefer to wait something like 5 days before cleaning the "closed" column.

Echoing what I wrote above in #7 (comment), I believe the compensation maintainer should close issues with the appropriate was:accepted / was:rejected label and a corresponding comment as soon as possible after the vote reveal. This simply reflects the real state of the compensation request. At that point, the issues will automatically transition to the Done column, where they can stay in place for 5 days if you like, or perhaps until the next cycle's issue submission deadline, at which point the contents of the Done column can be Archived (this is a feature of GitHub project boards, not sure whether you're aware of it). This is what I meant by leaving the board "clean" for the next cycle. Again, the main point here is that comments and discussion can still occur on closed issues, there's nothing stopping that, but it's better to reflect that they were accepted or rejected as soon as we know the results.

• If that works for you, please update the documentation accordingly and mention that you've done so here. Thanks.

I thought that it might be nice to announce deadlines for submitting reviews and submitting DAO proposals at Compensation Board, with a note at the "In review" and "Proposal submitted" columns, and that BSQ rates for the current cycle announcement will be a pinned issue at Compensation repository.

I think that's a nice use of the "Card" feature of GitHub project boards, good idea. I do think we also need to announce the compensation request issue deadline and BSQ exchange rate outside the board as well, though. I see that you've mentioned this on the wiki with the following line from https://bisq.wiki/Compensation#Compensation_Maintainer:

The exact date and reminders will be announced at @bisq-network/dao team and the Compensation board

... but I just want to double-check it here.

[cbeams]

Closing as delivered. Thanks to everyone who participated in this project!