Apply suggestions from code review
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
This commit is contained in:
+1
-1
@@ -250,7 +250,7 @@ Here are some important do's and don'ts when writing changesets:
|
||||
|
||||
### Changeset messages should describe user-facing behavior in plain language
|
||||
|
||||
Changeset messages are read by Backstage adopters, not contributors. They should describe what changed from the user's perspective, not how the code was changed internally. Never reference internal implementation details such as internal function names, class names, variable names, or other code symbols that are not part of the public API. Public API names (exported functions, components, types, etc.) are fine to mention, but internal code structure should not appear in changeset messages.
|
||||
Changeset messages are read by Backstage adopters, not contributors. They should describe what changed from the user's perspective, not how the code was changed internally. Never reference internal implementation details such as function names, class names, variable names, or other code symbols that are not part of the public API. Public API names (exported functions, components, types, etc.) are fine to mention, but internal code structure should not appear in changeset messages.
|
||||
|
||||
### Changeset should give a clear description to what has changed
|
||||
|
||||
|
||||
Reference in New Issue
Block a user