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
Create a separate `COMMUNICATION.md` document. Link this document to your `README.md` so comprehensive contact information can be provided and not take up the extra space in your README. This document should answer frequently
87
+
asked questions about communicating with your team that contributors need to know. The goal is to streamline communications so users and contributors reach out to the correct person through a single channel. This reduces unnecessary distractions for team members and organizes communications so they do not get lost.
88
+
89
+
Sections in the `COMMUNICATION.md` include points of contact for incoming communications and information about outgoing communications from the project's ownership team. See some examples below.
90
+
91
+
Points of contact for incoming communication and how to contact those users:
92
+
93
+
* Reporting a bug
94
+
* Following up on a PR
95
+
* Feature requests
96
+
* Questions about documentation
97
+
* Escalations
98
+
99
+
How and when the team communicates outbound with users and how to get added to those communications:
100
+
101
+
* Planned and unplanned outages
102
+
* Feature releases
103
+
* Code freezes
104
+
* Breaking changes
105
+
84
106
There are many of good examples for how to write a `README.md` and what kind
85
107
of information to include in a `CONTRIBUTING.md` file in various open source projects.
86
108
Pages like [how to write a readme that rocks](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a),
87
109
[Open Source Guide from GitHub](https://opensource.guide/) as well as
88
110
the book [Producing Open Source](https://producingoss.com/en/producingoss.html)
89
111
all have valuable information on what kind of information to provide. While
90
112
Producing Open Source does not have a chapter on writing a good README per se,
In addition to that, this pattern comes with three very basic templates to get you
120
+
started right away: [README-template.md](templates/README-template.md),
121
+
[CONTRIBUTING-template.md](templates/CONTRIBUTING-template.md), and [COMMUNICATION-template.md](templates/COMMUNICATION-template.md).
101
122
102
123
## Resulting Context
103
124
@@ -110,11 +131,16 @@ started right away: [README-template.md](templates/README-template.md) and
110
131
* Europace AG - See blog post [InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
111
132
* Paypal Inc.
112
133
* Mercado Libre - create a documentation site that contains how to get started with InnerSource and also define the basic artifacts that a repository must have to be InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc).
134
+
* Analog Devices Inc.
113
135
114
136
## Authors
115
137
116
138
* Isabel Drost-Fromm
117
139
140
+
## Acknowledgments
141
+
142
+
* Katie Schueths - for adding the `COMMUNICATION.md` concept
143
+
118
144
## Alias
119
145
120
146
Provide standard base documentation through a README
0 commit comments