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
Copy file name to clipboardExpand all lines: committee-code-of-conduct/governance/onboarding-offboarding.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,7 @@ Different actions on this list must be carried out by different members:
13
13
**Who executes:** When offboarding, outgoing members must remove themselves from Slack channels. When onboarding, carryover members must add incoming members.
14
14
15
15
-[ ] Code of conduct committee Slack channel(s) (public and private) on `kubernetes.slack.com`
16
+
-[ ]`#kubernetes-moderators` and `#slack-reports` private channels on `kubernetes.slack.com`
16
17
-[ ] Code of conduct sync Slack channel on `cloud-native.slack.com`
Copy file name to clipboardExpand all lines: communication/marketing-team/storytelling-resources/blog-guidelines.md
+37-10Lines changed: 37 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,17 +6,47 @@ We are looking for Kubernetes-curious community members who are **interested in
6
6
7
7
## Requested Content
8
8
9
-
We are looking for:
9
+
We are looking for content related to the contributor experience and with increasing the visibility of Kubernetes and how it is developed: this includes interviews with SIGs, articles on how to better use existing tools and processes, and in general tips and suggestions on how to collaborate.
10
10
11
-
* TODO << Request specific types of content
11
+
Other types of content, like Kubernetes capabilities, tutorials, and technical articles, are better suited for the [SIG-Docs blogging initiative](/sig-docs/blog-subproject/README.md).
12
12
13
-
Other types of content, like Kubernetes capabilities and tutorials, are better suited for the [SIG-Docs blogging initiative](/sig-docs/blog-subproject/README.md).
13
+
## Where to publish
14
14
15
-
## Submit a Post
15
+
As mentioned, the focus of the Contributor Experience articles is targeted at those that contribute to Kubernetes, but sometimes it's not obvious were a specific theme will fit. The following are the most common situations:
16
16
17
-
The quickest way to get involved is to let the team in [#sig-contribex](https://kubernetes.slack.com/archives/C1TU9EB9S) know that you have an idea for an article.
17
+
1. Article is just for [k8s.dev](http://k8s.dev/blog): 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.
18
+
2. Article is just for [kubernetes.io](https://kubernetes.io/blog/): 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.
19
+
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.
20
+
21
+
The decision on what is the right option will be made jointly by the SIG Contribex Comms and the SIG Docs Blogging editorial team: as a content writer you shouldn't be overly concerned about it, expect in how it can change the approval process, as described below.
22
+
23
+
## Submission and review process
24
+
25
+
The quickest way to get involved is to let the team in [#sig-contribex-comms](https://kubernetes.slack.com/archives/C03KT3SUJ20) know that you have an idea for an article; the team will identify the best target for your submission and liaison with the necessary teams, if needed. To reduce the amount of editing done directly in GitHub, a two-stage approach is highly recommended.
26
+
27
+
This process is initiated in [#sig-contribex-comms](https://kubernetes.slack.com/archives/C03KT3SUJ20) and uses the processes from the SIG Docs blog [subproject](/sig-docs/blog-subproject/README.md), and is broadly as follows:
28
+
29
+
1. Present your idea to the community, by going to the [#sig-contribex-comms](https://kubernetes.slack.com/archives/C03KT3SUJ20) Slack channel, or by joining the [weekly meeting](https://docs.google.com/document/d/1KDoqbw2A6W7rLSbIRuOlqH8gkoOnp2IHHuV9KyJDD2c). This will make it easier to coordinate effort and avoid duplicate effort, as well as to gather initial suggestions around the article scope.
30
+
2. The submission idea will be reviewed by the team, including the decision on where to publish it; someone from the SIG Contribex Comms team will reach out to the [#sig-docs-blog](https://kubernetes.slack.com/archives/CJDHVD54J) editorial team to clarify if the content is adequate for republishing in the main Kubernentes blog. At this stage an editor should be assigned to follow-up the process with you.
31
+
3. Create your proposal draft in [Google Docs](https://docs.google.com/) or HackMD (https://hackmd.io), and ask for a review in [the channel](https://kubernetes.slack.com/archives/C03KT3SUJ20). This will facilitate easier editing, especially if major changes or restructuring is needed. Take into account the [documentation style guide](https://kubernetes.io/docs/contribute/style/style-guide/): these guidelines can help in improving the readability of your article, especially in terms of the use of Kubernetes terminology.
32
+
4. Once you have reflected any feedback in the proposal draft, announce that the article is ready for submission (again, in the channel or in one of the weekly meetings): the assigned editor will use the final text to open the PR, adding you as a Co-author
33
+
5. (Optional) If the submission will be mirrored in the main Kubernetes site, a second PR will be oped by the editor, but on the main repository, and after being approved in the `contributor-site` one.
34
+
35
+
For now, our official process is to use [SIG Docs' system](/sig-docs/blog-subproject/README.md), with one change: instead of directly creating the file in the Kubernetes site repository, as instructed abovem it's initially created in the [contributor-site](https://github.com/kubernetes/contributor-site), in the appropriate folder (i.e. the right year in `contributor-site/content/en/blog/`).
36
+
37
+
This will lead to an initial review process before it gets mirrored to the main Kubernetes site.
38
+
39
+
### Editor instructions
40
+
41
+
Once the text is final, an editor will open the PR. This facilitates the approval process and prevents articles with massive restructuring or changes needed to be submitted to GitHub, something that makes the review process substantially more difficult.
42
+
43
+
In order to keep the authorship information (which will make the submission count towards the contribution of the article author), editors must [add the original author as a co-author](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors). This is done by adding `Co-authored-by: original-author-name <[email protected]>` to the commit message.
44
+
45
+
The number of PRs depends on where the article will be published:
46
+
47
+
1. If it's solely for the Contributor site: the PR should be opened in the [contributor-site](https://github.com/kubernetes/contributor-site), after which the process ends.
48
+
2. If it's to be mirrored in the main Kubernetes blog: after the previous step, a new PR is opened on [kubernetes/website](https://github.com/kubernetes/website), mentioning the original PR. The SIG-Docs Blog editorial team will, in this case, already been notified and involved in the initial PR.
18
49
19
-
For now, our official process is to use [SIG-Doc's system](/sig-docs/blog-subproject/README.md).
20
50
21
51
## Blogger Expectations, Responsibilities, and Info
22
52
@@ -52,14 +82,11 @@ Keep the following points in mind as you write in order to speed up the review p
52
82
* Avoid interjecting personal reactions
53
83
* Ensure that the blog post is reviewed by the anyone being mentioned in the piece
54
84
* As the author, never talk about your employer, sell, promote, or pitch; this is about upstream community endeavours and the individuals and groups that create it
85
+
* Follow the [documentation style guide](https://kubernetes.io/docs/contribute/style/style-guide/).
55
86
56
87
## Further Recommendations
57
88
58
89
The following are helpful resources for authoring articles:
59
90
60
91
*[Creating Quality Content (For Search Engines and People)](https://moz.com/blog/quality-blog-content)
61
92
*[How to write effective documentation for your open source project](https://opensource.com/article/20/3/documentation)
62
-
63
-
## Review Process
64
-
65
-
This process is bootstrapped from the sig-docs blog [subproject](/sig-docs/blog-subproject/README.md). Please ask for review from community liaisons on the sig-docs-blog team or let the team in [#sig-contribex](https://kubernetes.slack.com/archives/C1TU9EB9S) know you need help.
Copy file name to clipboardExpand all lines: communication/marketing-team/storytelling-resources/social-guidelines.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
5
5
## General guidelines
6
6
7
-
All messaging must be consistent with the values and principles of the project and the [ethos/vision of the team](./CHARTER.md#ethosvision). Messaging should be positive and uplifting. Be aware that sarcasm and/or jokes are generally hard to read over a medium such as social media.
7
+
All messaging must be consistent with the values and principles of the project and the [ethos/vision of the team](/communication/marketing-team/CHARTER.md#ethosvision). Messaging should be positive and uplifting. Be aware that sarcasm and/or jokes are generally hard to read over a medium such as social media.
8
8
9
9
Original messages should come out of this teams' accounts at least twice a week (if not more). However, there should be no more than three tweets per hour (including retweets). Retweets, likes, and responses are unlimited, but they should be used thoughtfully to encourage inclusive and kind participation. Use scheduling software as needed to space out messages. All messages should serve a purpose: have an action and/or thumbnail image ("click link for details," "register today," etc. are example actions). Never include photos, user handles, or other personally identifiable information without explicit permission.
0 commit comments