Sorry, I must not have explained myself well enough. For dtdocs, we have pretty much chosen our tool chain, and we intentionally did not announce anything to avoid this type of bike shedding.

While markdown has its negatives, the positive is that if you've written a comment on the internet in the last several years, you've probably written markdown, if you know so or not.

By "actionable criticism," I meant please make sure your criticism is applicable and actionable on the current dtdocs project. I don't think we're interested in generalized markup discussion, tool chain discussions, or any thing else of that sort. Again, the decisions have been made. If you feel we've absolutely made the wrong decision with markdown, you're free to fork the repo, convert it to the markup flavor that suits you, and edit the content there.

We won't use RTD since the point is that we host the documentation ourselves. Hugo gives us a pretty simple and straight forward way to publish things, the dependencies are very minimal, and it integrates well into CI systems. If you feel that things are missing, please open an issue, but the sentiment of "eventually it'll be missing something because tool XYZ is better" isn't really helpful.

For context: my profession is documentation and has been for the last 12 years. I've maintained large documentation sets in LaTeX, docbook, DITA XML, FrameMaker, and more. I've maintained docs using just git and I've maintained them using proprietary systems that cost millions of dollars. I've architected new documentation sets that covered hundreds of products and customized the publishing pipeline around them.

- mica

On 10/16/20 5:13 PM, Moritz Moeller wrote:
On 17.10.20 01:41, Mica Semrick wrote:
You have specifically pointed out where you think markdown is falling short in this case.

For me MD vs Sphinx is mostly about roles, extensions, citations, line comments, footnotes etc. that you have in Sphinx but not in MD. MD was designed for writing texts on the Web. ReST + Sphinx was designed for writing documentation.

Here is a longer version of that, written by someone else:
https://eli.thegreenplace.net/2017/restructuredtext-vs-markdown-for-technical-documentation/

With that said: I prefer MD syntax over ReST any day as long as it doesn't take anything away I think is standard for good documentation.
E.g. being able to have an index auto-generated.

Sadly it does. Worst, there is no real standard in MD.
CommonMarkdown is different everywhere. Maybe a feature you grew fond of when using MD in Jupyter Notebooks' MD is not available on GiHub's MD etc.

 > Feedback is welcome, but please try to make it actionable. We're
 > aiming for improvement.

With the above in mind – if I were to start a documentation project now I'd probably use this:
https://myst-parser.readthedocs.io/en/latest/

Which is kinda ReST + MD having a baby. :)

It would mean all the work you done could be used, mostly as-is.
But you would have all the bonuses of ReST + Spinx on top that MD + Sphinx would not give you. Even if you switched from MD + Hugo to MD + Sphinx.

Oh, and use readthedocs to handle building and serving.

Because, again, that is an ecosystem build for serving documentation as static pages online.
Hugo is nice but it was meant to build static websites.
Which surely represent a superset, containing static online documentation, but broad enough that it will leave many things to be desired, sooner or later.

And btw: https://darktable.readthedocs.io/ is available. ;)


Beers,

.mm


P.S.: For context:
I wrote software documentation in MD several times during the last decade.
I wrote software documentation in ReST using Sphinx several time (that was before Sphinx added MD support).
I also have BG writing docs in LaTex from way before.

With that being said I feel entitled to be opinionated about the subject.
And mind you, I am talking about the perspective of the writer, not the user.
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Reply via email to