Tutorials are the success documentation emerging from engineering project documentation.
Engineering projects document how teams organized themselves to jump into the unknown, what happened, what worked, what did not work and a vision of next steps if the project were to be continued. Tutorials are the first manuals, the first training course, the first document handed to customers that want to repeat an engineering success.
Engineers have to learn things. They can not make their ignorance an engineering problem. They have to learn quickly. They learn just enough to do the project. They don't learn everything. They don't become experts. They hate open ended tutorials that have no specific goal. If the tutorial doesn't serve the project at hand, then it is a bad tutorial.
Each engineer has different backgrounds, talents and enthusiasms. So they are going to want to survey many different, self paced tutorials on the same subject. Engineers are going to want different starting points. They are going to want some tutorials to work backwards, (reverse engineer), they are going to want some tutorials that work forward with clear goals.
The goal is to prepare engineers for their current project as quickly as possible. If a tutorial is not exactly suited to the engineers background and current project (which is usually the case), then the engineer has the responsibility forking the tutorial (making copy and then modifying it with different objective, different starting point) or editing the existing tutorial.
Engineers can start a completely new tutorial on the same subject. They can forward engineer with a slightly different objective. They can reverse engineer a slightly different product.
These tutorials are not intended to support manufacturer certifications or any specific tool expertise. They may be used by more than one project.
When these goals don't satisfy a particular engineer, they have the responsibility of improving/forking the tutorial.