mm-docs
mm-docs-template
Our great sponsors
| mm-docs | mm-docs-template | |
|---|---|---|
| 2 | 1 | |
| 16 | 7 | |
| - | - | |
| 5.6 | 7.3 | |
| 6 months ago | 6 months ago | |
| PowerShell | PowerShell | |
| GNU General Public License v3.0 only | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mm-docs
-
Stripe Open Sources Markdoc
I am glad to know there are those that put so much thought into documentation. Documentations is just another service, and deserves all the same methodology: CI/CD, tests, components, reuse etc.
As far as I can see, you can get similar workflow with combination of existing tools. I created this docker image that combines them for very easy consumption and created thousands of pages of technical, functional and user documentation with it:
https://github.com/majkinetor/mm-docs
- Show HN: Documentation system for any kind of project and documentation type
mm-docs-template
-
Why Your Company's Documentation Sucks
This view is too much simplified. If docs where tree vs graph we would probably have at least some orgs doing it right, while there are literarily almost zero.
Some of the important aspects of good documentation is:
1. Narrative style. You can't do ad hoc whatever wherever and call it a day. Most people don't have it and many are quite illiterate IMO. You need to practice this and most engineers don't like that. Hell, even most seniors don't like writing tickets IME which take almost the same time as putting garbage on Slack. I created templates on both GH and GL and almost nobody uses them even tho you don't need to think about anything but follow few rules.
2. Its quite hard to know what level of detail to put in documentation. You need a lot of experience for this - put to much, and it gets quickly outdated, put too little, and it doesn't convey much. Good documentation exists on multiple levels - as bunch of markup files "on the spot", as formal hi and low level documentation and also those are usually affecting different target groups so you actually need to design docs.
3. Documentation is a service. It has source code, build procedure, automatic link checking, export to bunch of format, crosslinks, variables, macros, configuration for different environments, abbreviations, definitions. Its quite hard to get it right. After years of struggle on different projects I finally created my own stuff [1] that I use on all projects, for docs spanning 50-500 pages. I maintain that for years now, constantly (so yeah, its a job).
[1]: https://github.com/majkinetor/mm-docs-template
What are some alternatives?
remark - markdown processor powered by plugins part of the @unifiedjs collective
log4brains - ✍️ Log and publish your architecture decisions (ADR)
ConvertOneNote2MarkDown - Ready to make the step to Markdown and saying farewell to your OneNote, EverNote or whatever proprietary note taking tool you are using? Nothing beats clear text, right? Read on!
Doxide - Modern documentation for modern C++. Configure with YAML, output Markdown, post-process with Material for MkDocs.
docs - Source code for the Streamlit Python library documentation
pydoc-markdown - Create Python API documentation in Markdown format.
markdoc - A literate programming package for Stata which develops dynamic documents, slides, and help files in various formats
docs - The documentation for Firefly III
docs - Documentation site for Markdoc
MkDocs - Project documentation with Markdown.
rst2nitrile - convert rst to latex books
Optic - OpenAPI linting, diffing and testing. Optic helps prevent breaking changes, publish accurate documentation and improve the design of your APIs.