Document error message conventions in contributing guide

[KrishnaIyer]

Summary

Document error message conventions in contributing guide

Why do we need this?

I keep getting review comments on what (not) to do in error messages but I don't find such conventions documented.

What is already there? What do you see now?

The front-end Design guide has a section on error messages; https://github.com/TheThingsNetwork/lorawan-stack/blob/v3.18/DESIGN.md#error-messages

What is missing? What do you want to see?

Add a similar one for the backend.

Environment

TTS v3.17.2

How do you propose to implement this?

Add an error messages section to our CONTRIBUTING.md. Some common things I've encountered

• Error tense
• Punctuations
• Not using failed to or _failed

How do you propose to test this?

NA

Can you do this yourself and submit a Pull Request?

Can review.

[johanstokking]

From my understanding:

• every error implies something went wrong. So there is no need to use generic prefixes en suffixes like could_not_... and ..._failed and "could not ..." "failed to ..." in error codes and messages respectively
• specific errors, like invalid_{something} and {something}_not_found are permitted
• error codes should be meaningful in the namespace, which is the package name. So validation is perfectly fine in the pkg/config namespace
• the code and the message should should use the same terms so they belong together
• no formatting in error messages. All variable data must be passed as a) field, b) public attribute or c) not in the error but logged as log field
• all fields should be in backticks, except literal error messages that are copied in (e.g. from some external system). The reason being that the backticks are shown as literal and that doesn't look good with full error messages