Features and Enhancements should be treated separately or questions be rephrased

[Xrayez]

Relates to #10.

Noticed some issue with people not filling templates properly.

There should be two kinds of templates in GIP: one handling new features, and another enhancing existing ones, that way people could avoid filling out redundant questions. The template itself is named as Feature / Enhancement Proposal when you attempt to create one, so makes sense to split those just like in the main repository.

I propose modifying those templates like the following:

Feature template

Describe the project you are working on
Describe the vision/end goal you are trying to achieve

• not sure how to phrase it better but some people might not want to describe their own projects for whatever reason (they even might be under NDA, who knows).

Describe how this enhancement will help your project:
Describe how this feature will help to achieve your goal:

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:

If this feature will not be used often, can it be worked around with a few lines of script?:

• this feels a bit more like a hint/guide rather than an actual question to fill.
• this also pertains to enhancement rather than feature proposal.
• "working around" makes sense for existing features.
• the feature should be used relatively often within domain!

Is there a reason why this should be core and not an add-on in the asset library?:

Enhancement template

Describe the project you are working on
Describe enhancement of the existing feature (#39 (comment))

• most people refer to this as "irrelevant" when filling out blanks Preserve script state (breakpoints, bookmarks, folding) after closing a script in the editor #37, Download export templates on the background #35.
• some just learn stuff Add support for multiple displays/screens/monitors in Godot editor #28.

Describe how this feature / enhancement will help your project:
Describe how this enhancement will help to achieve your goal:

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

• somewhat irrelevant because the ground work is already done.

Describe implementation detail for your proposal (in code), if possible:

If this enhancement will not be used often, can it be worked around with a few lines of script?:

Is there a reason why this should be core and not an add-on in the asset library?:

• the feature is already there in the core Preserve script state (breakpoints, bookmarks, folding) after closing a script in the editor #37, Expose Easing equations #36

---

A few other questions could be added for each.

[iwek7]

I'd add field Describe Enhancment at the top of enhancment template. With current template I do not really know where to put proposed changes and since it is most importat information it should be probably at the top of the template.

[willnationsdev]

Straight up removing the "workaround", "mockup", and "why in core" questions does a lot more damage I think. The entire purpose is for the template to be a end-all solution for capturing possible redundancies in the codebase and filtering out stuff that doesn't belong, and each of these questions have valid responses where someone might think it goes in the engine, but really shouldn't.

• Feature "workaround with script":
  • Could be a new feature for a class which is easily enough worked around by just making a script that does some magic instead of making engine changes. If it isn't a feature that would be used often or by many people, then there may not be a reason to add it (depends on the change). It's just meant to get people thinking, "do I really need to suggest this change?"
  • Could be an editor change that adds new features to the editor, but which can be easily enough added via an EditorPlugin for the most part (Add a Spreadsheet resource for handling tabular data #13 is a good example where about 90% of the features can be done from a plugin and the other 10% is just a minor usability/maintenance headache that deserves its own Issue).
  • In cases like these, it can be up to the Issue creator to create a proof of concept in script code where the workaround is demonstrated, and if the scripted code/tools becomes really popular in the community, then it could be argued that there is demand for integrating it into the engine directly.
• Enhancement "mockup":
  • Just because it is an enhancement of something that already exists doesn't mean a mockup or visual demonstration of the changes isn't possible. Add "+/-" shortkeys to edit variables in inspector  #29, Exclude certain folders from search/quick scene #25, Change editor view panel UI #14, Make editor more compact and detailed #9, and Ability to change order of elements in export (Array) #23 are all examples of PRs that (whether they did or didn't) could fully have provided mockups to demonstrate what the changes would look like, even though none of them around about including entirely new features, but rather mixing up or updating existing features for the most part.
  • The additional detail that can be gathered from this Issue is hugely significant to improving the contributors' idea of what change is being requested and improves the discussion thereof.
• Enhancement "why in core":
  • Just like in the previous case, an enhancement of a thing doesn't necessarily mean it is in the core. If it were an enhancement of a module or an editor change, then many of those types of changes are fully capable of going into an EditorPlugin or a third-party asset that can override and add improved workflows to existing types in the engine.

Overall, I am not in favor of removing any of the discussed fields. The potential loss of benefit far outweighs any perceived improvement/simplification in the Issue creation workflow.

If you really wanted to create different templates that just reword the statements, I guess you could(?), but then you'd be maintaining two separate Issue templates that effectively ask the exact same questions. And that just doesn't really make sense to do from a repository management perspective.

[Xrayez]

My point is that we should make it flexible, some of those questions can be made optional, with words:

• "If applicable"
• "Recommended"
• "Optional"

But yeah if the task is to prevent people from creating "low-quality" proposals just to make sure they don't make a proposal in the first place then it makes perfect sense.

If you really wanted to create different templates that just reword the statements, I guess you could(?), but then you'd be maintaining two separate Issue templates that effectively ask the exact same questions. And that just doesn't really make sense to do from a repository management perspective.

I don't see how this could be an issue from management perspective, a python script could write out needed templates from a single source. But then again I'd just refine correct wording for each at the very least.

[willnationsdev]

I don't see how this could be an issue from management perspective, a python script could write out needed templates from a single source.

Why complicate something this simple even further? I'm just saying that I don't think the effort involved is worth it, not that it would necessarily be a huge pain to deal with.

[willnationsdev]

I do agree that having an "if applicable" condition could help to make certain proposals feel more at home though.

[Xrayez]

Why complicate something this simple even further?

Exactly, but we should first define if the effort should be alleviated from the maintainers side or user side.

[clayjohn]

Adding something like "if applicable" is counter to the purpose of the proposals. If every part of the template is marked as "if applicable" people will just not fill them out and then it falls on core developers to police them.

The purpose of the proposals is to force users to spend time and decently plan out their feature request. Each question is asking for particular, necessary information.

For example, if you don't have a project that needs the feature, then you shouldn't make a proposal in the first place. The goal of this system is to eliminate all feature proposals that are "nice to have" and narrow down the proposals to things that are "need to have".

And for other sections, if we make them optional, users will just not fill them out. Just look at the 1000 feature proposals on the main repo for examples.

[Zylann]

I see no labels assigned yet in this repo, should we add some for this as well?

[willnationsdev]

It does seem to me like the core contributors are more interested at this point in encouraging people to NOT make feature requests / enhancements when they don't actually need them for an active project. Hence the blatant "don't bother making this if these conditions don't apply" issue template. Which is another reason I think people shouldn't be removing any of the questions that are currently there.

When I'm thinking of "if applicable", I'm thinking of the way some of the questions are phrased to imply that you have an actual game project you are working on. I myself mostly develop tools and plugins, so until recently there haven't been any "projects" that my things could be related to, and many of the proposals I've made so far have been for the sake of building better tools and workflows for other people who create projects. In those cases, asking whether I have a project that needs the feature is not applicable, so-to-speak.

[Xrayez]

@clayjohn thanks for your answer, this clears up the process somewhat. I think this also depends on how substantial and big the feature proposal/enhancement really is.

And for other sections, if we make them optional, users will just not fill them out. Just look at the 1000 feature proposals on the main repo for examples.

Quoting reduz's words in #10 (comment):

Proposals are, most of the time, too many, too vague and impossible to discuss, we need to change our approach to quality over quantity.

One could write a really nice proposal with all the descriptions, diagrams, screenshots etc that would be worth of 10 incomplete and vague feature proposals. But this wouldn't make a difference as long as hardly anyone would be really interested in reading it all, understanding all the nuances, especially if the feature is undesired by most users because the actual use cases are quite niche (which wouldn't be welcomed in the first place then, so this needs to be stated clearly).

So there's a dilemma of whether it's actually worth making a proposal, or should a person come up with his own solution even if it might be potentially worth for a lot of users, either now or in the future.

As I recall correctly, there was some music game jam going on recently, and I think this created quite a lot of interest by itself, so you could possibly see users starting mentioning about various audio-related features being created and requested by developers using Godot, but that's unrelated to the topic.

The point again is really there should be some freedom in expressing ideas. Just put "Recommended" and ignore the proposal if you feel like it's incomplete if users start omitting important parts.

[Xrayez]

@willnationsdev

In those cases, asking whether I have a project that needs the feature is not applicable, so-to-speak.

Yes, from all the question that really get me is:

Describe the project you are working on

I can live with the rest of the questions just fine to be honest. I'd even close this issue if this gets rephrased/omitted, but I still think there should be two templates.

[clayjohn]

@Xrayez Personally, I am against "optional/recommended" solely because it implies that users can avoid those questions. As someone on the bugsquad, I feel very bad closing issues unless they are clearly in violation of rules. I know other contributors are in a similar place, that is the reason why we have literally thousands of issues on the main repo that will never be addressed, but are nevertheless left open. If a user submitted a proposal and didn't fill out a section marked as "recommended" I wouldn't feel right closing the proposal just because that section wasn't filled out. It wouldn't be fair to the person. I prefer to keep the requirement that all sections be filled out, then it is our discretion whether we leave the proposal open even though it violates the rule.

Yes, from all the question that really get me is:
Describe the project you are working on

I agree that we can improve all the questions, this one in particular. In my opinion it should be more like "Discuss what you are trying to do and why it isn't currently possible". That way it is sufficiently general to capture non-project/game use cases, but still highlights that you need to be proposing a solution to an unmet need.

[willnationsdev]

@clayjohn well, I think the suggestion you have is more like the "how would this benefit you if added" question whereas the first question is more about 1) securing the context of the "benefit" question and 2) enforcing that an actual task that someone is attempting to complete is inhibited by the lack of the proposed changes.

So, I think we should change the "what is your project?" question to "You should have a live or in-development project/task/tool that you cannot complete as desired without this proposal. If so, please describe it."

[clayjohn]

You should have a live or in-development project/task/tool that you cannot complete as desired without this proposal. If so, please describe it

Sounds great to me. :)

[Xrayez]

From the #42:

You should have a live or in-development project/task/tool that you cannot complete as desired without this proposal. If so, please describe it

Imo this can be simplified, read on.

(things that solve real obstacles / use-cases)

Perhaps "use-case" and "obstacle" is a better word for this. Describing the project/task/tool effectively forces the person to reveal his end goal created by problem/limitation/obstacle etc. Describing the real-life context can help but it's not necessary as long as the problem is clear enough.

So, this question has two parts actually: the context and the problem.

Describe the project you are working on (optional)

• This is context.

Describe the problem you are dealing with.

• "I don't have a tool" can be a problem in and of itself. In fact Godot might not be capable of creating such project to begin with, so the project itself might not exist yet, how can we talk about it? What if I'm a teacher who wants to simplify the learning process for my students? I don't have a project, I have a problem of students not picking up some aspects of Godot easily etc etc.

Describe how this enhancement will help to solve your problem:

• This is the next question.

Better yet, a user can come up with "Minimal reproduction project" to show this limitation so as to create proper context, but it has to be optional because users will just pass by, including myself (but yeah I understand the policy now).

[Xrayez]

Perhaps we should have godot-ideas for people to avoid formal proposals just because they'd like to start the fire in the minds of other people who can and might implement them into godot-proposals, for things which are "nice-to-have" as you say, because "nice-to-have" converts to "need-to-have" eventually.

[golddotasksquestions]

@willnationsdev

It does seem to me like the core contributors are more interested at this point in encouraging people to NOT make feature requests / enhancements when they don't actually need them for an active project.

This to me is highly problematic, as the reason why I (and I assume a lot of other people too) would not start a specific project is the lack of a certain feature or the need to improve an existing feature in Godot.

[Zylann]

@willnationsdev isn't a plugin an actual project? It's not a game, but it's a piece of software with a use within Godot. And sometimes people even want such plugins to exist (at least you, since you make plugins, I guess you have a reason to make them, even if not a game you are making :D)

[clayjohn]

This to me is highly problematic, as the reason why I (and I assume a lot of other people too) would not start a specific project is the lack of a certain feature or the need to improve an existing feature in Godot.

You have to understand the amount of work that core contributors (who are volunteers) have to put in right now in moderating random feature proposals. Users drop in out of nowhere and say "I want X and I want it now". It takes them ten seconds to ask for a feature they haven't fully thought out, and then the burden is on us to figure out if a) other users even need it, b) if it can be implemented without changing the engine and c) if it can be implemented at all. That is a LOT of work that has to come from volunteers. The new process is designed to ask more of people making feature proposals. It shifts some of the work to them. If you absolutely need a new feature, be prepared to spend ten minutes or more and give a complete explanation of that proposed feature. This way core contributors can spend less time moderating proposals and more time actually improving the engine.

I'd also like to point out that the main repo has 1000 feature proposals and 1500 proposed enhancements. That number is extreme, most of those will never be implemented and so they have no value for anyone. If a person makes a feature request and absolutely no one else expresses interest in that feature, then it should not be implemented. This new process gives us the tools and procedure to properly close unwanted feature requests.

"I don't have a tool" can be a problem in and of itself. In fact Godot might not be capable of creating such project to begin with, so the project itself might not exist yet, how can we talk about it?

I like willnationsdev's solution here, he says "project/task/tool", to me "task" captures all those non-project based needs.

[golddotasksquestions]

It takes them ten seconds to ask for a feature they haven't fully thought out, and then the burden is on us to figure out if a) other users even need it, b) if it can be implemented without changing the engine and c) if it can be implemented at all. That is a LOT of work that has to come from volunteers.

I highly doubt anyone who mentally sane who understand the meaning of "open source" with a 2 men team actually being paid (not enough) would expect people who spend their free time to contribute (completely unpaid) to respond to their every wishes.

Personally I never assumed it was anyone's job to figure out if a) other users even need it, b) if it can be implemented without changing the engine and c) if it can be implemented at all.

If I would go to Github and submit a proposal for a new feature or improvement of existing feature, I would assume I do this, for the sole purpose to document my need and to establish a place for discussion for this particular issue. Nothing more nothing less. If anyone has a similar need I can refer them to the issue and ask them for a thumbs up or voice their opinion. Other people have slightly different ideas about the solution, so we have a place to discuss. If someone already had the issue I can check and contribute with my support/opinion/ideas there. Since the year I've been here, I heard over and over again, the reason we did this on Github and not on Reddit or Discord was so it is documented and can be tracked. Issues on Github are also found via online search machines.

Maybe someone who may or may not have the same need one day comes along and has the time, skills and motivation to actually make a PR and implement a solution. In that case it's good to already have a place for a discussion or at least documented interest in a feature. Core contributors don't have to do anything if you ask me. If they are curious, want to poke around the idea pool or share their expertise on stuff that's in their insterest, that's cool. But honestly, I really wonder why you reduz or akien would think they would have to do this. If this is about implementation and architecture/bloat, I thought that's what the Pull Request is for, no?
Anyway. The discussions, collection of interest and ideas (of not just contributors but regular users) will have to happen someplace else. I think it was highly necessary to have bugs and feature requests/improvements separated. Not sure if closing anything not meeting the new incredibly strict requirements without supporting an alternative (like @Xrayez 'godot-ideas' rep) to tunnel the momentum is the right way though.

[golddotasksquestions]

I'd also like to point out that the main repo has 1000 feature proposals and 1500 proposed enhancements. That number is extreme, most of those will never be implemented and so they have no value for anyone. If a person makes a feature request and absolutely no one else expresses interest in that feature, then it should not be implemented. This new process gives us the tools and procedure to properly close unwanted feature requests.

I would like to strongly disagree on this. @clayjohn Not everyone has the same needs at the same time. If someone made a feature request in 2014, someone else found the issue 2016 and added "I need this too", and in 2018 three more people come to the same issue because they found it via online search or through some other cross-reference any realize there is actually an easy solution for it, or even if they just want to state they need this as well ...
This happens all the time. I have seen so many feature requests on Github spanning over years.

[clayjohn]

@golddotasksquestions You are mostly right. In general the previous process worked. However, i'd like your thoughts on one more point. What should we do about the current 2500 feature/enhancement requests? Obviously they are not going to get implemented, so how do we create a fair system to select which ones are left open and which ones are closed? Leaving 2500 open requests in our bug report tracking system is not an option. Currently its a nightmare for those of us who are actually contributing to the engine to sort through bug reports (I say this as a bugsquad member and frequent contributor). I spend hours every day dealing with new issues that are posted, and even at that I feel I am barely doing an adequate job because I just don't have time to cross reference every bug report with recent PRs and prior bug reports (this is necessary to determine if a new report is a duplicate or if it has been fixed in master). So right now our current process is failing, and it gets more and more difficult every day as the number of issues climbs.

Edit: At any rate our discussion is getting off topic. My apologies @Xrayez. Lets continue this on discord perhaps?

[Xrayez]

@clayjohn thanks but I think I've expressed my opinion fully and I completely understand your position.

[golddotasksquestions]

I spend hours every day dealing with new issues that are posted,

My heartfelt Thank You!

Leaving 2500 open requests in our bug report tracking system is not an option.

Yes.

so how do we create a fair system to select which ones are left open and which ones are closed?

By moving everything that is a) not a bug and b) does not the GIP requirement to godot-ideas rep.

I feel I am barely doing an adequate job because I just don't have time to cross reference every bug report with recent PRs and prior bug reports

If you feel like you want to do any actual work, you can stick around godot-proposals. If you are looking for brainfrats, maybe good ideas by users who have not fully understood the system yet, discussions on ideas not ready for GIPs, small life improvements that don't justify writing up a ull GIP, random expression of needs from the general userbase, you go to godot-ideas

Edit: At any rate our discussion is getting off topic. My apologies @Xrayez. Lets continue this on discord perhaps?

👍

[Xrayez]

Closing and continuing with a different approach in #47 which I feel like is the real motivation for this.