How to notify errors on issues?

[SimonLab]

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]

@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]

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]

@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]

@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 👍