Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[R4R] ADR: New docs structure #2696

Merged
merged 6 commits into from
Nov 13, 2018
Merged

[R4R] ADR: New docs structure #2696

merged 6 commits into from
Nov 13, 2018

Conversation

gamarin2
Copy link
Contributor

@gamarin2 gamarin2 commented Nov 5, 2018

This PR proposes a new structure for SDK docs that we discussed with @zramsay. It would clear the SDK repo of unnecessary content and would make it much easier for devs to find what they need to update. It would also help if we want to have executable documentation in the future (cc @cwgoes).

Here are the current steps for the docs refactor #2697

@codecov
Copy link

codecov bot commented Nov 5, 2018

Codecov Report

Merging #2696 into docs-overhaul will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           docs-overhaul    #2696   +/-   ##
==============================================
  Coverage          58.01%   58.01%           
==============================================
  Files                153      153           
  Lines               9511     9511           
==============================================
  Hits                5518     5518           
  Misses              3632     3632           
  Partials             361      361

@gamarin2 gamarin2 changed the base branch from develop to docs-overhaul November 5, 2018 19:56

The files in each sub-folders do not matter and will likely change. What matters is the sectioning:

- `README`: Landing page of the docs. Goal is to have a short explainer of the SDK and then channel people to the resource they need. The [sdk-tutorial](https://github.com/cosmos/sdk-application-tutorial/pulls) will be highlighted, as well as the `godocs`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rm /pulls from the link

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great. Like the areas highlighted here!


- `README`: Landing page of the docs. Goal is to have a short explainer of the SDK and then channel people to the resource they need. The [sdk-tutorial](https://github.com/cosmos/sdk-application-tutorial/pulls) will be highlighted, as well as the `godocs`.
- `gaia`: Contains all docs related to the `gaia` application. Will later be renamed to `cosmos-hub` or `chub` and probably moved to its own repository.
- `reference`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about swagger? https://cosmos.network/rpc/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the clients section

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you think we should ditch the /rpc/ endpoint on the site?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessarily. The swagger doc can be linked from the clients section. I don't think swagger doc can be integrated in a vuepress site, or can it?

@gamarin2 gamarin2 mentioned this pull request Nov 5, 2018
- `README`: Landing page of the docs. Goal is to have a short explainer of the SDK and then channel people to the resource they need. The [sdk-tutorial](https://github.com/cosmos/sdk-application-tutorial/pulls) will be highlighted, as well as the `godocs`.
- `gaia`: Contains all docs related to the `gaia` application. Will later be renamed to `cosmos-hub` or `chub` and probably moved to its own repository.
- `reference`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
- `examples`: Contain a couple examples of sdk application liker `bascoin` and `democoin`. Developers need to maintain them up-to-date and make sure they compiles as the SDK gets upgraded.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

liker, bascoin

keep them up-to-date ... compile

- `gaia`: Contains all docs related to the `gaia` application. Will later be renamed to `cosmos-hub` or `chub` and probably moved to its own repository.
- `reference`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
- `examples`: Contain a couple examples of sdk application liker `bascoin` and `democoin`. Developers need to maintain them up-to-date and make sure they compiles as the SDK gets upgraded.
- `clients`: Contains specs and infos about the various SDK clients.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

info

- Intro (`README`)
- `gaia`
- `reference`
- `clients`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why only these three?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

explained just after

- `reference`
- `clients`

`architecture` and `examples` need not be displayed on the website. As for `modules`, we might need to think about creating a modules manager, but this is out of scope for this document.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the files get rendered by virtue of being .md files, so they're accesible by default, even if not linked in the sidebar

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, this is what matters (that they're not in the sidebar)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @gamarin2 here


### Neutral

- We need to move a bunch of deprecated stuff to `/attic` folder.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_attic

Copy link
Contributor

@zramsay zramsay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should add a section about swagger and the lite RPC. also would be good to mention the DOCS_README.md somewhere

### Neutral

- We need to move a bunch of deprecated stuff to `/attic` folder.
- We need to port most of the content in `docs/sdk/docs/core` in `reference`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, hm, i moved that into _attic FTTB

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, let me rephrase. For now, _attic, but the content is good and most of it could fill parts of the reference

Copy link
Member

@jackzampolin jackzampolin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of small comments, but this looks great! Can't wait to see implementation here.

│ ├── basecoin/
│ └── democoin/
├── clients/
│ ├── lite/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the CLI client?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, this tree is not the definitive docs tree, just a more or less accurate example! what matters are the section.

│ ├── validator-node.md
│ ├── validator-faq.md
│ └── delegator-faq.md
├── reference/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like all new content?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I presume this is the old SDK spec?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, the spec should stay in the same place

- `reference`
- `clients`

`architecture` and `examples` need not be displayed on the website. As for `modules`, we might need to think about creating a modules manager, but this is out of scope for this document.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @gamarin2 here

@gamarin2 gamarin2 changed the title ADR: New docs structure [R4R] ADR: New docs structure Nov 5, 2018
Copy link
Contributor

@cwgoes cwgoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments. I'm not sure this should be an ADR - it might be nice if we keep ADRs to decisions about the technical architecture of our code, instead of the documentation, as the latter isn't necessarily relevant to the target audience (someone trying to understand our decisions or reimplement parts of our work elsewhere).

│ ├── validator-node.md
│ ├── validator-faq.md
│ └── delegator-faq.md
├── reference/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I presume this is the old SDK spec?

- `reference`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
- `examples`: Contain a couple examples of sdk application like `basecoin` and `democoin`. Developers need to maintain them up-to-date and make sure they compile as the SDK gets upgraded.
- `clients`: Contains specs and info about the various SDK clients.
- `modules`: Contains specs of modules.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gaia modules, right (like we have at the moment)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Until we figure out a better decision for module management.


### Neutral

- We need to move a bunch of deprecated stuff to `/_attic` folder.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we instead delete it? Git keeps full history, we can always restore it later. Leaving files around in _attic just creates clutter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gamarin2
Copy link
Contributor Author

gamarin2 commented Nov 6, 2018

Where would you put such records then? Tendermint does have ADR related to documentation tendermint/tendermint#2313.

The goal of this doc is to understand why we're making these changes, getting consensus on them and keeping a record. Wdyt @zramsay?

@cwgoes
Copy link
Contributor

cwgoes commented Nov 6, 2018

Where would you put such records then? Tendermint does have ADR related to documentation tendermint/tendermint#2313.

Alternatively we could just put this in a file in the root of the docs folder, but I don't have a strong opinion.

@codecov
Copy link

codecov bot commented Nov 13, 2018

Codecov Report

Merging #2696 into docs-overhaul will increase coverage by 0.11%.
The diff coverage is n/a.

@@                Coverage Diff                @@
##           docs-overhaul    #2696      +/-   ##
=================================================
+ Coverage          57.92%   58.03%   +0.11%     
=================================================
  Files                129      153      +24     
  Lines               8270     9511    +1241     
=================================================
+ Hits                4790     5520     +730     
- Misses              3162     3630     +468     
- Partials             318      361      +43

@gamarin2 gamarin2 merged this pull request into docs-overhaul Nov 13, 2018
@gamarin2 gamarin2 deleted the gamarin/docs-adr branch November 13, 2018 17:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants