-
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.
GitHub accounts: