Difference between revisions of "Organisation"

From Minetest Developer Wiki
Jump to navigation Jump to search
m (Remove outdated stuff)
Line 14: Line 14:
 
Each issue and pull request should be assigned to a subsystem using the appropriate section label.
 
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".
 
For example, pull request [https://github.com/minetest/minetest/pull/7 #7] would get the label "Section - Build".
 
Note: the Github interface makes it harder than it should be to [https://github.com/isaacs/github/issues/1 assign labels to pull requests],
 
in particular there is no way to do so from the pull request page. Two known workarounds:
 
* Open the issue list (not the pull request list!), check the pull request, and use the "Label" dropdown to assign labels.
 
* Or install [https://userscripts.org/scripts/show/185095 iguananaut's greasemonkey script] which adds the label management widget that appears on issue pages to pull request pages.
 
  
 
== Subsystems ==
 
== Subsystems ==

Revision as of 10:25, 24 May 2014

System

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:

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).

Each subsystem is allocated to one "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 devs agree still stays valid for when it is useful (= when the appropriate maintainer is away).

Github

Each issue and pull request should be assigned to a subsystem using the appropriate section label. For example, pull request #7 would get the label "Section - Build".

Subsystems

Developer Subsystem
celeron55 maintainer conflicts
sapier server/client/env
kahrl startup/config/util
ShadowNinja script API
hmmmm mapgen
celeron55 client/audiovisuals
sapier low-level network
[OPEN] build system
proller masterserver
ShadowNinja Documentation

Those positions will maybe be assigned in the future:
releases
voting/community

Subsystem Files

(TODO)

maintainer conflicts

Meta-subsystem with the task of resolving conflicts between other subsystem maintainers that they can't solve themselves.

Proposed

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.