I have made some suggestions that could become a presedicent for future tutorials. If the structure/content is agreeable, then I will gladly work on further diving into some of the concepts more in-depth and polishing this:

Changes: There is an overall structure, a 'rustling' vibe. This would provide a guide to adding steps, and giving all necessary background info, and the outcome from this step:

• Step 0 - Defining a pallet
  • Context: Project Setup and Background Knowledge
    • Project Setup
    • Background Knowledge: State Transitions
  • Tutorial Objectives
  • In the Code
  • Implementation

Goals:

• Relatively concise
• Use more diagrams to show relationships between crucial parts of FRAME
• Explain specific outcomes from this step, and ensure all steps connect to one another.
• Reflect these changes in SCRIPT.md so anyone can replicate
• We should use LOTS of links back to the Rust docs for various types and macros :) (didn't do here, but will do if this is a good way to go)

Suggestions:

• Is it possible to host this in a mdBook, that way t he progression is better highlighted and trackable?
• What are the thoughts on heavily commented code, or should it be left blank whilst the README contains all the explaination?

I think this is a great example of a page that should have been entirely documented in rust-docs: it is almost entirely copy-pasted, and extremely hard to maintain: https://docs.substrate.io/reference/command-line-tools/node-template/

We should focus on the documentation of the crate https://paritytech.github.io/substrate/master/sc_cli/index.html and improve it such that this page can act as the single source of truth for CLI args.

This crate should be linked in #11.

Recall:

• Both the master tutorial's (#3) written code and reference docs (#4) will have code snippets.
• None of these should to be hardcoded and all must come from valid sources that can be checked for validity, such as a git permalink.

We need a system to build this, using Gatsby.

Note that some more details might change as we flesh out how the master tutorial is being built. Perhaps, if we use diff files to denote each step of the tutorial, the snippets must come not from a permalink, but instead from a diff file.

Moreover, we should also explore embedding pieces from docs.rs.

So that we can hack it a bit to look more custom made.

Also, there are a few hacks that if we find answers to, we can use:

1. https://github.com/paritytech/substrate/issues/13818
2. Make it show tests, examples, and so on
3. Easier distinction between types that are storage and not.
4. Easier distinction between enums and struct that are part of pallet macros and those that are not.
5. Easier distinction between functions that are getters.
6. Easier distinction between functions that are dispatchables.

Some of these are being handled in an https://github.com/paritytech/substrate/tree/kiz-improve-fast-unstake-dcos, but in hacky ways.

Some ideas from GPT-4:

Rustdoc is a tool that generates documentation for Rust projects from doc-comments within the source code. While the default rendering is sufficient for most use-cases, you might want to customize it to better suit your needs or preferences. Here are a few hacks to tweak the rendering of Rustdocs:

Custom CSS:
You can add custom CSS to change the appearance of the generated documentation. Create a new CSS file, and include it in your Cargo.toml under the [package.metadata.docs.rs] section:

toml
Copy code
[package.metadata.docs.rs]
rustdoc-args = ["--html-in-header", "path/to/your/custom.css"]
Now you can add any CSS rules to the custom file to modify the appearance of the Rustdoc output.

Custom JavaScript:
If you need more advanced control over the rendering, you can add custom JavaScript to the generated docs. Create a new JavaScript file and include it in your Cargo.toml as well:

toml
Copy code
[package.metadata.docs.rs]
rustdoc-args = ["--html-in-header", "path/to/your/custom.js"]
With JavaScript, you can reorder sections, hide or show elements, or make other changes to the DOM as needed.

Modify the theme:
Rustdoc has a built-in theme switcher. You can create a custom theme by modifying the theme CSS files located in the src/librustdoc/html/static/themes directory in the Rustdoc source code. You can then include your custom theme in your project, allowing users to switch to it using the theme switcher.

Custom HTML templates:
Rustdoc uses Handlebars templates to generate the HTML output. You can create your own templates to customize the structure of the generated documentation. You'll need to modify the Rustdoc source code, located in the src/librustdoc/html directory, and then build a custom version of Rustdoc to use with your project.

Fork Rustdoc:
If you need extensive customization, you can fork the Rustdoc project, make your desired changes, and use your custom Rustdoc version to generate documentation for your projects. This approach allows you to have full control over the output and functionality but requires more effort to maintain and stay up-to-date with the official Rustdoc releases.

Remember that making significant changes to the appearance or structure of Rustdocs can make it harder for other Rust users to navigate and understand your documentation. Be cautious with customizations and consider the impact on usability before implementing them.