Difference between revisions of "Organisation"
Jump to navigation
Jump to search
(Meeting discussion 2024-02-18 (related cleanup)) |
|||
| (41 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | == Contributors == |
| − | + | A contributor is anyone who has made a pull request that has been merged, or successfully sent a patch to be applied otherwise. | |
| − | |||
| − | |||
| − | |||
| − | == | + | == Core developers == |
| + | Core developers have special privileges and responsibilities compared to other contributors: | ||
| + | * Can vote for and against merging pull requests (See also [[Git Guidelines]]) | ||
| + | * Has write access to the Minetest team's repositories on GitHub | ||
| − | + | The core team should all be people who are trusted and capable of reviewing C++ code if you ask them to. They don't necessarily need to have the time. However, if a core developer doesn't write or review any code for a long time, the trust disappears. | |
| − | + | ||
| − | + | ==== Assignment ==== | |
| − | + | 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", or by email. | |
| − | + | * Celeron55 accepts complaints about core developers and ultimately decides on unassignments. | |
| − | + | * 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. | |
| − | + | * If a person doesn't use their core developer privileges for 6 months, the privileges will be revoked for security reasons. | |
| − | + | ||
| − | + | == Past major changes == | |
| − | + | 2015-11-02: The subsystem maintainer method was officially taken out of use. It had already been unofficially out of use for a long time. See the history of this page for details about how it worked. | |
| − | + | ||
| − | + | [[Category:Rules and Guidelines]] | |
| − | + | [[Category:Root-Category]] | |
| − | + | [[Category:Organisation]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 15:31, 18 February 2024
Contributors
A contributor is anyone who has made a pull request that has been merged, or successfully sent a patch to be applied otherwise.
Core developers
Core developers have special privileges and responsibilities compared to other contributors:
- Can vote for and against merging pull requests (See also Git Guidelines)
- Has write access to the Minetest team's repositories on GitHub
The core team should all be people who are trusted and capable of reviewing C++ code if you ask them to. They don't necessarily need to have the time. However, if a core developer doesn't write or review any code for a long time, the trust disappears.
Assignment
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", or by email.
- Celeron55 accepts complaints about core developers and ultimately decides on unassignments.
- 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.
- If a person doesn't use their core developer privileges for 6 months, the privileges will be revoked for security reasons.
Past major changes
2015-11-02: The subsystem maintainer method was officially taken out of use. It had already been unofficially out of use for a long time. See the history of this page for details about how it worked.