[bisq-network/support] based on discussion on kb (#336)

Chris Beams notifications at github.com
Fri Feb 7 16:06:09 UTC 2020


cbeams requested changes on this pull request.

Please see the specific review comments, but in general, please also:

- [ ] Review and adhere to the guidelines at https://github.com/bisq-network/bisq/blob/master/CONTRIBUTING.md#write-well-formed-commit-messages.
- [ ] Review GitHub's documentation on [how to create issue templates](https://help.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository) and pay special attention to how to write the YAML front matter that drives the issue template chooser. Right now, this issue template doesn't even show up as an option when creating a new issue, because this metadata is not in place. You can follow suit with how @KanoczTomas put together the fee reimbursement issue template YAML front matter at https://github.com/bisq-network/support/blob/master/.github/ISSUE_TEMPLATE/reimbursement-template.md.

Note that the check that failed on this PR was not your fault. I've fixed the underlying cause, and when you push changes to this PR branch, you should see no further failures.

Thanks.

> @@ -1,17 +1,7 @@
 <if contains sensitive info please use the encryption feature on Keybase>

- [ ] Please use HTML comments, e.g. <!-- ... -->
- [ ] Please do not put this at the top of the file. For parsing reasons as discussed in Keybase chat.

> +user_request_block_height:
+agent_response_block_height:
+resolution_block_height:
+support_type: <L1 / L2>

What I suggested in Keybase was the following:
```
user_request_date: 2020-02-06T18:35:52Z
agent_response_date: 2020-02-06T18:39:01Z

Lorem ipsum dolor sit amet (description text)
```

- [ ] You acknowledged that dropping block height makes sense, but it's still here. Please change it to what's seen above.
- [ ] I mentioned in chat that the resolution date can be dropped because we can infer it from the issue close date. Pleaes remove.
- [ ] I read your comment about keeping the support type field, but I really do not want to include it. It's a likely example of YAGNI (you ain't gonna need it). Support agents are extremely likely to fail to fill this out and/or fail to come back and change it when it gets escalated to L2. It's just busy work, and will end up being a broken window in the system, and we have no requirement for it for our very basic metrics we're trying to track. Please remove.

> -brief-description: 
-
-started_at_UTC: <yyyy-mm-dd hh:mm>
-
-started_at_block:
-
-closed_at_UTC: <yyyy-mm-dd hh:mm>
-
-closed_at_block:
-
-solution: 
-
-github-issue: 
-
-support_type: 
+<Prose describing the case, and (if already known), its solution; otherwise the solution summary comes with the closing comment. This prose includes any references to related issues e.g. bisq-network\/bisq#1234>

Again, please use HTML comments. When doing so, there should be no need to escape the issue reference.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/support/pull/336#pullrequestreview-355252981
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200207/349da8d8/attachment.html>


More information about the bisq-github mailing list