Skip to content

[WIP] Standards/Style Guide for Documentation of Home Assistant #3461

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

Merged
merged 5 commits into from
Oct 9, 2017

Conversation

dale3h
Copy link
Member

@dale3h dale3h commented Sep 28, 2017

NOT READY TO MERGE

Description:
I have started a list of documentation standards/styling guide, and would love to open the topic up to everyone for discussion.

  1. Is there anything here that seems absolutely absurd and should not be a standard?
  2. Is there anything you would like to add that is missing?
  3. Do you have any recommendations on how to lay it out in an orderly fashion?

This document/section will be expanding/changing quite a bit over the coming weeks (and possibly months), as we make our way through each of the documentation pages. Unfortunately, each page needs to be updated manually and cannot be batch processed. However, this also gives the opportunity to address and fix any syntax errors, logic errors, etc that we come across.

Please keep in mind that right now this is just "my thoughts" dropped into a quick Markdown file. This is why I am sharing it with all of you, so that we can address the rules of documentation as a community moving forward.

@onerealfunnyguy
Copy link

onerealfunnyguy commented Sep 28, 2017

some how some way, those writting the docs that know this stuff need to phrase it in a way that us noobs can understand so more people with lower skill levels have access to setting up a running system, vs talking to skilled linux users and admins

https://readthedocs.org ever lookin to some thing like this, says it build docs as git is commited, dont use it from that side, yet know I spend alot of time there for other app that use it.

@phillprice
Copy link
Contributor

One thing I've found as a new convert to HA is that I miss seeing simple things like what it will look like in the UI if I do something I know it would be tricky to keep UI changes upto date with each release.

There is tooling available through selenium and image checkers that could spot ui changes between builds and flag that a change in the docs may be required if that could help.

For instance in here there's not a single picture of how a light shows up in the ui, what happens when you click it to bring up the panel etc.

https://home-assistant.io/components/light.hue/

@frenck
Copy link
Member

frenck commented Sep 29, 2017

I think we should add some style guide to Markdown in general.
For example: http://guides.dealerdirect.io/code-styling/markdown/

Also, add some more automated checks on PR's. A full build might be too heavy, but we could add a liquid and Markdown linter and maybe even a tool like Alex.

@andrey-git
Copy link
Contributor

Using the new config format is important, but beyond that I think the rules will cause more harm than good unless there is hound-like CI to alert on them.

Imagine (I would assume a common) usecase of someone seeing a typo, a missing parameter, or a not-clear-enough explanation. They use the "edit this page" button and send a quick PR. Then a week later a reviewer asks them to fix their oxford comma. I would assume half of the people won't bother.

@ajfriesen
Copy link
Contributor

How about having a template for the different parts of documentation?
At least for the components, I could imagine that.

Just define some headings which most components share like:

  1. How to enable component
  2. Requierements
  3. Configuration Variables
  4. Platform Services
    1. Service A
    2. Service B
    3. Service n
  5. Retrieving the Access Token
  6. Specific information for HASSIO
  7. Examples

In the different sections we could write down some rules from your list or some best practice approaches. (If you start a new component, this could help.)
If a section is empty everybody knows there is help needed. If the section should be empty we could mark it as not necessary.

This is just a quick example and needs some work, but I think you get the idea.

@fabaff fabaff merged commit ba6e507 into current Oct 9, 2017
@fabaff fabaff deleted the standards branch October 9, 2017 18:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help-wanted Wanna help? Jump in!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants