Skip to content

Commit

Permalink
move more writing style recommendations into the public guide
Browse files Browse the repository at this point in the history
  • Loading branch information
fricklerhandwerk committed Jun 21, 2023
1 parent 9c3e6c5 commit 6faffbd
Show file tree
Hide file tree
Showing 3 changed files with 136 additions and 145 deletions.
45 changes: 24 additions & 21 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,19 @@ Open an [issue] if you want to clarify something not evident from what is provid
[issue]: https://github.com/NixOS/nix.dev/issues
[pull request]: https://github.com/NixOS/nix.dev/pulls

## Code of conduct

Adapted from the [Contributor Covenant] and [The Carpentries Code of Conduct]:

- Use welcoming and inclusive language
- Show empathy and respect towards other people
- Be respectful of different viewpoints and experiences
- Give and gracefully accept constructive criticism
- Focus on what is best for the community

[Contributor Covenant]: https://github.com/EthicalSource/contributor_covenant/blob/cd7fcf684249786b7f7d47ba49c23a6bcb3233eb/content/version/2/1/code_of_conduct.md
[The Carpentries Code of Conduct]: https://github.com/carpentries/docs.carpentries.org/blob/4691971d9f49544054410334140a4fd391a738da/topic_folders/policies/code-of-conduct.md

## What you can do

### You want to learn and use Nix?
Expand Down Expand Up @@ -52,7 +65,7 @@ We would be glad to incorporate your insights.

## Contributor guides

Please read ["Contributing Documentation"](./source/contributing/documentation.md).
Please read [Contributing Documentation](https://nix.dev/contributing/documentation).

# Vision

Expand Down Expand Up @@ -210,24 +223,7 @@ This section shows how the disconnected packages from previous examples can be w
- Docker containers
- Contributing to Nix

# Licensing and attribution

When opening pull requests with your own contributions, you agree to licensing your work under [CC-BY-SA 4.0].
Before merging your work, you have to sign the [contributor agreement](cla/README.md).

Having a single legal entity hold non-exclusive copyright avoids disputes and ensures the material can be put to use more effectively, e.g. by eventually publishing it as a book.
You will still be considered co-author, as recorded by version history.

When adding material by third parties, make sure it has a matching license that permits this.
In that case, unambiguously state source, authors, and license.
Also [add the original author as co-author] to the respective change, so we can track authorship through version history.

Notify the authors *before* using their work.

[CC-BY-SA 4.0]: https://creativecommons.org/licenses/by-sa/4.0/
[add the original author as co-author]: https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors

# Notes
# Contributor notes

## GitHub heading anchors fails linkcheck

Expand All @@ -238,6 +234,13 @@ Until the bug is resolved, add the `user-content-` prefix to GitHub links
containing heading anchors.

For example, instead of
`https://github.com/cachix/install-nix-action#user-content-how-can-i-run-nixos-tests`,

```
https://github.com/nix-community/nixos-generators#cross-compiling
```

use
`https://github.com/cachix/install-nix-action#user-content-how-can-i-run-nixos-tests`.

```
https://github.com/nix-community/nixos-generators#user-content-cross-compiling
```
118 changes: 12 additions & 106 deletions source/contributing/documentation.md
Original file line number Diff line number Diff line change
@@ -1,19 +1,19 @@
# Contributing Documentation

This guide shows how you can contribute documentation to Nix, Nixpkgs, or NixOS.
It is maintained by the [Nix documentation team](https://nixos.org/community/teams/documentation), your first point of contact if you want to help out.
This is an overview documentation resources for Nix, Nixpkgs, and NixOS, with suggestions how you can help to improve them.
Documentation contributions should follow to the [writing style recommendations](./writing-style.md).

## List of available documentation
Feel free to in touch with the [Nix documentation team](https://nixos.org/community/teams/documentation) if you want to help out.

### Manuals
## Reference manuals

The manuals for [Nix][nix manual] ([source][nix manual src]), [Nixpkgs][Nixpkgs manual] ([source][nixpkgs manual src]), and [NixOS][NixOS manual] ([source][nixos manual src]) are purely reference documentation, specifying interfaces and behavior.

They also show example interactions which demonstrate how to use its components, and explain mechanisms where necessary.

The documentation team watches all pull requests to the manuals and assists contributors to get their changes merged.

You can help by doing the following:
You can help by

- picking up documentation-related issues on [Nix][nix docs issues], [Nixpkgs][nixpkgs docs issues], and [NixOS][nixos docs issues].

Expand Down Expand Up @@ -42,19 +42,19 @@ You can help by doing the following:
[nixpkgs docs prs]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%226.topic%3A+documentation%22+-label%3A%226.topic%3A+nixos%22
[nixos docs prs]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%226.topic%3A+documentation%22+label%3A%226.topic%3A+nixos%22+

### nix.dev
## nix.dev

The purpose of [nix.dev] ([source][nix.dev src]) is to guide newcomers by teaching essential Nix knowledge, show best practices, and help orient users in the Nix ecosystem.

It goes into breadth, not depth.

The documentation team maintains nix.dev as editors.

You can help by doing the following:
You can help by

- working on [open issues][nix.dev issues]
- reviewing [pull requests][nix.dev prs] by testing new material or features
- adding guides or tutorials following the [proposed outline](https://github.com/NixOS/nix.dev/pull/265/files)
- adding guides or tutorials following the [proposed outline](https://github.com/NixOS/nix.dev/blob/master/CONTRIBTUING#user-content-vision)

New articles can be based on videos such as:

Expand All @@ -75,7 +75,7 @@ Since writing a guide or tutorial is a lot of work, please make sure to coordina
[Nix video guides]: https://www.youtube.com/user/elitespartan117j27
[Summer of Nix 2022 talks]: https://www.youtube.com/playlist?list=PLt4-_lkyRrOMWyp5G-m_d1wtTcbBaOxZk

### nixos.org
## nixos.org

The Nix project web site is [nixos.org] ([source][nixos website src]).

Expand All @@ -87,13 +87,13 @@ The [Nix marketing team] is responsible for the web site, and the documentation
[nixos website src]: https://github.com/nixos/nixos-homepage
[Nix marketing team]: https://nixos.org/community/teams/marketing.html

## List of communication channels
## Communication channels

### Matrix

Use Matrix for casual communication.

The documentation team frequents the [Nix* Documentation] room.
The documentation team frequents the [Nix\* Documentation] room.

Old messages are extremely improbable to be read by anyone.

Expand Down Expand Up @@ -131,7 +131,7 @@ You can help by joining meetings to take notes or clean them up before publishin

[Discourse community calendar]: https://discourse.nixos.org/t/community-calendar/18589

### External sources
## External sources

The Internet is full of helpful resources concerning Nix.

Expand Down Expand Up @@ -167,97 +167,3 @@ Where to migrate what:

[NixOS Wiki]: https://nixos.wiki/
[NixCon 2015: Make Nix friendlier for Beginners]: https://media.ccc.de/v/nixcon2015-3-MakeNixfriendlierforBeginners#video

## Values

### Be kind

Adapted from [Contributor Covenant] and [The Carpentries Code of Conduct]:

- Use welcoming and inclusive language
- Show empathy and respect towards other people
- Be respectful of different viewpoints and experiences
- Give and gracefully accept constructive criticism
- Focus on what is best for the community

[Contributor Covenant]: https://github.com/EthicalSource/contributor_covenant/blob/cd7fcf684249786b7f7d47ba49c23a6bcb3233eb/content/version/2/1/code_of_conduct.md
[The Carpentries Code of Conduct]: https://github.com/carpentries/docs.carpentries.org/blob/4691971d9f49544054410334140a4fd391a738da/topic_folders/policies/code-of-conduct.md

### Be truthful

The only thing more confusing than no documentation is misleading documentation.

#### Use and provide evidence

Documentation should enable readers to answer all their questions on their own.

Provide links to other resources, such as the manuals, if it would help guide readers on their learning journey.

It is explicitly encouraged to update or restructure the manuals where appropriate, to improve the overall experience.

Similarly, the other information surrounding documentation should enable contributors to answer most of their questions and correct obvious errors on their own, and only then resort to opening issues.

Errors get more obvious if we can measure execution against intent.

Therefore we ask you to always make explicit the motivation behind your proposed changes.

Add references to any relevant resources in commit messages, if it helps understand the reasoning behind a significant change.

#### Ensure working code samples

Code samples must always be working correctly when run as instructed.

Nix provides us with everything needed to make this happen.

### Be concise

> I would have written a shorter letter, but I did not have the time.
>
> [Blaise Pascal][Blaise Pascal]
Readers' time and attention is limited.

Take the time to be extraordinarily respectful with their cognitive resources.

The same holds for communication directed to contributors and maintainers: This is a public project, and many people will read what you write. Use this leverage with care.

[Blaise Pascal]: https://en.m.wikiquote.org/w/index.php?title=Blaise_Pascal&oldid=2978584#Quotes

## Guidelines

:::{note}
Contributed documentation should adhere to the [writing style](./writing-style.md) recommendations.
:::

### Links

Unless explicitly required to point to the latest version of an external resource, all references should be [permanent links].

Many web services offer permalinks, such as:

- [GitHub URLs to specific commits]
- [Wikipedia URLs to specific page versions]
- [Internet Archive "Save Page Now" for persisting web pages]

[permanent links]: https://en.m.wikipedia.org/wiki/Permalink
[GitHub URLs to specific commits]: https://docs.github.com/en/repositories/working-with-files/using-files/getting-permanent-links-to-files
[Wikipedia URLs to specific page versions]: https://en.m.wikipedia.org/wiki/Wikipedia:Linking_to_Wikipedia#Permanent_links_to_old_versions_of_pages
[Internet Archive "Save Page Now" for persisting web pages]: https://web.archive.org/save

### Markdown

- Write one sentence per line.

This makes long sentences immediately visible, and makes it easier to manage changes.

The rule is unambiguous and does not require tooling support to be applied easily.

[Here is a discussion of different line wrapping styles.]

- Use [reference links] to keep the plain text readable.

Collect links at the end of each section, which are delimited by headings.

[Here is a discussion of different line wrapping styles.]: https://web.archive.org/web/20220519121408/https://mtsknn.fi/blog/4-1-wrapping-styles-for-markdown-prose-and-code-comments/
[reference links]: https://github.github.com/gfm/#reference-link

118 changes: 100 additions & 18 deletions source/contributing/writing-style.md
Original file line number Diff line number Diff line change
@@ -1,38 +1,120 @@
# Writing style

This guide gives some recommendations about how to write tutorials, guides, and other documentation.

## Recommendations
- Follow the evidence-based [plain language guidelines].
## Language

## Aim for clarity and brevity

> I would have written a shorter letter, but I did not have the time.
>
> [Blaise Pascal](https://en.m.wikiquote.org/w/index.php?title=Blaise_Pascal&oldid=2978584#Quotes)
Readers' time and attention is limited.
Take the time to be extraordinarily respectful with their cognitive resources.

The same holds for communication directed to contributors and maintainers:
This is a public project, and many people will read what you write.
Use this leverage with care.

- Follow the evidence-based [plain language guidelines](https://www.plainlanguage.gov/guidelines/)

- Use imperative in direct instructions

- Avoid narrative or discursive style

## Be truthful

> Incorrect documentation is often worse than no documentation.
>
> — attributed to [Bertrand Meyer](https://web.archive.org/web/20080706015334/https://www.eskimo.com/~hottub/software/programming_quotes.html)
- Describe the subject factually

Avoid value judgement or emotional appeal.
We don't know how and for which purpose the tools we document are going to be used, and our goal is not to advertise but to teach and inform.

- Use and provide evidence

Provide links to other resources, such as the reference manuals or source code.
This helps guide readers on their learning journey, and discover related relevant information.
The Nix documentation team explicitly encourages you to update or restructure the manuals where appropriate, to improve the overall experience.

Relying on reference documentation as much as possible also reduces the maintenance burden, as many key facts can be documented in a single place.

- Show fully working examples

- Describe the subject factually.
Code samples must always be working correctly when run as given.
Nix provides us with everything needed to make this happen.

- Use imperative in direct instructions.
- State your intent

- Clarity and brevity outweighs emotional appeal.
Errors become more obvious and easier to fix if execution can be measured against intent.
Therefore, always make explicit the motivation behind your proposed changes.

Do not presuppose a personal relationship with readers.
Add references to any relevant resources in commit messages, if it helps understand the reasoning behind a significant change.

- Address the reader with "you" when necessary.
## Use inclusive language

- Avoid idioms

Idioms can be hard to understand for non-native English speakers.

- Don't try to be funny

Humor is highly culturally sensitive.
At best, jokes may obfuscate the relevant information.
At worst, jokes may offend readers and invalidate our effort to help them learn.

- Don't use references to popular culture

What you may consider well-known may be entirely obscure and distracting to people from different backgrounds.

- Do not presuppose a personal relationship with readers

Address the reader with "you" only when necessary.
Clarify identity if you use "we".
Generally, "we" are the Nix community.
Generally, "we" are users and contributors in the Nix ecosystem.

# Licensing and attribution

When opening pull requests with your own contributions, you agree to licensing your work under [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/).

When adding material by third parties, make sure it has a license that permits this.
In that case, unambiguously state source, authors, and license in the newly added material.
Notify the authors *before* using their work.

[Add the original author as co-author](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors) to the first commit of your pull request, which should contain the original document verbatim, so we can track authorship and changes through version history.

Using free licenses other than CC-BY-SA 4.0 is possible for individual documents, and by contributing changes to those documents you agree to license your work accordingly.

## Links

Unless explicitly required to point to the latest version of an external resource, all references should be [permanent links] to ensure that the referenced content is what is intended.

Many web services offer permalinks, such as:

- Use culturally neutral language:
- [GitHub URLs to specific commits]
- [Wikipedia URLs to specific page versions]
- [Internet Archive "Save Page Now" for persisting web pages]

- Avoid idioms.
[permanent links]: https://en.wikipedia.org/wiki/Permalink
[GitHub URLs to specific commits]: https://docs.github.com/en/repositories/working-with-files/using-files/getting-permanent-links-to-files
[Wikipedia URLs to specific page versions]: https://en.wikipedia.org/wiki/Wikipedia:Linking_to_Wikipedia#Permanent_links_to_old_versions_of_pages
[Internet Archive "Save Page Now" for persisting web pages]: https://web.archive.org/save

Idioms can be hard to understand for non-native English speakers.
## Markdown

- Don't try to be funny.
- Write one sentence per line.

Humor is highly culturally sensitive.
This makes long sentences immediately visible, and makes it easier to review changes and make suggestions.

At best, jokes may obfuscate the relevant instructions.
The rule is unambiguous and does not require tooling support to be applied easily.
[Here is a discussion of different line wrapping styles.]

At worst, jokes may offend readers and invalidate our effort to help them learn.
[Here is a discussion of different line wrapping styles.]: https://web.archive.org/web/20220519121408/https://mtsknn.fi/blog/4-1-wrapping-styles-for-markdown-prose-and-code-comments/

- Don't use references to popular culture.
- Use [reference links](https://github.github.com/gfm/#reference-link) where needed, either to keep the plain text containing many references readable or to reuse the same link multiple times.

What you may consider well-known may be entirely obscure and distracting to people from different backgrounds.
Keep reference link definitions close to their use site so they are easy to find without additional tooling.

[plain language guidelines]: https://www.plainlanguage.gov/guidelines/

0 comments on commit 6faffbd

Please sign in to comment.