client
client copied to clipboard
knative
Consistency in success and error messages
At the moment we have some inconsistencies when it comes to messages. There are also no written rules how messages should look like.
Examples:
Service 'k8s-event-display' successfully created in namespace 'default'.
Service 'k8s-event-display' updated in namespace 'default'.
services.serving.knative.dev "k8s-event-display" already exists
Issues:
- Different quoting (reason: Error message was given through directly)
- "successfully created" vs. "updated". I'm all for removing "successfully" everywhere as this is a tautology.
- "Service" vs. "services.serving.knative.dev". The latter comes from an error message directly handed through. I think we should massage this message and map it to a Service
- dot at the end of the sentence vs. not. Again, because error message don't have dots vs. our messages that have dots at the end.
Of course, this can not be fully automatable checked, but we could:
- Write a style guide which could be used as a reference in PR reviews
- For some rules we can write an automatic translator. E.g we could have a
prepareErrorMessage(err)which would upercase the the first letter, translates CRDs names and adds a dot to the end. And maybe even an "ERROR: " prefix.
This all mostly sounds reasonable to me. Though I am not for automatic translator for messages at this point. Rather a linter (update to the current /lint) that could point out deviations from style guide would be nice. Especially since this could help guarantee consistency now and in future. Best.
@maximilien: You must be a member of the knative/knative-milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility.
In response to this:
/milestone v0.8.0
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@rhuss: You must be a member of the knative/knative-milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility.
In response to this:
/milestone v0.8.0
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.