Merge pull request #14327 from Ivorforce/master

Re-write the problem rule to be about context rather than effort.
This commit is contained in:
Lukas Tenbrink
2026-02-26 10:12:46 +01:00
committed by GitHub
2 changed files with 14 additions and 10 deletions

View File

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

View File

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