@@ -26,7 +26,8 @@ conventions and process used during a release by both groups.
26
26
## For documentation contributors
27
27
28
28
In general, documentation contributors don't write content from scratch for a release.
29
- Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready.
29
+ Instead, they work with the SIG creating a new feature to refine the draft documentation
30
+ and make it release ready.
30
31
31
32
After you've chosen a feature to document or assist, ask about it in the ` #sig-docs `
32
33
Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the
@@ -106,11 +107,9 @@ deadlines.
106
107
issue with a link to the PR to notify the docs person managing this release that
107
108
the feature docs are coming and should be tracked for the release.
108
109
109
- If your feature does not need
110
- any documentation changes, make sure the sig-release team knows this, by
111
- mentioning it in the ` #sig-release ` Slack channel. If the feature does need
112
- documentation but the PR is not created, the feature may be removed from the
113
- milestone.
110
+ If your feature does not need any documentation changes, make sure the sig-release team knows this,
111
+ by mentioning it in the ` #sig-release ` Slack channel. If the feature does need
112
+ documentation but the PR is not created, the feature may be removed from the milestone.
114
113
115
114
### PR ready for review
116
115
@@ -133,8 +132,7 @@ content is not received, the feature may be removed from the milestone.
133
132
If your feature is an Alpha or Beta feature and is behind a feature gate,
134
133
you need a feature gate file for it inside
135
134
` content/en/docs/reference/command-line-tools-reference/feature-gates/ ` .
136
- The name of the file should be the feature gate, converted from ` UpperCamelCase `
137
- to ` kebab-case ` , with ` .md ` as the suffix.
135
+ The name of the file should be the name of the feature gate with ` .md ` as the suffix.
138
136
You can look at other files already in the same directory for a hint about what yours
139
137
should look like. Usually a single paragraph is enough; for longer explanations,
140
138
add documentation elsewhere and link to that.
@@ -153,9 +151,8 @@ stages:
153
151
toVersion : <Version> # (Optional) The version until which the feature gate is available
154
152
` ` `
155
153
156
- With net new feature gates, a separate
157
- description of the feature gate is also required; create a new Markdown file
158
- inside ` content/en/docs/reference/command-line-tools-reference/feature-gates/`
154
+ With net new feature gates, a separate description of the feature gate is also required;
155
+ create a new Markdown file inside ` content/en/docs/reference/command-line-tools-reference/feature-gates/`
159
156
(use other files as a template).
160
157
161
158
When you change a feature gate from disabled-by-default to enabled-by-default,
0 commit comments