Establish compensation request review process about projects HOT 19 CLOSED

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

from projects.

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.

from projects.

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

from projects.

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

from projects.

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

from projects.

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

from projects.

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

from projects.

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.

from projects.

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.

from projects.

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

from projects.

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.

from projects.

Great process, this seems fair to me.

from projects.

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

from projects.

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.

from projects.

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.

from projects.

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.

from projects.

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.

from projects.

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.

from projects.

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

from projects.