From e19355de4263cf85d86847a8f17a47bbee55d1b2 Mon Sep 17 00:00:00 2001 From: Lukas Tenbrink Date: Wed, 25 Feb 2026 09:39:56 +0100 Subject: [PATCH] Re-write the problem rule to be about context rather than effort. --- .github/ISSUE_TEMPLATE/feature_proposal.yml | 13 ++++++++----- README.md | 11 ++++++----- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/feature_proposal.yml b/.github/ISSUE_TEMPLATE/feature_proposal.yml index 7be000e..17c8de1 100644 --- a/.github/ISSUE_TEMPLATE/feature_proposal.yml +++ b/.github/ISSUE_TEMPLATE/feature_proposal.yml @@ -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: |+ 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: |+ Add keyboard shortcuts to select groups of nodes quickly. diff --git a/README.md b/README.md index f5cd6ae..590d573 100644 --- a/README.md +++ b/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.