Difference between revisions of "User:Rarkenin/Proposal System"
(Remove /) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
The subpage should begin with a heading describing in a few paragraphs the proposal's features, and reasons for why it is needed. Stability and completeness of the code should also be discussed with a link to an appropriate Github repository. | The subpage should begin with a heading describing in a few paragraphs the proposal's features, and reasons for why it is needed. Stability and completeness of the code should also be discussed with a link to an appropriate Github repository. | ||
| − | Below this, a discussion may be kept with important points about the proposal. While IRC is meant for realtime chatting, it is a poor choice for tracking a consensus. A concrete opinion of reject, weak reject, neutral, weak support, or support may be given with a comment explaining the reasoning. Majorities do not rule here, but reasoning and rationality. After a given amount of time for the discussion(one month or sufficient comments given), a user with commit access to the repository should give a decision ''in accordance to the opinions provided and their arguments,'' and not based heavily on personal opinion. This means that a developer can reject a proposal for technical reasons, such as large programming issues that are unfixable(if they are fixable, they should be fixed and the proposal continued), or due to community consensus in favor of rejecting, not because a developer doesn't like it. After this is done, the proposal will be either rejected or merged into the code, and the proposal page will receive an archive notice. Upon acceptance, the code will be merged from the appropriate branch, with core devs and the proposal author helping ensure a smooth integration with recent changes. The rule of consensus within the core devs is fulfilled by community consensus and ONE core dev performing the merge. | + | Below this, a discussion may be kept with important points about the proposal. While IRC is meant for realtime chatting, it is a poor choice for tracking a consensus. A concrete opinion of reject, weak reject, neutral, weak support, or support may be given with a comment explaining the reasoning. Majorities do not rule here, but reasoning and rationality. After a given amount of time for the discussion (one month or sufficient comments given), a user with commit access to the repository should give a decision ''in accordance to the opinions provided and their arguments,'' and not based heavily on personal opinion. This means that a developer can reject a proposal for technical reasons, such as large programming issues that are unfixable (if they are fixable, they should be fixed and the proposal continued), or due to community consensus in favor of rejecting, not because a developer doesn't like it. After this is done, the proposal will be either rejected or merged into the code, and the proposal page will receive an archive notice. Upon acceptance, the code will be merged from the appropriate branch, with core devs and the proposal author helping ensure a smooth integration with recent changes. The rule of consensus within the core devs is fulfilled by community consensus and ONE core dev performing the merge. |
==Rejection reasons against consensus== | ==Rejection reasons against consensus== | ||
The following are possible reasons why a proposal may be rejected against consensus. | The following are possible reasons why a proposal may be rejected against consensus. | ||
| − | * Technically cannot be merged(due to new incompatible features) | + | * Technically cannot be merged (due to new incompatible features) |
| − | * Severe stability issues(such as extremely poor performance, memory leaks, segfaults occurring often, etc.) | + | * Severe stability issues (such as extremely poor performance, memory leaks, segfaults occurring often, etc.) |
* Proposals which can be done in Lua without appreciable performance loss | * Proposals which can be done in Lua without appreciable performance loss | ||
| Line 17: | Line 17: | ||
* A core dev does not like feature foo. | * A core dev does not like feature foo. | ||
* The code follows technical conventions, but not my quirks. | * The code follows technical conventions, but not my quirks. | ||
| − | * I cannot merge this(in this case, defer to another dev). | + | * I cannot merge this (in this case, defer to another dev). |
==Proposal reruns== | ==Proposal reruns== | ||
If a proposal is rejected, it may be resubmitted with a reasonable wait time until it is deemed that changes in opinion or other portions of the Minetest engine may affect the worthiness of the proposal. A new proposal subpage will be created, with a notice linking to the original proposal discussion. The proposal will then be agreed upon or rejected as per above. | If a proposal is rejected, it may be resubmitted with a reasonable wait time until it is deemed that changes in opinion or other portions of the Minetest engine may affect the worthiness of the proposal. A new proposal subpage will be created, with a notice linking to the original proposal discussion. The proposal will then be agreed upon or rejected as per above. | ||
Latest revision as of 17:40, 30 April 2013
Please note that this is a userspace proposal for policy, and as such, has no binding effect.
Proposals are listed at Proposals and will get a subpage for each proposal below this point. It is imperative to plan and prepare a proposal before submitting it, as it will see heavy discussion, questioning, and/or a possibility of merging.
The subpage should begin with a heading describing in a few paragraphs the proposal's features, and reasons for why it is needed. Stability and completeness of the code should also be discussed with a link to an appropriate Github repository.
Below this, a discussion may be kept with important points about the proposal. While IRC is meant for realtime chatting, it is a poor choice for tracking a consensus. A concrete opinion of reject, weak reject, neutral, weak support, or support may be given with a comment explaining the reasoning. Majorities do not rule here, but reasoning and rationality. After a given amount of time for the discussion (one month or sufficient comments given), a user with commit access to the repository should give a decision in accordance to the opinions provided and their arguments, and not based heavily on personal opinion. This means that a developer can reject a proposal for technical reasons, such as large programming issues that are unfixable (if they are fixable, they should be fixed and the proposal continued), or due to community consensus in favor of rejecting, not because a developer doesn't like it. After this is done, the proposal will be either rejected or merged into the code, and the proposal page will receive an archive notice. Upon acceptance, the code will be merged from the appropriate branch, with core devs and the proposal author helping ensure a smooth integration with recent changes. The rule of consensus within the core devs is fulfilled by community consensus and ONE core dev performing the merge.
Rejection reasons against consensus
The following are possible reasons why a proposal may be rejected against consensus.
- Technically cannot be merged (due to new incompatible features)
- Severe stability issues (such as extremely poor performance, memory leaks, segfaults occurring often, etc.)
- Proposals which can be done in Lua without appreciable performance loss
The following should never be used as reasons:
- A core dev does not like feature foo.
- The code follows technical conventions, but not my quirks.
- I cannot merge this (in this case, defer to another dev).
Proposal reruns
If a proposal is rejected, it may be resubmitted with a reasonable wait time until it is deemed that changes in opinion or other portions of the Minetest engine may affect the worthiness of the proposal. A new proposal subpage will be created, with a notice linking to the original proposal discussion. The proposal will then be agreed upon or rejected as per above.