mirror of
https://github.com/godotengine/godot-proposals.git
synced 2026-09-03 18:14:03 +03:00
Merge pull request #14327 from Ivorforce/master
Re-write the problem rule to be about context rather than effort.
This commit is contained in:
13
.github/ISSUE_TEMPLATE/feature_proposal.yml
vendored
13
.github/ISSUE_TEMPLATE/feature_proposal.yml
vendored
@@ -17,10 +17,12 @@ body:
|
||||
label: Problem or limitation
|
||||
description: |+
|
||||
Describe the problem or limitation you are facing while working on your project.
|
||||
It is not enough to say a feature would be "nice" or "helpful".
|
||||
Describe how the lack of it is impacting your ability to make games.
|
||||
You should also describe which workarounds you tried and link related proposals. If you do
|
||||
not provide a well-founded motivation, your proposal will be closed.
|
||||
Give context to your problem.
|
||||
To give an example in cooking: Say you wanted to bake a cake and found a recipe.
|
||||
Don't write your problem as "I need flour", write "I want to bake a cake".
|
||||
To add flour is the proposed solution.
|
||||
You should also describe which workarounds you tried and link related proposals.
|
||||
If you do not provide a well-founded motivation, your proposal will be closed.
|
||||
placeholder: |+
|
||||
<Example>
|
||||
The 3D selection tools are cumbersome to use.
|
||||
@@ -33,10 +35,11 @@ body:
|
||||
label: Proposed improvement
|
||||
description: |+
|
||||
Describe how to overcome the limitation you described above.
|
||||
Be specific with your solution.
|
||||
It is not enough to describe just the idea; your proposal should make all the necessary design decisions
|
||||
such that they can be discussed by the community. Include images, mock-ups, diagrams, code, if applicable.
|
||||
Also consider describing the positive impact your proposal could have.
|
||||
If your solution lacks in detail, is ambiguous, or otherwise low-effort, your proposal will be closed.
|
||||
If your solution lacks in detail, is ambiguous, or otherwise unactionable, your proposal will be closed.
|
||||
placeholder: |+
|
||||
<Example>
|
||||
Add keyboard shortcuts to select groups of nodes quickly.
|
||||
|
||||
11
README.md
11
README.md
@@ -57,15 +57,16 @@ AI-written proposals are hard to read and often invent facts and solutions that
|
||||
If you aren't comfortable with English, write your proposal in your mother tongue and use
|
||||
dedicated translation software (not a chat bot) to translate it into English.
|
||||
|
||||
3. **Put effort into the problem statement.** It is not enough to say a feature would be
|
||||
"nice" or "helpful". Describe how the lack of it is impacting your ability to make games.
|
||||
You should also describe which workarounds you tried and link related proposals. If you do
|
||||
not provide a well-founded motivation, your proposal will be closed.
|
||||
3. **Give context to your problem.** To give an example in cooking: Say you wanted to bake
|
||||
a cake and found a recipe. Don't write your problem as "I need flour", write "I want to bake
|
||||
a cake". To add flour is the proposed solution. You should also describe which workarounds
|
||||
you tried and link related proposals. If you do not provide a well-founded motivation, your
|
||||
proposal will be closed.
|
||||
|
||||
4. **Be specific with your solution.** It is not enough to describe just the idea; your proposal
|
||||
should make all the necessary design decisions such that they can be discussed by the community.
|
||||
Include images, mock-ups, diagrams, code, if applicable. If your solution lacks in detail,
|
||||
is ambiguous, or otherwise low-effort, your proposal will be closed.
|
||||
is ambiguous, or otherwise unactionable, your proposal will be closed.
|
||||
|
||||
5. **Use one issue per proposal.** Do not cram multiple feature requests into a single proposal,
|
||||
as this makes it harder to discuss features individually.
|
||||
|
||||
Reference in New Issue
Block a user