You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have switched (back) from ReStructuredText (rst) to MarkDown as the default documentation format in the NLeSC Python template. This has historically been a slightly controversial choice in the Python ecosystem, where rst has been the norm (hence the original switch to rst in the template). Nowadays, MarkDown seems well supported as well. Since it is generally seen as easier to use, and we want to lower the barrier to people documenting their code as much as possible, it seems we should start recommending people to use MarkDown in the guide as well. We should probably also briefly motivate our choice there, for which the previous sentences could suffice. Further supportive material can be found in discussions via mail and in Teams chat of April 13th 2021. To give the full picture, the downsides should also be mentioned, so people can make their own well informed choice. Apart from the Python ecosystem dominance of rst mentioned already, rst may also scale better to larger documentation projects, like when writing large manuals. Furthermore, as highlighted by @merijn, MarkDown is a PITA to machine-read, whereas rst is not.
The text was updated successfully, but these errors were encountered:
Is this just about the package description on PyPI then? Or about the entire documentation?
For me, the reason to use markdown for the description of the package on PyPI is that you can conveniently re-use README.md that all GitHub projects have (by default?).
We have switched (back) from ReStructuredText (rst) to MarkDown as the default documentation format in the NLeSC Python template. This has historically been a slightly controversial choice in the Python ecosystem, where rst has been the norm (hence the original switch to rst in the template). Nowadays, MarkDown seems well supported as well. Since it is generally seen as easier to use, and we want to lower the barrier to people documenting their code as much as possible, it seems we should start recommending people to use MarkDown in the guide as well. We should probably also briefly motivate our choice there, for which the previous sentences could suffice. Further supportive material can be found in discussions via mail and in Teams chat of April 13th 2021. To give the full picture, the downsides should also be mentioned, so people can make their own well informed choice. Apart from the Python ecosystem dominance of rst mentioned already, rst may also scale better to larger documentation projects, like when writing large manuals. Furthermore, as highlighted by @merijn, MarkDown is a PITA to machine-read, whereas rst is not.
The text was updated successfully, but these errors were encountered: