Admin: Documentation Structure

[dongsam]

Apply a better documentation structure by referring to cosmos-cash before the production level release.

But currently, the farming module spec is frequently changed, so we are prototyping to the PoC level, therefore we plan to write detailed documentation of How-To and Tutorials after the alpha version.

A basic document format or spec doc can be applied in advance, regardless of the direction of the code.

In addition, for quick decision-making and development, the initial Spec will be applied to the Spec without the ADR process, and major changes need to be discussed or decisions after the release will be subject to the ADR process.

/
├── README
├── CONTRIBUTING
├── TECHNICAL-SETUP
├── CODEOWNERS
├── x/
|   ├── module_a/
|       ├── README
|       ├── docs/
|           ├── state
|           ├── state_transitions
|           ├── messages
├── docs/
    ├── README
    ├── CODEOWNERS
    ├── Explanation/
    |   ├── README
    |   ├── ADR/
    |   |   ├── README
    |   |   ├── PROCESS
    |   |   ├── adr-template
    |   |   ├── adr-{number}-{desc}
    |   ├── articles/
    |   |   ├── regulation-litepaper/
    |   |       ├── ARTICLE
    |   ├── research/
    |       ├── README
    |       ├── research_topic/
    ├── How-To/
    |   ├── HowToDoSomething/
    |   ├── HowToDoSomethingElse/
    ├── Reference/
    |   ├── README
    |   ├── GLOSSARY
    |   ├── MODULES
    |   ├── use-cases/
    |   |   ├── use-case-A
    |   |   ├── use-case-B
    |   ├── architecture/
    ├── Tutorials/
        ├── Tutorial_1/
        ├── Tutorial_2/

Ref.

• https://github.com/allinbits/cosmos-cash/blob/main/docs/Explanation/ADR/adr-002-docs-structure.md

[minkyraccoon]

Comment: ADR's SHOULD NOT be optional. If a POC is built then a decision must have been made and documented. The purpose of the ADR is to describe the architecture and get feedback on it. ADR's can be used to do this.
Likewise, if you discover that the PoC has an issue and needs a new implementation (e.g. F1) then this can be raised in a new ADR. Now we have a record next to the code of why the module has been implemented the way it is.
The advantage now is that instead of having to explain the design every time, people can find and read the documentation for themselves.