Sig Instrumentation Spotlight

[imnmo]

HackMd: https://hackmd.io/@TyxQSpShS_mQBOxa_4vq5A/BJWfsol_o/edit

[imnmo]

@kaslin @fsmunoz PTAL

[jberkus]

Important question: is this going only on the Contributor blog, or should it go on the main Kubernetes blog? It's looking like something for the main blog.

[sftim]

We usually mirror SIG spotlight articles onto the main blog (which means: once this is edited enough to be reviewable, /hold this PR and open a similar PR against k/website, so we can get them in sync to publish on the same day).

[imnmo]

Thanks for the PR.

I can offer some feedback.

Overall:

• sentence case headings please
• kube-state-metrics not Kube State Metrics.
• SIG Instrumentation not SIG-Instrumentation

Thanks a lot, @sftim I am done with fixing it. Will upload a new patch.

[imnmo]

Important question: is this going only on the Contributor blog, or should it go on the main Kubernetes blog? It's looking like something for the main blog.

Quoting @sftim once this is ready to merge stage I will open a new PR within K8s.io to make sync and review easier

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: imnmo / name: Imran Noor Mohamed (b425ad890fcbfb3428a383bf5294c720c4ee4b2f, 62012c2d0d4d1998604b1859ffd5fcec55abab31)

[fsmunoz]

Hi @imnmo , great stuff, thank you for your work on this. I made some suggestions (which are on top on what was already reviewed before), minor stuff (except the Author field).

@jberkus: as @sftim mentioned, SIG Spotlights are considered adequate for both, and I've tried to reflect that (in a generalised way) in the last update to the blogging guidelines

1. Article is just for k8s.dev: this is when it is relevant for the contributor community, and not necessarily for Kubernetes end-users. An example is an article explaining how to use some specific tool or automation that helps with the Kubernetes development process.
2. Article is just for kubernetes.io: when the article targets Kubernetes end-users, and not specifically the contributor community. Examples include most technical articles on Kubernetes features, updates on new features and deprecations, etc.
3. Article is relevant for both: sometimes, an article will be relevant to both the Kubernetes end-users, and the contributor community. Examples include interviews with SIGs and WGs, articles on technical aspects that are important for the contributor community, etc.

It also describes that a second PR will be made against the main site. The process assumes that both PRs are opened by the editor (with the author also listed) though.

[imnmo]

@sftim PTAL

[sftim]

I recommend asking #sig-docs-blog (on Slack) for advice on getting the PR opened against k/website, and also for feedback on that PR once it's opened.

[fsmunoz]

@imnmo the Comms blogging guideline mentioned above has some guidance on the process, and I can also assist in our Slack channel should it be needed. In general though, for articles which are cross-posted, pretty much all of the review should be done in this PR.

[imnmo]

@sftim and @fsmunoz I asked in the slack channel for hints to post in k8s.io

[sftim]

I can fix up the punctuation in a follow up PR.

/lgtm /approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: imnmo, sftim

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/kubernetes/contributor-site/blob/master/OWNERS)~~ [sftim] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[sftim]

/hold cancel