Skip to content

Commit

Permalink
feat(docs): Docs meta doc (#4767)
Browse files Browse the repository at this point in the history
  • Loading branch information
catmcgee committed Feb 26, 2024
1 parent df40b15 commit 0a645d3
Show file tree
Hide file tree
Showing 2 changed files with 64 additions and 0 deletions.
4 changes: 4 additions & 0 deletions docs/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,10 @@ Things to note:

When in doubt, check existing sections of the code to see if there are relevant references.

## Structuring the docs

Aztec's docs are structured in accordance to a few smart people's philosophies about documentation. You can read the guidelines into how we write docs [here](./HOW_WE_WRITE_DOCS.md).

### Citations

The following documents were referenced in the creation of this doc.
Expand Down
60 changes: 60 additions & 0 deletions docs/HOW_WE_WRITE_DOCS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# How we write docs

This doc covers the structure and tone of Aztec developer documentation. For the contribution guidelines, go [here](./CONTRIBUTING.md). Please keep in mind that this is constantly changing.

## Structure

### High level

Aztec docs are divided into two main sections - `Learn` and `Build`.

Anyone technical can read the `Learn` section, whereas only developers who are actively building or starting to build on Aztec will read the `Build` section.

The `Learn` section contains [explanations](#explainations) of each of the concepts that make up Aztec, going into much more detail than is required by developers who just want to build something.

The `Build` section contains information that only developers need to know - this can be related to setting up or interacting with a local environment, writing smart contracts, or using Aztec.js.

### Types of pages

The Aztec docs roughly follow the [Diataxis](https://diataxis.fr/) framework. It is recommended to read this website before contributing to the docs.

Every page will fall into **one type of doc**. If your contribution covers multiple types, you will need to split it into multiple pages.

#### Explainations

These answer the questions "What is...?" and don't have any direct implications for what the reader does. It helps readers understand a concept. These can exist in both `Learn` and `Build` sections of the docs, depending on the context of the explanations. For example, a doc explaining UTXOs would sit in `Learn`, but explaining how Aztec.nr abstracts UTXOs would sit in `Build`.

#### Tutorials

These are follow-along experiences that guide the reader into building something. In the context of Aztec docs, these are generally project-oriented rather than feature-oriented. For example, a developer might learn how to build a private token rather than focusing on how to use a specific Aztec privacy feature. It does not expect too much prior knowledge from the developer, and does not expect that they have a goal in mind aside from learning. They currently only exist in `Build`.

#### How-tos

These are guides for the reader to accomplish a specific goal. In the context of Aztec docs, how-to guides usually cover a specific feature, library, or setup. It expects the reader to know why they are there and does not provide any additional context than needed. They currently only exist in `Build`.

#### References

These are docs that developers can consult to know exact and succint information about a specific library or feature. In the case of Aztec, it usually consists of lists of callable functions, their parameters, and return types. Most Aztec references are autogenerated. They currently only exist in `Build`.

## Tone

* Concise and informative - for example, rather than repeating information, write "to learn more, read ..."
* Friendly and empathetic - for example, "you do not have to worry about this yet"
* Simple and jardon-avoidant when possible
* Short sentences
* Unopinionated language - we know things are exciting sometimes, but try not to tell the developer what they should be excited about

## Grammar

To keep docs consistent and easily-searchable, follow these grammar guidelines:

* Write with American English
* When talking about ZK, use:
** `zero knowledge` as the noun
** `zero-knowledge` as the adjective
** `ZK` for subsequent mentions of zero knowledge and zero-knowledge on the same page
* Do not end bullet points with any punctuation, such as bullet points or semi-colons (most of the time)
* Use numbered bullets when the order is important, such as steps in a guide or hierarchies of dependencies
* Write with [active voice](https://www.grammarly.com/blog/active-vs-passive-voice/) in tutorials and how-tos, and passive voice in explanations
* Use the [Oxford comma](https://www.grammarly.com/blog/what-is-the-oxford-comma-and-why-do-people-care-so-much-about-it/)
* Avoid exclamation points

0 comments on commit 0a645d3

Please sign in to comment.