Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Establish compensation request review process #7

Closed
32 tasks done
cbeams opened this issue Feb 10, 2020 · 19 comments
Closed
32 tasks done

Establish compensation request review process #7

cbeams opened this issue Feb 10, 2020 · 19 comments

Comments

@cbeams
Copy link
Member

cbeams commented Feb 10, 2020

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

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
Copy link
Member Author

cbeams commented Feb 10, 2020

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:

  1. Team lead review
  2. Submit compensation request DAO proposals
  3. Close compensation requests after voting

@m52go
Copy link

m52go commented Feb 10, 2020

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
Copy link
Member Author

cbeams commented Feb 10, 2020

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
Copy link
Member Author

cbeams commented Feb 10, 2020

@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
Copy link
Member

wiz commented Feb 11, 2020

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
Copy link
Member

wiz commented Feb 11, 2020

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.
Screen Shot 2020-02-10 at 23 14 44

@m52go
Copy link

m52go commented Feb 11, 2020

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

@MwithM
Copy link

MwithM commented Feb 11, 2020

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
Copy link

leo816 commented Feb 11, 2020

Great process, this seems fair to me.

@cbeams
Copy link
Member Author

cbeams commented Feb 11, 2020

@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
Copy link
Member Author

cbeams commented Feb 11, 2020

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

image

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
Copy link
Member Author

cbeams commented Feb 11, 2020

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 cbeams changed the title Establish team lead compensation request review process Establish compensation request review process Feb 17, 2020
@cbeams cbeams transferred this issue from bisq-network/admin Feb 17, 2020
@cbeams cbeams added this to In progress in Master Projects Board Feb 17, 2020
@cbeams
Copy link
Member Author

cbeams commented Feb 17, 2020

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
Copy link

m52go commented Feb 17, 2020

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
Copy link
Member Author

cbeams commented Feb 17, 2020

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
Copy link
Member Author

cbeams commented Feb 17, 2020

@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
Copy link

MwithM commented Feb 18, 2020

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
Copy link
Member Author

cbeams commented Feb 19, 2020

@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 cbeams added this to the Cycle 10 milestone Feb 20, 2020
cbeams added a commit to cbeams/bisq-docs that referenced this issue Feb 21, 2020
@cbeams cbeams added the was:delivered bisq.wiki/Project_management#Closing_as_delivered label Feb 25, 2020
@cbeams
Copy link
Member Author

cbeams commented Feb 25, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
to:Improve Mgmt was:delivered bisq.wiki/Project_management#Closing_as_delivered
Development

No branches or pull requests

6 participants