1
0
Fork 0
mirror of https://github.com/NixOS/nix.dev.git synced 2024-10-18 14:32:43 -04:00

update the tutorial guide, add issue template

This commit is contained in:
Valentin Gagarin 2024-09-02 11:17:30 +02:00
parent 9eeafb5ef0
commit 9c75769a3c
2 changed files with 48 additions and 29 deletions

View file

@ -1,5 +1,5 @@
---
name: Tracking Issue
name: Tracking issue
about: Create a tracking issue for a collection of issues and pull-requests
labels: tracking
---

View file

@ -5,8 +5,6 @@ This is a guide to writing tutorials about Nix.
By tutorials we mean *lessons* as described in the [Diátaxis framework for technical documentation](https://diataxis.fr/), and recommend becoming familiar with Diátaxis before proceeding.
Especially note [the difference between tutorials and guides](https://diataxis.fr/tutorials-how-to/).
We strongly recommend the book [How Learning Works (summary)](https://www.lesswrong.com/posts/mAdMkFqWzbJRB544m/book-review-how-learning-works) as a guide for designing learning materials.
## Target audience
The main target audience of Nix tutorials are software developers with at least basic experience on the Linux command line.
@ -18,9 +16,54 @@ This is achieved by following the structure outlined here, which is primarily ch
As a byproduct, a well-written tutorial will be useful as lecture notes for use in interactive training sessions.
Therefore, the secondary target audience are instructors teaching Nix.
## Process
Writing a high-quality tutorial takes some time for you and others.
Most of that time is typically spent collaboratively:
- Figuring out the right approach
- Ensuring that the instructions are neither too sparse nor too dense for learners
- Finding ever-more succinct and clear ways to convey ideas
Follow these steps to avoid re-doing work
### Pick a topic
There is a [tracking issue](https://github.com/NixOS/nix.dev/issues/572) for tutorials that the documentation team has decided should exist as part of the tutorial series.
Pick an issue that covers a topic that you're either knowledgeable about or have a particular interest in.
Check referenced issues and pull request to make sure you won't duplicate work that someone else has already started!
There are more [tutorial requests](https://github.com/NixOS/nix.dev/issues?q=is%3Aopen+is%3Aissue+label%3Atutorial) than captured in the outline.
[Open a new issue](https://github.com/NixOS/nix.dev/issues/new?&template=tutorial.md) if what you wanted to work on isn't tracked anywhere.
This is an opportunity for you to clarify your goals, and an opportunity for everyone else to find out that there's interest in that subject.
### Submit an pull request with an outline
Submit a pull request with an outline of the tutorial following [our recommended structure](#structure).
The outline should contain bullet points on each section's content.
Reference the tracking issue from the pull request description to announce that you're working on a tutorial.
A review will ensure you're going in the right direction in terms of learning objectives and technical implementation.
### Expand on the outline
Elaborate the contents of the tutorial following your outline and the [](style-guide).
A review will ensure that you get all the required information in the right order without overwhelming learners.
### Follow up on review comments
Revise your tutorial based on the detailed feedback.
We recommend testing your tutorial with friends or coworkers.
This will both help with revealing implicit prerequisites as well as provide a realistic estimate of the reading time.
In a final review will check that everything is technically correct.
## Structure
Each tutorial should have the following structure:
Each tutorial should answer the following questions.
In addition, we strongly recommend the book [How Learning Works (summary)](https://www.lesswrong.com/posts/mAdMkFqWzbJRB544m/book-review-how-learning-works) as a guide for designing learning materials.
### What will you learn?
@ -46,10 +89,7 @@ This is important for learners to make sure they have the capacity to achieve th
The estimate will depend on the learner's pre-existing knowledge and proficiency.
You can note how optional skills or knowledge may influence reading time.
We recommend testing your tutorial with friends or coworkers.
This will both help with revealing implicit prerequisites as well as provide a realistic estimate of the reading time.
### Tutorial
### What to do?
Provide steps to achieve the learning goal.
These should take the form of direct instructions which repeatably lead to the desired outcome.
@ -78,24 +118,3 @@ We recommend making an explicit separation of practical from theoretical learnin
External resources should have a summary to set expectations, ideally including reading time.
Blog posts should have their original title in the link, and `(<author>, <year>)`:
Give authors credit, give readers an idea of how up to date the information is.
## Process
### Pick a topic
There is a [tracking issue](https://github.com/NixOS/nix.dev/issues/572) for tutorials that the documentation team has decided should exist as part of the tutorial series.
Pick an issue that covers a topic that you're either knowledgeable about or have a particular interest in.
Check referenced issues and pull request to make sure you won't duplicate work that someone else has already started!
### Submit an pull request with an outline
Submit a pull request with an outline of the tutorial following the above structure and containing bullet points on each section's content.
Reference the tracking issue from the pull request description to announce that you're working on a tutorial.
A review will ensure the work is going in the right direction in terms of learning objectives and technical details.
### Expand on the outline
Elaborate the contents of the tutorial following your outline and the [](style-guide).
In a final review will check that everything is technically correct.