Documentation Structure

[metcoder95]

Based on Fastify#2071, it seems that the overall agreement is the lack of structure of our documentation, rather than the precision or amount of documentation itself.

If we focus first on structuring our documentation in a way that is easier to filter, extend and manage; adding and improving documentation content/details should be an easier task for us and for any contributor of the project.

The structure that seems to be the most suggested is the Divio#Documentation Framework. On a higher-level the structure seems nice, easier to filter, manage and extend.

We already have a set of sections in mind that we would like to converge, like Plugins, Guides, and References. We can come with a mixed result based on the structure suggested an our needs.

Following the documentation and our current setup; I was imagine something similar to this:

• Documentation Home
• Technical Principles
• Use Cases
• Guides (should be ordered alphabetically)
  • Getting Started
  • v3 Migration Guide (shall we remove it?)
  • v2 Migration Guide (shall we remove it?)
  • The Hitchhiker's Guide to Plugins
  • Prototype Poisoning
  • Serverless
  • Testing
  • Write-Type-Provider
  • TypeScript Best Practices
  • Encapsulation
• References
  • Content Type Parser
  • Decorators
  • Errors
  • HTTP2
  • Hooks
  • LTS
  • Lifecycle
  • Logging
  • Middleware
  • Plugins
  • Reply
  • Request
  • Routes
  • Server
  • Type Providers
  • TypeScript
  • Validation and Serialization

[metcoder95]

cc: @Eomm