You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 22, 2023. It is now read-only.
Documentation is an essential part of good software, thus it deserves an own area within a release statement.
I see 3 options for naming the new modification type:
docs
documentation
or both with docs being alias of documentation
I like docs best. It is short and commonly used. documentation sound more official but is a quite long word. Having both options will bloat up the spec without much use.
Acceptance Criteria
Add specification of new modification type for labeling documentation changes
The text was updated successfully, but these errors were encountered:
title: Release Notes of an awesome projectreleases:
- version: Unreleasedadded:
- Add some fancy feature.docs:
- Add an [example](examples/fancy-feature/) on how to use fancy feature.
- Fixed api status code description of some legacy feature.
- Setup code of conduct and introduce getting started tutorial.
- Update license year in all code doc block annotations.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Documentation is an essential part of good software, thus it deserves an own area within a release statement.
I see 3 options for naming the new modification type:
I like
docs
best. It is short and commonly used.documentation
sound more official but is a quite long word. Having both options will bloat up the spec without much use.Acceptance Criteria
The text was updated successfully, but these errors were encountered: