Manifest of the Minetest-Mods team and Mod content

This document describes the organization and requirements of the Minetest-Mods team, it’s goal and regulations.

Goal of this project

This project exists to provide a method for minetest players and server operators to have a semi-trusted source of Minetest Mods.

Minetest mods are distributed separately and there is not a single source of mods. This has lead to hundreds of Minetest Mods around in equal amount of locations on the internet, and this is bad for players, server operators and developers alike.

By providing a single hosting namespace for Minetest mods, this project serves as a method of telling users that a specific version of a Minetest mod is the preferred or recommended version of that mod. This helps to alleviate the issues of having many forks of Minetest mods around.

Authors of Minetest Mods that host their mods in the minetest-mods project explicitly allow the minetest-mods admins to merge changes into their mods. This allows the authors of these mods to “sign out” for a while knowing that their mods are being taken care of, and provides a method for users to continue using the exact same mods long after the original author has moved on since these mods will still be maintained.

Contents of the project

This project hosts any minetest mod that mod authors have contributed to the Minetest Mods project, permitted these mods are properly licensed as an Open Source project, and do not present any other legal issues.

The project admins reserve the right to discontinue, remove or refuse any project based on legality, content or other, at their discretion.

New mods are not being accepted into the project at this time

The original author of the mod should be the one submitting it to the minetest-mods project. Only in exigent circumstances will a mod fork be allowed, and admins reserve the right to refuse mod forks at their discretion. In general, forks are only allowed if the original author clearly no longer maintains the project, and if the project has been properly licensed by the original author, and last, that the project license has remained unchanged in the fork.

Modpacks (groups of mods bundled together) are not permitted in minetest-mods, as they make management more difficult and prevent users from installing only parts of of a modpack. For cooperative maintenance of modpacks, see the minetest-modpacks team instead, or look at the minetest-games project. (At the time of writing of this document, those two teams/projects do not exist).

Mods should ensure that they have all the needed files present to assure dependencies and mod metadata is present. description.txt is required to be present, and we strongly urge mods to have mod.conf present, as well as a screenshot.png file, a LICENSE file and a README.md file as well.

Member organization

The project’s team members are organized into specific roles:

1. project administrator (admin)

Project administrators have full access to all minetest-mods projects, and can create new ones, merge PR’s in any project, push code to any project, remove any project from the minetest-mods project, maintain memberships and permissions.

2. project author (author)

3. individual contributor (committer)

Namespace Organization

Many different versions of mods exists, and many mods have similar names but sometimes provide very different functionality. For the purpose of clarity, comflicting names are to be prevented, and mods in the minetest-mods project should have clear and unambiguous names.

Namespace organization may require admin and author to cooperate to establish proper API’s and propagate their use through other mods. Authors reasonably should join this discussion and cooperate, to avoid mod conflicts and improve mod harmony.

A note on legacy

Mod author and admin should do their best to avoid supporting a legacy of old world data, as this generally does not provide the best atmosphere to develop new mods and mod features going forward. At times it may be best to remove support for old minetest game versions, old APIs or game object types. We encourage people to provide fallback code for old code, but would prefer if people code with a healthy attitude of cleaning out old code instead.

As such, we recommend that people actively remove code that exists solely for the purpose of old world data, old game versions or old supporting mods. For the purpose of this document, “old” means “more than 1 year old, or 365 days”. While admins do not want to police or enforce this rule, they retain the privilege to remove code that violates this rule at their discretion.