|
1 | | -# Documentation Guidelines |
| 1 | +# Documentation guidelines |
2 | 2 |
|
3 | 3 | ## What |
4 | 4 |
|
5 | | -As a developer you are responsible for providing four kinds of documentation: **tutorials** for beginners learning how to use a tool, **how-to guides** for achieving specific goals, technical **reference** for understanding software, and **explanation** for understanding why tools were built the way they are. |
| 5 | +As a developer you are responsible for providing four kinds of documentation: **tutorials** for beginners learning how to use a tool, **how-to guides** for achieving specific goals, technical **reference** for understanding software, and **explanation** for understanding why tools were built the way they are. Our documentation is organized according to the [diataxis](https://diataxis.fr/) framework. |
6 | 6 |
|
| 7 | +At a minimum, you must provide a technical **reference** in the `README.md` file in every GitHub repository that you maintain and update the standard headers in the [aind-library-template](https://github.com/AllenNeuralDynamics/aind-library-template): Usage, Level of Support, Installation. |
7 | 8 |
|
| 9 | +All packages should include: |
8 | 10 |
|
9 | | -## Where |
| 11 | +1. A **tutorial** aimed at total beginners using your package that walks them through a basic example. |
| 12 | +2. **How-to guides** for specific use-cases of your package. Note that AIND-specific use cases should be documented in [aind-software-docs](https://github.com/AllenNeuralDynamics/aind-software-docs). |
10 | 13 |
|
11 | | -| Location | Type | User | Details | |
12 | | -|----------|------|------|---------| |
13 | | -| [aind-software-docs](https://github.com/AllenNeuralDynamics/aind-software-docs) | Tutorials | New users | User stories, tutorials, and links to technical documentation | |
14 | | -| Documentation pages for your repository | How-to Guides | Technical users | Technical details about a library | |
15 | | -| Documentation pages for your repository | Reference | Developers | Developer documentation, contributing guidelines, and deployment details | |
16 | | -| Talks, project proposals, white papers, documentation pages for your repository | Explanation | Developers | Why we did things the way we did | |
| 14 | +For packages that are fully released you should also add: |
17 | 15 |
|
18 | | -## How |
| 16 | +3. **Technical reference**, generally auto-generated library or API docs. |
| 17 | +4. **Explanation** of technical or philosophical decisions made during development. Links to a preprint or paper can often take the place of an explanation section. |
| 18 | + |
| 19 | +As an example, on the [aind-data-schema documentation](https://aind-data-schema.readthedocs.io/en/latest/example_workflow/example_workflow.html) the [Generating metadata](https://aind-data-schema.readthedocs.io/en/latest/example_workflow/example_workflow.html) section is a tutorial, the [Core and Component Schemas](https://aind-data-schema.readthedocs.io/en/latest/data_description.html) pages are reference, and the [Philosophy](https://aind-data-schema.readthedocs.io/en/latest/general.html) sections provide some explanation of *why* certain decisions were made. |
19 | 20 |
|
20 | | -You can contribute directly to this repository with a pull request and review. |
| 21 | +## How |
21 | 22 |
|
22 | 23 | Libraries built using the `aind-library-template` automatically have a read-the-docs documentation built-in. You can write `.rst` files or add the `myst-parser` package and write `.md` files. You can deploy your documentation directly on the [read-the-docs](https://readthedocs.org). |
23 | 24 |
|
| 25 | +You can contribute updates and how-to guides for your tools directly to this repository with a pull request and review. |
| 26 | + |
24 | 27 | ## Why |
25 | 28 |
|
26 | | -[Diataxis](https://diataxis.fr/) |
| 29 | +Software engineer at AIND has grown to a scale where a central entry-point for users should make it far easier to find and learn about our tools. Across packages we are also taking a variety of approaches to documentation, iteratively moving toward a more standardized "feel" in our documentation will reduce the overhead for users who are only rarely interacting with documentation during their scientific work. |
0 commit comments