Closed shannonxtreme closed 4 months ago
/assign /sig docs
/triage accepted /lifecycle frozen
/priority backlog /sig contributor-experience
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
This issue is currently awaiting triage.
SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted
label.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
@shannonxtreme I'd love to hear from you if you think this issue is worth reviving. At the moment, many of the relevant issues you've mentioned have been closed due to inactivity, and this umbrella issue would need an overhaul to have it linked to relevant work in flight (or not). While I do think this work is important, we can absolutely reflect as such in a new issue
Coming back to this issue, and in the interest of cleaning up some of our older work, I am in favour of closing this given the amount of inactivity in the linked relevant work, and the overhaul required to make this umbrella issue suitable for our current docs scope.
Happy to hear feedback from others!
Yeah I think we should close this. If I have more time down the line I'll bring it up at a sig meeting 😁 I think that we covered a lot of this in the linked issues so I see it as a win still!
Agreed, thanks @shannonxtreme! 🎉 /close
We should expand the Contributor Style Guide so that contributors have a reference for common terms and phrases.
Some examples of what we could add:
VerticalPodAutoscaler
vs Vertical Pod Autoscaler) and whether to use the word "object" or "resource" after a code-blocked mention (eg: Create aService
object vs Create aService
)A lot of the groundwork already exists in the current Style Guide, but it could use expansion and potential reorganization.
We could, for example, organize into sections based on type of style issue (grammar/accessibility & inclusion/formatting/API).
This may be a long term priority but I thought it might be a good discussion point for a future meeting as it has the potential to be a pain to maintain as it grows, but would be invaluable for new contributors (like me!).
Related issues
26190
18231
14101
7030
5234
20862
20925
Tasks
/cc @sftim