Readme amends #115
Readme amends #115
Conversation
Cleop
commented
Jun 21, 2017
•
Cleop
commented
- Grammar/ typo edits to README, README: grammatical / copy edits #113
- Move backtick in dwylbot comment for consistent styling, Amend markdown error on time estimation dwylbot comment #114
- Adds table of rules/actions to README, update readme with list of rules and comments #105
Codecov Report
@@ Coverage Diff @@
## master #115 +/- ##
=======================================
Coverage 98.08% 98.08%
=======================================
Files 22 22
Lines 157 157
=======================================
Hits 154 154
Misses 3 3
Continue to review full report at Codecov.
|
README.md
Outdated
|
|
||
| | Category | Rule | dwylbot comments | Labels changed | | ||
| |---------------|------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------| | ||
| | Pull Requests | "awaiting-review" and a merge conflict, #64 | :warning: @username, the pull request has a **merge conflict**., Please resolve the conflict and reassign when ready :+1:, Thanks! | remove "awaiting-review" and replace with "merge-conflicts". @username assigned. | |
There was a problem hiding this comment.
The issue number ie: #64 are not linked to the issues, we might need to precise the full url?
|
|
||
| We've devised a set of rules and actions to respond to these problems, they look like this: | ||
|
|
||
| | Category | Rule | dwylbot comments | Labels changed | |
There was a problem hiding this comment.
The format looks nice 👍
I think we should also add a column "trigger" which explain what trigger dwylbot, ex: "on PR open", "on adding the in-progress label",...
There was a problem hiding this comment.
That's what I had tried to include in the 'rule' column, would you like me to rephrase them?
I think I called it 'rule' rather than say 'trigger' because in the readme I'm thinking about it from a user over developer perspective... the user wants to know what our gitflow rules are to decide whether they want to use dwylbot because it's useful/relevant to their own gitflow.
There was a problem hiding this comment.
I think rules and triggers are slightly different (but sometime they can be the same).
For me the rule is all the conditions the issue/pr must satisfied. The trigger is what is going to start the verification of the rule. Different type of triggers can also start the same rule.
For example for the rule that check if an issue has the description will only be triggered when the issue is created and dwylbot shouldn't run the rule on other triggers, ie we don't want the rule when we close the issue, or when someone change a label,...
Let me know what you think, maybe I'm going to much in details for the readme but I think it can help users to reproduce a error if they need to test it.
There was a problem hiding this comment.
Right, that's interesting. So in theory, say I created an issue with a blank description and dwylbot warned me against this. I then continue working on the issue and adding labels to it/ closing it etc. - I should only receive the warning from dwylbot that I should give my issue a description once, when I first created it? I won't get a reminder every time I do another action on the issue?
I suppose from a technical perspective that would mean you'd have to be doing more evaluations on each post event because any of the rules might apply at that time if the user had failed to act upon the first warning.
