[bisq-network/projects] Establish compensation request review process (#7)
notifications at github.com
Mon Feb 17 15:39:23 UTC 2020
> 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.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bisq-github