becarpenter-book6/CONTRIBUTING.md

# book6
A collaborative IPv6 book.

This is a first draft of how to contribute.

Contributors will be self-declared practitioners of IPv6. There is no other entry ticket except a valid GitHub account.

Contributions (in markdown format) will fit into an agreed table of contents. They will be factual and will teach technical readers about a particular aspect of IPv6. As far as possible, references will be to RFCs and other freely available documents.

Where there are alternatives and choices for people deploying or using IPv6, the choices will be presented objectively, if possible with factual pros and cons. Justified recommendations may be made (e.g., "X is generally more secure than Y") but strong personal opinions (e.g., "NAT66 is never the right answer") should be avoided.

Contributors may edit their own and other contributions. However, significant changes should first be discussed using the issue tracker. That isn't necessary for spelling mistakes, grammar problems, or small nits. GitHub PRs will be used when necessary (i.e., where the changes need review). The goal is to achieve IETF-style rough consensus on the content. A typical tie-breaker argument is "I have deployed this and it works well."

Preferably, a contribution will be a complete section. There is a naming convention for files, based on the table of contents, so that some clever person can write a script to generate the whole book from the repo. See the [basic chapter template](99.%20Chapter%20Template) and follow it carefully. Please create a separate file for each section within the folder for its chapter. Also add previous/next/contents links as shown in the template. (If anyone knows how to automate those links, please tell us!)

Note that contributions MUST be original writing unless the contributor has the legal right to submit the material under the agreed license (see [LICENSE.md](LICENSE.md)).

We should probably appoint two or three people as top-level editors who can declare consensus and approve PRs.

Diagrams can be ASCII art when applicable, e.g.:
~~~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              etc.                             |
~~~

The [*mermaid* tool](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams) can be used for flow charts and state diagrams, e.g.:

~~~
```mermaid
flowchart LR
    S[Start here] --> E[End here]
```
~~~

```mermaid
flowchart LR
    S[Start here] --> E[End here]
```

Other types of diagrams could be included using SVG generated by a separate drawing tool such as *dia*, with the SVG file also stored here on GitHub, e.g.:

~~~
<img src="./diag.svg">
~~~
<img src="./diag.svg">

The language is English, preferably US spelling. Please keep sentences reasonably short and simple. Avoid language that might be unclear for someone whose first language is not English.

Any translation into other languages must be under the same open source license as the original version and must be available free of charge.