06071d5abf
A large migration of documentation over to mkdocs, and some rewrites. Some stuff (install information, basic supported systems, contributors, thanks) are still staying in README.md, and CONTRIBUTING.md is essentially duplicated right now. However, stuff like configuration and key/mouse bindings are now moved to mkdocs. Some parts are still a bit WIP - it is definitely not done (documentation never seems to be...). However, it should be "good enough" for now, and I'm much happier working with the documentation in this form than trying to scroll through a giant endless README.md file. It also works much better for adding new documentation.
1.9 KiB
Documentation
When should documentation changes be done?
- Whenever a new feature is added, a bug is fixed, or a breaking change is made, it should be documented where appropriate (ex:
README.md, changelog, etc.) - New methods of installation are always appreciated and should be documented
What pages need documentation?
There are a few areas where documentation changes are often needed:
- The extended documentation (AKA here)
- The
README.md - The help menu inside of the application (located here)
- The
CHANGELOG.md
How should I add documentation?
-
Fork the repository first and make changes there.
-
Where you're adding documentation will probably affect what you need to do:
-
For changes to
README.mdandCHANGELOG.md, just follow the formatting provided and use any editor. -
For changes to the help menu, try to refer to the existing code within
src/constants.rson how the help menu is generated. -
For changes to the extended documentation, you'll want MkDocs, Material for MkDocs, and
mdx_truly_sane_listsinstalled to provide live reloading and preview for your changes. You can do so throughpipor your system's package managers. While you don't need these, it'll probably help in making and validating changes.
-
-
Once you have your documentation changes done, submit it as a pull request. For more information regarding that, refer to Issues and Pull Requests.