@thedavid will write the actual Tutorials QA topic, so this article is offering a few suggestions about that workflow:
-
There is no benefit in treating the Tutorial as two separate tutorials - since it is really just one .md article and testers do need the gradual approach, Tutorial I followed by Tutorial II.
-
There will be many people testing many chapters of the tutorial, what data container should be used to report and discuss QA findings? Discourse seems like a candidate - except that it does not support nested responses (see Discourse CAN show nested replies? - feature - Discourse Meta). If we can accept the feature described in the next quoted paragraph, proposed by Discourse:
There’s also an alternative option for this feature that temporarily hides the posts in-between replies rather than duplicating them (which moves away from the appearance of nesting). That site setting is called
enable filtered replies viewif you’re curious.
- We may use a newly created QA topic with as many subtopics as there are chapters in the Tutorial. To further simplify the reporting data structure, each person on the QA team should be assigned several chapters and that person then owns the items in this person’s subtopic
Each tester can create a repo on Github, where the details of a specific report are kept as GitHub issues - like this example, which I would report if the QA session has already started.
People with other ideas, please pitch in, even if I expect that @thedavid will first rewrite this post, to his taste.