Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 61 additions & 52 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,15 +22,16 @@ Feel free to open a pull-request based on any bug report as well!
## Suggesting improvements

You have two options to make a suggestion for the future of the engine. You
can either open a proposal [**Issue**](https://github.com/godotengine/godot-proposals/issues/new/choose),
or you can create an open [**Discussion**](https://github.com/godotengine/godot-proposals/discussions/new).
can either:
- open a proposal [**Issue**](https://github.com/godotengine/godot-proposals/issues/new/choose). Choose this option if you are prepared to implement the feature yourself.
- or open a new [**Discussion**](https://github.com/godotengine/godot-proposals/discussions/new/choose). Choose this if you have a more general idea.

Proposal *issues* are required to explain in technical detail how the suggested change
should be implemented. It is also preferred that the submitter of a proposal is
ready to implement it if it was approved. If you have a more general idea for
a feature but are not well versed in Godot's architecture or do not possess
the necessary knowledge to implement it in the engine, feel free to open a
[*discussion*](https://github.com/godotengine/godot-proposals/discussions/new)
[*discussion*](https://github.com/godotengine/godot-proposals/discussions/new/choose)
instead of an [*issue*](https://github.com/godotengine/godot-proposals/issues/new/choose).

A valid feature proposal will be held open to allow fellow Godot users and
Expand All @@ -40,71 +41,77 @@ implementation for a proposal to be considered ready to implement.

**Proposals should be made by opening an issue or a discussion, not a pull request.**
Don't fork this repository to open a proposal.

## Rules for submitting a proposal

> **Note:** The following points describe requirements for a proposal issue. A
> [discussion](https://github.com/godotengine/godot-proposals/discussions/new),
> on the other hand, can be started in any form.

1. Only proposals that properly fill out the template will be considered. If
the template is not filled out or is filled out improperly, it will be closed.

2. Please open one proposal per feature requested. Do not cram multiple feature
requests in a single proposal, as this makes it harder to discuss features
individually.

3. All proposals must be linked to a substantive use-case. In justifying your
proposal, it is not enough to say it would be "nice" or "helpful". Use the
template to show how Godot is not currently meeting your needs and then
explain how your proposal will meet a particular need.

* If you feel that you cannot provide highly detailed instructions with the
proposal, consider creating a more simple, open-ended issue in the
unofficial, community-maintained
[Godot Ideas](https://github.com/godot-extended-libraries/godot-ideas)
repository.

4. Other users must express interest in your proposal for it to be considered.
Godot is community-driven: if no other users are interested in your proposal,
it may be closed. It is up to you to draw interest in your proposed feature.
Start by reaching out on the community channels (Reddit, Discord,
[Godot Contributors Chat](https://chat.godotengine.org/)), etc.
see the [Community Channels](http://docs.godotengine.org/en/stable/community/channels.html) doc),
then create your proposal once you have gained some interest.

5. You can make a PR implementing the feature in the main repository before
making a proposal. However, if it is a large change, a core developer may
require that you make a proposal before your PR can be merged. It is always
better to make and discuss a proposal before spending your time implementing
a new feature.

6. If you or another user is capable of making a PR, include that fact in
the issue or in a subsequent comment so that a core contributor can
fast-track the approval process.

## What to do if your proposal is closed

<details>
<summary>Rules for submitting a proposal issue</summary>

> **Note:** The following points describe requirements for a proposal issue. A
> [discussion](https://github.com/godotengine/godot-proposals/discussions/new/choose),
> on the other hand, can be started in any form.

1. Only proposals that properly fill out the template will be considered. If
the template is filled out improperly, it will be closed.

2. Please open one proposal per feature requested. Do not cram multiple feature
requests in a single proposal, as this makes it harder to discuss features
individually.

3. All proposals must be linked to a substantive use-case. In justifying your
proposal, it is not enough to say it would be "nice" or "helpful". Use the
template to show how Godot is not currently meeting your needs and then
explain how your proposal will meet a particular need.

* If you feel that you cannot provide highly detailed instructions with the
proposal, consider creating a more simple, open-ended issue in the
unofficial, community-maintained
[Godot Ideas](https://github.com/godot-extended-libraries/godot-ideas)
repository.

4. Other users must express interest in your proposal for it to be considered.
Godot is community-driven: if no other users are interested in your proposal,
it may be closed. It is up to you to draw interest in your proposed feature.
Start by reaching out on the community channels (Reddit, Discord,
[Godot Contributors Chat](https://chat.godotengine.org/)), etc.
see the [Community Channels](http://docs.godotengine.org/en/stable/community/channels.html) doc),
then create your proposal once you have gained some interest.

5. You can make a PR implementing the feature in the main repository before
making a proposal. However, if it is a large change, a core developer may
require that you make a proposal before your PR can be merged. It is always
better to make and discuss a proposal before spending your time implementing
a new feature.

6. If you or another user is capable of making a PR, include that fact in
the issue or in a subsequent comment so that a core contributor can
fast-track the approval process.
</details>

<details>
<summary>What to do if your proposal was closed</summary>

### Improperly filled out template
If your proposal was closed because the template was not filled out, then
fill out the [template](.github/ISSUE_TEMPLATE/feature_proposal.yml)
and ask the person who closed the issue to re-open it.

If your proposal was closed as a duplicate and had a different approach to solving
### Duplicate Proposals
If your proposal was closed as a duplicate, and had a different approach to solving
the problem described in the linked proposal, please comment in the linked proposal
with your own idea. You don't need to copy-paste your whole proposal's text. Instead,
rephrase the main ideas and add mockups if needed.

### Lack Of Interest
If your proposal was closed because of lack of interest, then try to build up
some interest on the [community channels](http://docs.godotengine.org/en/stable/community/channels.html)
and then ask the person who closed the issue to re-open it.

### Not worth implementing
If your proposal was closed because a core contributor determined that it was
not worth pursuing and you feel that it was wrongly closed, then feel free
to join the [Godot Contributors Chat](https://chat.godotengine.org/)
and have a more in-depth discussion with other core developers about the feature.

## How core developers evaluate proposals

</details>
<details>
<summary>How core developers evaluate proposals</summary>
The following is a list of considerations that core developers use when deciding
to accept, close, or leave a proposal open. It is intended to be useful for core
developers when considering proposals and for proposal-makers in drafting their
Expand Down Expand Up @@ -162,7 +169,9 @@ If the feature is only intended to save users a few lines of code it is unlikely
to be accepted.

The above considerations are all balanced, no one is more important than another.

Core developers have discretion to weigh the factors as they see fit.

In addition to the above guideline, consider [this article](https://docs.godotengine.org/en/latest/community/contributing/best_practices_for_engine_contributors.html)
which outlines what core developers consider when evaluating PRs.
</details>