update the tutorial guide, add issue template

.github/ISSUE_TEMPLATE/tracking-issue.md

@@ -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
 ---

source/contributing/documentation/writing-a-tutorial.md

@@ -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.