Thanks @hogepodge for the RFC. It would be great for us as a community to
converge on a documentation system that we can all collaborate together.
Based on the current proposals, I find that it might be helpful to dissect the
possible choices here to facilitate the discussion(since we might want to pick
some of the good choices from each of the layouts). Here are some of the
choices I tried to capture from the current candidates(with possible choice
labels so to help the discussion). Note this is only based on my reading and
they may be incomplete(please feel free to suggest more)
## Q0: Tutorial and How to/Demo Terminology
This seems to be the main difference between L1/L0 and L2
- Q0a: Separate Tutorial from How_to
- Tutorial is about lecture
- Q0b: Combine Tutorial and How to
- Rename some of the how_to to "Demo"
## Q1: Whether Include Beginner Facing Tutorials in Getting Started
One pattern that L2 introduces is include beginner facing "bltiz
course"(tutorial) in the Getting Started Section.
- Q1a: Include a "bliz course" style tutorials on the Getting Started
- Q1b: Only include landing page with links to the tutorial section
## Q2: Whether we want API reference to be on top-level
- Q2a: Keep API reference as sub section of user guide
- Q2b: Keep API reference as a flat top level section for better accessibility.
## Q3: How to Organize Developer Documentation
L0/L1 focuses on a more separated organization, by introducing
tutorials/how_to/deepdive(architecture guide) sections.
L2 seems to advocate for a more component first view, by focusing on the
architecture components and their relations, and embed `how_tos` in each of
the sub component. To elaborate a bit, one possible choice could be
```text
Architecture Guide
- Frontend
- Description of the frontend module and its relation to the rest
- How to add a new frontend
- Runtime system
- description of the runtime
- How to add a new PackedFunc
- Relay Layer
- How to add an new operator
```
Notably, the way to teach the design architecture can differ from the best way
to teach users. It might be more important to have a "global picture" before
drilling down, this could mean that there is more weights on the architecture
guide than a tutorial style guide(which I believe is what L2 tries to get at).
As a result, here are a list of possible choices
- Q3a: Keep developer how to/tutorial, and include a L2 style architecture
guide in the place of deep dive.
- Q3b: Embed most of the how to and guides in the specific component of
architecture guide, with the rationale that developers will need to first
understand the component to do development.
- Q3c: Keep an architecture guide that contains the components and their
relations. Combine it with developer tutorial. Have a separate developer how to
in parallel to the component guide for quick search to find actions like "How
to add a new relay op".
## Q4: Choice of Specific SubTopic Page
For topics like microTVM and VTA, there are multiple ways to organize them.
- Q4a: Organize most of the topics under the current system(e.g.
tutorials/how_to) and provide a landing page in get started with links to each
of them
- Q4b: Organize the topics under a Topics section, and keep documents local to
each of the subtree.
---
[Visit Topic](https://discuss.tvm.apache.org/t/updated-docs-pre-rfc/10833/4) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/unsubscribe/2ec4a632d2250ef2dfa5db96113ed3b3fa7ec368af161fbda2f31c390d14707d).
