-
appguru / LMD
-
benrob0329
-
erlehmann
-
exe_virus
-
GreenXenith
-
ROllerozxa / Sublayer plank
-
j45
-
josiah_wi
-
wsor
These goals are intended to be accomplished in no particular time frame, however they are listed here roughly by priority.
-
Document the entire Lua API, it’s parameters, and return types consistently and in an easy to understand manner
-
Provide snippets for the recommended way to use non-trivial API componenets in as simple a manner as is practical
-
Cross reference engine source code (C++ and Lua) for ease of access
-
Cross reference existing documentation where more applicable (such as the Modding Book for tutorials, and the MTE repo for engine internals)
-
Host larger examples for more complex behavior and recommended API usage
-
Document engine limitations and known issues where applicable
-
Cover APIs other than the modding API, such as the menu API
We request the following from celeron55:
-
A new repository under the Minetest Github Organization called
minetest-docs
-
Said repository to be initialized with a CC-BY license (https://creativecommons.org/licenses/by/4.0/legalcode.txt)
-
Write access to this repository given to all team members above
-
All proposed changes must have 1 or more approvals from a Minetest-Docs team member other than the proposer, so as long as said approval is not also contested by another Minetest-Docs team member
-
To clearly show and explain the Minetest Lua API
-
To show and explain Lua examples for said API
-
To be linkable from The Web for ease of reference
-
To be accessible to any reader, regardless of skill level
-
To be accessible offline (not including hyperlinks to external resources)
-
To be able to be parsed by tooling, bots, and IDE plugins
Through these requirements, the following necessary features have been deduced:
-
Basic text, source code (preferably with syntax highlighting), tables, section links
-
The ability to convert to HTML for static site hosting
-
Macros or other meta features to assist with custom styling and constructs
-
Notifiers (
Info:
andWarning:
) as a nice-to-have -
Data output, library availability, or good consistency for easy parsing by tools
Through a loose vote (and some bikeshedding) we have concluded that AsciiDoc is our format of choice.
Don't want to bother but would like to make you aware of my MT core PR #13077 on the
doc
README improvementKeep on the good work and prosper.