3 Contributions are welcome! Here's how you can help:
5 - [Contributing code](#code)
6 - [Reporting issues](#issues)
7 - [Requesting features](#feature-requests)
8 - [Translating](#translations)
9 - [Donating](#donations)
13 1. [Fork](https://help.github.com/articles/fork-a-repo/) the repository and
14 [clone](https://help.github.com/articles/cloning-a-repository/) your fork.
16 2. Before you start coding, consider opening an
17 [issue at Github](https://github.com/minetest/minetest/issues) to discuss the
18 suitability and implementation of your intended contribution with the core
21 Any Pull Request that isn't a bug fix and isn't covered by
22 [the roadmap](../doc/direction.md) will be closed within a week unless it
23 receives a concept approval from a Core Developer. For this reason, it is
24 recommended that you open an issue for any such pull requests before doing
25 the work, to avoid disappointment.
27 You may also benefit from discussing on our IRC development channel
28 [#minetest-dev](http://www.minetest.net/irc/). Note that a proper IRC client
29 is required to speak on this channel.
33 [Lua API](https://github.com/minetest/minetest/blob/master/doc/lua_api.txt),
34 [Developer Wiki](http://dev.minetest.net/Main_Page) and other
35 [documentation](https://github.com/minetest/minetest/tree/master/doc).
36 - Follow the [C/C++](http://dev.minetest.net/Code_style_guidelines) and
37 [Lua](http://dev.minetest.net/Lua_code_style_guidelines) code style guidelines.
38 - Check your code works as expected and document any changes to the Lua API.
40 4. Commit & [push](https://help.github.com/articles/pushing-to-a-remote/) your changes to a new branch (not `master`, one change per branch)
41 - Commit messages should:
42 - Use the present tense.
43 - Be descriptive. See the commit messages by core developers for examples.
44 - The first line should:
45 - Start with a capital letter.
46 - Be a compact summary of the commit.
47 - Preferably have less than 70 characters.
48 - Have no full stop at the end.
49 - The second line should be empty.
50 - The following lines should describe the commit, starting a new line for each point.
52 5. Once you are happy with your changes, submit a pull request.
53 - Open the [pull-request form](https://github.com/minetest/minetest/pull/new/master).
54 - Add a description explaining what you've done (or if it's a
55 work-in-progress - what you need to do).
56 - Make sure to fill out the pull request template.
58 ### A pull-request is considered merge-able when:
60 1. It follows [the roadmap](../doc/direction.md) in some way and fits the whole
61 picture of the project.
63 3. It follows the code style for
64 [C/C++](http://dev.minetest.net/Code_style_guidelines) or
65 [Lua](http://dev.minetest.net/Lua_code_style_guidelines).
66 4. The code's interfaces are well designed, regardless of other aspects that
67 might need more work in the future.
68 5. It uses protocols and formats which include the required compatibility.
70 ### Important note about automated GitHub checks
72 When you submit a pull request, GitHub automatically runs checks on the Minetest
73 Engine combined with your changes. One of these checks is called 'cpp lint /
74 clang format', which checks code formatting. Because formatting for readability
75 requires human judgement this check often fails and often makes unsuitable
76 formatting requests which make code readability worse.
78 If this check fails, look at the details to check for any clear mistakes and
79 correct those. However, you should not apply everything ClangFormat requests.
80 Ignore requests that make code readability worse and any other clearly
81 unsuitable requests. Discuss in the pull request with a core developer about how
86 If you experience an issue, we would like to know the details - especially when
87 a stable release is on the way.
89 1. Do a quick search on GitHub to check if the issue has already been reported.
90 2. Is it an issue with the Minetest *engine*? If not, report it
91 [elsewhere](http://www.minetest.net/development/#reporting-issues).
92 3. [Open an issue](https://github.com/minetest/minetest/issues/new) and describe
93 the issue you are having - you could include:
94 - Error logs (check the bottom of the `debug.txt` file).
96 - Ways you have tried to solve the issue, and whether they worked or not.
97 - Your Minetest version and the content (games, mods or texture packs) you have installed.
98 - Your platform (e.g. Windows 10 or Ubuntu 15.04 x64).
100 After reporting you should aim to answer questions or clarifications as this
101 helps pinpoint the cause of the issue (if you don't do this your issue may be
102 closed after 1 month).
106 Feature requests are welcome but take a moment to see if your idea follows
107 [the roadmap](../doc/direction.md) in some way and fits the whole picture of
108 the project. You should provide a clear explanation with as much detail as
113 The core translations of Minetest are performed using Weblate. You can access
114 the project page with a list of current languages
115 [here](https://hosted.weblate.org/projects/minetest/minetest/).
117 Builtin (the component which contains things like server messages, chat command
118 descriptions, privilege descriptions) is translated separately; it needs to be
119 translated by editing a `.tr` text file. See
120 [Translation](https://dev.minetest.net/Translation) for more information.
124 If you'd like to monetarily support Minetest development, you can find donation
125 methods on [our website](http://www.minetest.net/development/#donate).
129 * This is a concise version of the
130 [Rules & Guidelines](http://dev.minetest.net/Category:Rules_and_Guidelines) on the developer wiki.*
132 These notes are for those who have push access Minetest (core developers / maintainers).
134 - See the [project organisation](http://dev.minetest.net/Organisation) for the people involved.
136 ## Concept approvals and roadmaps
138 If a Pull Request is not a bug fix:
140 * If it matches a goal in [the roadmap](../doc/direction.md), then the PR should
141 be labelled as "Roadmap" and the goal stated by number in the description.
142 * If it doesn't match a goal, then it needs to receive a concept approval within
143 a week of being opened to remain open. This 1 week deadline does not apply to
144 PRs opened before the roadmap was adopted; instead, they may remain open or be
145 closed as needed. Use the "Concept Approved" label. Issues can be marked as
146 "Concept Approved" to give preapproval to future PRs.
148 ## Reviewing pull requests
150 Pull requests should be reviewed and, if appropriate, checked if they achieve
151 their intended purpose. You can show that you are in the process of, or will
152 review the pull request by commenting *"Looks good"* or something similar.
154 **If the pull-request is not [merge-able](#a-pull-request-is-considered-merge-able-when):**
156 Submit a comment explaining to the author what they need to change to make the
157 pull-request merge-able.
159 - If the author comments or makes changes to the pull-request, it can be
161 - If no response is made from the author within 1 month (when improvements are
162 suggested or a question is asked), it can be closed.
164 **If the pull-request is [merge-able](#a-pull-request-is-considered-merge-able-when):**
166 Submit a :+1: (+1) or "Looks good" comment to show you believe the pull-request should be merged. "Looks good" comments often signify that the patch might require (more) testing.
168 - Two core developers must agree to the merge before it is carried out and both should +1 the pull request.
169 - Who intends to merge the pull-request should follow the commit rules:
170 - The title should follow the commit guidelines (title starts with a capital letter, present tense, descriptive).
171 - Don't modify history older than 10 minutes.
172 - Use rebase, not merge to get linear history:
173 - `curl https://github.com/minetest/minetest/pull/1.patch | git am`
175 ## Reviewing issues and feature requests
177 - If an issue does not get a response from its author within 1 month (when requiring more details), it can be closed.
178 - When an issue is a duplicate, refer to the first ones and close the later ones.
179 - Tag issues with the appropriate [labels](https://github.com/minetest/minetest/labels) for devices, platforms etc.
181 ## Releasing a new version
183 *Refer to [dev.minetest.net/Releasing_Minetest](http://dev.minetest.net/Releasing_Minetest)*