search

dwyl / dwylbot

:robot: Automating our GitHub Workflow to improve team communication/collaboration and reduce tedious repetition!
28 stars 7 forks source link

How to notify errors on issues? #59

Closed SimonLab closed 7 years ago

SimonLab commented 7 years ago

The first idea is to add a comment on the issue for each error detected. This can become very noisy and annoying for the users. Another idea is to have a "dwylbot-error" label added on the issue if something is wrong. This allow the users to know quickly if the issue is not well formated. We could also update/edit the dwylbot comment to add or remove description errors, so only having one comment instead of multiple (one per error). I think this solution might be a bit more user friendly but this need to be tested. @markwilliamfirth @iteles @nelsonic any thought on this?

nelsonic commented 7 years ago

@SimonLab agree that commenting in the case of errors can be "noisy". 👍 and the more "noisy" something is, the more likely it will be "muted" (ignored!) 🔇

Adding a dwylbot-error Label without detailed error is kinda useless because it's noise without insight.

What is an "Error"...?

I think it's worth taking a "step back" and understanding what an "error" actually is ... Is an "error" when the dwylbot script/app is unable to process the issue? Or is it simply when a person has not followed the contribution workflow?

We should clearly define what an "error" is. and we should have a "scale" of words to describe the degrees of "errors" in our workflow. and the messaging needs to reflect the "severity" of the "error". we don't want complete beginners joining the @dwyl community to be "scalded" for forgetting to include an issue number in their commit message (for example) but we do want to politely remind them why it's important/useful to do so.

Update a Single Comment or Post New Comment(s) Each Time?

Initially I thought that updating the dwylbot comment would be a good idea ... but on further reflection if an issue/story has many (human) interactions and only one dwylbot comment then the human(s) will easily get confused as to what the "latest" status is. It's better to have a fresh dwylbot comment each time in chronological order.

SimonLab commented 7 years ago

thanks for your feedback @nelsonic ! agree we need to define what is a dwylbot error and their different type and severity. I was indeed referencing a contribution workflow error (ex: an issue with the label "in-progress" but without any assignees). Agree to try with adding a dwylbot comment for each break of the contribution workflow. I still think a "dwylbot-error" label can be useful (not on its own but linked to comments) to quickly identify the issues that are not "valid".

nelsonic commented 7 years ago

@SimonLab given than our plan with dwylbot is to make it fairly "generic", having a dwylbot-error label on a client project might be unwelcome. By contrast if we call the label something like workflow-step-skipped it can be used on client projects and by other people/organisations.

Note: the question of the label should be addressed by someone who has more time to think about this. But having something starting with a w means it's "out-of-the-way" alphabetically. (I don't like having to "scroll" through our labels when I'm picking them...)

ghost commented 7 years ago

@simonlab in addition to comments let's apply a workflow-error label whenever there is an error for now, test it and then we can change it in future if necessary 👍