Difference between revisions of "Organisation"

From Minetest Developer Wiki
Jump to navigation Jump to search
m
Line 1: Line 1:
−
== Original pre-text ==
 
−
With the goal of lessening the likeliness of pull requests being left hanging around, making it clearer who knows what, giving more motivation via responsibility and change for the sake of change, Minetest's organization update of 2014-01-02:
 
−
 
 
== Core developers ==
 
== Core developers ==
 
Core developers have special privileges and responsibilities compared to other contributors:
 
Core developers have special privileges and responsibilities compared to other contributors:
−
* Can vote for and against merging pull requests (or if being the subsystem's maintainer, can directly decide)
+
* Can vote for and against merging pull requests (Two for-votes are required for code to be mergeable upstream.)
 
* Has write access to the minetest team's repositories on github
 
* Has write access to the minetest team's repositories on github
−
* If assigned a subsystem, should take care of it (doh)
 
  
 
Core developers are assigned and unassigned by celeron55, based on these rules:
 
Core developers are assigned and unassigned by celeron55, based on these rules:
Line 14: Line 10:
 
* Core developers, like other contributors, should document and publish their work in a way that allows another contributor to pick up on it if the core developer stops working on the project due to any reason.
 
* Core developers, like other contributors, should document and publish their work in a way that allows another contributor to pick up on it if the core developer stops working on the project due to any reason.
  
−
== Subsystem maintainers ==
+
== Past major changes ==
−
The engine is split into virtual "subsystems" based on the most easily definable but still meaningful parts of the code (mostly each file should belong to one subsystem, but this is not strictly possible).
+
2015-11-02: The subsystem maintainer method was officially taken out of use. See the history of this page for details about how it worked.
−
 
 
−
Each subsystem is allocated to one core developer, who then becomes a "subsystem maintainer", who is responsible for making sure pull requests get handled and fixing the subsystem if it doesn't work. Subsystem maintainers are trusted to give their permissions and/or responsibiltiies to someone else too if they see fit.
 
−
 
 
−
Subsystem maintainers can be proposed to the core team by anyone (preferably by themselves or by the previous one), and they are not-so-officially majority voted. The person on "maintainer conflicts" can turn down proposals on the basis of wrong direction or too much controversy (as rarely as possible).
 
−
 
 
−
The old rule of merging if two core developers agree still stays valid. It is useful in cases when the appropriate maintainer is away or does not have time.
 
−
 
 
−
== Github ==
 
−
 
 
−
Each issue and pull request should be assigned to a subsystem using the appropriate section label.
 
−
For example, pull request [https://github.com/minetest/minetest/pull/7 #7] would get the label "Section - Build".
 
−
 
 
−
== Subsystems ==
 
−
 
 
−
{| class="wikitable" style="background-color: #cfd;" width="80%"
 
−
|'''Developer'''
 
−
|'''Subsystem '''
 
−
|- style="background-color: #fff;" width="80%"
 
−
|celeron55
 
−
|maintainer conflicts
 
−
|- style="background-color: #eee;" width="80%"
 
−
|sapier
 
−
|server/client/env
 
−
|- style="background-color: #fff;" width="80%"
 
−
|kahrl
 
−
|startup/config/util
 
−
|- style="background-color: #eee;" width="80%"
 
−
|ShadowNinja
 
−
|script API
 
−
|- style="background-color: #fff;" width="80%"
 
−
|hmmmm/kwolekr
 
−
|mapgen
 
−
|- style="background-color: #eee;" width="80%"
 
−
|celeron55 [HALF-OPEN]
 
−
|client/audiovisuals
 
−
|- style="background-color: #fff;" width="80%"
 
−
|nrzkt/nerzhul
 
−
|low-level network
 
−
|- style="background-color: #eee;" width="80%"
 
−
|''[OPEN]''
 
−
|build system
 
−
|- style="background-color: #fff;" width="80%"
 
−
|''[OPEN]''
 
−
|masterserver
 
−
|- style="background-color: #eee;" width="80%"
 
−
|ShadowNinja
 
−
|Documentation
 
−
|- style="background-color: #fff;" width="80%"
 
−
|''[OPEN]''
 
−
|Translation
 
−
|}
 
−
 
 
−
== Changelog ==
 
−
 
 
−
2015-02-10: low-level network: sapier ->  nrzkt/nerzhul
 
−
 
 
−
== Subsystem Files ==
 
−
 
 
−
(TODO)
 
−
 
 
−
=== Maintainer conflicts ===
 
−
 
 
−
Meta-subsystem with the task of resolving conflicts between other subsystem maintainers that they can't solve themselves.
 
−
 
 
−
== Proposed ==
 
−
 
 
−
These can be created if people who are interested in taking reponsibility of such things join the project.
 
−
 
 
−
=== Proposed: releases ===
 
−
 
 
−
Meta-subsystem with the task of maintaining a reasonable release schedule by deciding when to do it, what is missing and announcing feature freezes and poking the necessary people to make it happen. The most important tasks are to make sure every subsystem maintainer knows when there is a feature freeze and when there is not, and to manage the tags and branches on github.
 
−
 
 
−
=== Proposed: voting/community ===
 
  
−
Meta-subsystem with the task of figuring out and remembering what the community wants by reading discussions and arranging votings, and being a source of that kind of information to developers who want to focus on developing.
 
 
[[Category:Rules and Guidelines]]
 
[[Category:Rules and Guidelines]]
 
[[Category:Root-Category]]
 
[[Category:Root-Category]]

Revision as of 17:40, 2 November 2015

Core developers

Core developers have special privileges and responsibilities compared to other contributors:

  • Can vote for and against merging pull requests (Two for-votes are required for code to be mergeable upstream.)
  • Has write access to the minetest team's repositories on github

Core developers are assigned and unassigned by celeron55, based on these rules:

  • Only people who have already contributed to the project can be assigned to be core developers.
  • The person themselves or anyone else can propose someone to become or stop being a core developer. Do this by "/msg celeron55 blah blah".
  • If a core developer is doing almost nothing but blocking everything that comes their way, they will be unassigned. (celeron55 will accept complaints and will ultimately decide.)
  • Core developers, like other contributors, should document and publish their work in a way that allows another contributor to pick up on it if the core developer stops working on the project due to any reason.

Past major changes

2015-11-02: The subsystem maintainer method was officially taken out of use. See the history of this page for details about how it worked.

Retrieved from "http://dev.minetest.net/index.php?title=Organisation&oldid=3355"