Logo of Mineclonia
Mikita Wiśniewski

Content guidelines

This is an attempt at describing what goes on this Wiki, and what doesn’t, and minimize any potential friction in contributions.

1. LLM (genAI) usage

Using generative AI to write articles for you is forbidden. However, non-native (and esp. non-fluent) English speakers may use LLMs to help translate material from/to a language they speak, proof-read their grammar, spelling and punctuation, as well as provide general writing advice. However, asking LLMs to fact-check you is also forbidden.

Different countries have different legal stances on copyrightability of LLM-generated content (with most having no stance so far), but the general consensus (at least in the US and EU) is that creative human authorship is a prerequisite for a work to be copyrightable. There are also significant IP concerns with content produced by generative AI as LLMs have been shown to memorize copyrighted works and recite them given the right prompting with extreme precision[1]; given that Mineclonia cannot be described without mentioning a copyrighted work in itself (Minecraft), this is a big concern for our Wiki. It also doesn’t help that hallucinations are a natural part of genAI output and may only be mitigated, but never fully eliminated. Contributors must do their own research — seriously, it’s a block game, you won’t die from it.

2. Material scope

We defer to Minecraft Wiki for material which is already described there, meaning that this Wiki doesn’t document everything that is in Mineclonia. It would be needless effort with no benefit to the reader as Mineclonia already references the Minecraft Wiki when replicating its features. The Wiki also doesn’t document missing features or unfixed bugs, unless the Mineclonia team and the community decide not to implement/fix those; the reasoning is that such material would become outdated very quickly, and the Mineclonia issue tracker is already enough for that.

Yes to an article on in-game help, which is unique to Mineclonia, but no to an article on waxed weathered cut copper stairs ;)

3. Neutrality

Editors are asked to write from a neutral standpoint, neither praising Mineclonia (as much as we love it) nor scolding it for things we may not like; same goes for neighboring projects, like Luanti and VoxeLibre (but not Minecraft)[2]. This Wiki is not a forum or a tribune to express personal opinion, and we know from the long history of Luanti Minecraft clones that things tend to get heated in the community.

Yes to:

This feature was added back in the MineClone 2 days and was left in Mineclonia as a result of community discussion.

…but no to:

This “feature” was unfortunately added in the past and the mistaken players begged for it to stay at the expense of block game purity.

4. Writing style

Two main styles are used on the Wiki:

  • relatively formal, encyclopedic style for meta/technical articles, general descriptions of features/content, etc; and

  • a more casual, tutorial-oriented style with occasional uses of ‘you’ (in reference to the reader) and ‘we’ (in reference to the author(s) and the reader) for how-to sections and tutorial articles.

Regardless of the chosen style, editors should use American English spelling (“analyze” not “analyse”, “color” not “colour”, etc). Obscure, professional vocabulary is only permitted in technical articles, where the reader can be reasonably expected to look it up. Avoid awkward or overly complex grammatical structures, particularly ones that might trip up an automatic translator or an unfamiliar reader, and replace them with simpler alternatives wherever they appear.

5. Formatting

As was already mentioned, pages on this Wiki are written in MyST, or “Markedly Structured Text”, which is a Markdown (CommonMark) flavor with optional advanced syntax. Keep in mind that these exist mainly to prevent clean-up wars, and while these decisions were made arbitrarily, they were, after all, made, and should ideally be followed.

  1. Text lines are to be treated as paragraphs and are to be broken with a double line break. There is no column length limit. Lines should only be broken where a paragraph ends and another paragraph should begin.

  2. Footnotes (Bla bla bla[^note-name]. followed by [^note-name]: bla bla bla on a separate line) should be used instead of citations[3].

  3. Unordered list bullet points should be asterisks (*), not minuses (-). List elements are nested with 4 space characters per level.

  4. Multiline code sections should be formatted by enclosing them in triple backticks (“```”) before the first line and after the last line, as opposed to indenting them 4 spaces to the right. Wherever possible, a short name for the language should be written after the opening triple backticks to enable syntax highlighting (see Pygments’ language list).

  5. Inline formatting should be used sparingly. If an emphasis must be specified somewhere within a sentence, prefer italics over boldening. Double asterisks (**) are preferred for bold text and single underlines (_) are preferred for italics.

  6. Plaintext URLs (<https://example.com/>) should never be used in articles or footnotes (references); instead, they should have a proper text labeling them ([Example](https://example.com/)).

6. Be bold!

Aside from disallowed LLM (genAI) usage and obvious vandalism, every change is valuable and we will help you refine it and get it onto the Wiki. Please don’t be scared by the long list. Don’t care about it! As a Wikipedian would say, be bold and carry on.