Make some questions optional in the proposal template

[me2beats]

Describe the project you are working on: GDScript plugins

Describe the problem or limitation you are having in your project: When creating proposals, I often find myself thinking that I cannot accurately answer the last 2 questions of the template.

• If this enhancement will not be used often, can it be worked around with a few lines of script? When creating a proposal, in most cases I think that this enhancement could be used often (at least for the tasks that I am going to solve with this feature) Also I believe that my problem cannot be solved using a workaround with a few lines, or find these solutions inconvenient. In reality this may not be so, and perhaps there is a work-round that would suit many users instead of implementing a new feature. However, knowledge of the intricacies and work-rounds requires a lot of experience with the engine. So I would often like to humbly skip this question.

• Is there a reason why this should be core and not an add-on in the asset library? When creating a proposal, in most cases I believe that the problem cannot be solved using an addon or this would be inconvenient. Similar to the previous question, I cannot be sure about this as I do not have enough experience in developing addons in Godot. Although I can say for example that the current gdscript plugin API is not enough to implement the features I need, but again this may be a wrong opinion.

I noticed that other participants also often demonstrate uncertainty when answering these 2 questions. In this case, the proposal creator's answers to some clarifying questions in the comment section could be more helpful to determine the need for the feature.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: Ability to optionally answer questions about addons and workrouns would be more convenient.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: One could answer questions about addons and workrouns optionally, as additional information if he considers it important. For example, a plugin developer could indicate how he tried to implement an addon that could solve the problem and why he eventually abandoned it.

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

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

[YuriSizov]

You are free to fill them in as you see fit, this proposal being a clear example of that. But the questions have their purpose. They are there to make you think on the matter, because you will be asked by other contributors and the core team about those points all the same, even if you skip them. So requiring you to think on it in the opening message gives you a head start on preparing your answer to these questions. There is no rush to create a proposal, and the most thought out proposals are the most welcome ones.

[dalexeev]

Think of these questions as complementary. Answer if they are relevant to your proposal. Much the same as with the "OS/device including version" and "Minimal reproduction project" fields in the main repository.

[Xrayez]

The way I see it, the issue is about not treating new features and enhancements of existing features as distinct types of proposals. I've actually talked about this a year ago in #39.

This way, it's totally possible to add more questions for each type of the template, so one can have an opportunity to answer more relevant questions.

Having questions which do not apply to a proposal actually hurts the general flow of ideas. It's like search bar suggestions which are getting in the way of what you actually wanted to search for in the first place. 😄

Most of the times, I just have to paraphrase the questions in my mind to simplify and/or adapt them first, and only then I can properly answer them... I have perfectionist personality and I just cannot allow myself to omit questions, but trying to answer them is taking too much useless effort, in my opinion. That's why I'm for making those questions optional, at least.

In fact, I've implemented this kind of workflow already in Goost: https://github.com/goostengine/goost/issues/new/choose.

---

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

This is certainly something which is only relevant for new features rather than enhancements, because in order to improve something, a feature has to exist in the first place.

Of course, if maintainers don't want to create two separate templates for this, making those questions optional is also a solution. But for that, I think we need to modify the first rule for submitting proposals:

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.

I don't understand what "properly" means here, it's too vague. Does that mean I can just write N/A? Then what questions can be actually omitted without hurting the general value of the proposal?

To demonstrate, I have a proposal which completely disregards the template as seen in #104, but nonetheless it will take you 10-15 minutes to read it, and likely more hours to actually understand the use cases. 😛

To para-quote groud in https://github.com/godotengine/godot-proposals/issues/575#issuecomment-695834161:

Anyway, I'm going to stop this conversation here as it has already taken too much of my time.

I really doubt such lengthy proposals will ever be considered, because very few of the core developers would be willing to spend the time to read it all. So, requiring people to "properly fill out" the template is counter to this reality. Rights and obligations, rights and obligations... #154.

If this is all about maintenance, then let other people to help you, this is community-driven project, after all.

Or just recommend people to use alternative repositories like suggested in #1476.

[me2beats]

Yeah, this

If the template is not filled out or is filled out improperly, it will be closed.

and this

Proposals not following the template below will be closed immediately

doesn't sound very welcoming 🙂

[YuriSizov]

That's because proposals here are not designed to collect random ideas from users but rather provide a standardized way to propose thought out suggestions for the engine development. It's more of a set of RFCs than an ideas hub.

[Calinou]

For the record, what @pycbouh says is not uncommon in large, established open source projects. Rust manages feature proposals in a similar way with their rfcs repository.

[Xrayez]

That's because proposals here are not designed to collect random ideas from users but rather provide a standardized way to propose thought out suggestions for the engine development. It's more of a set of RFCs than an ideas hub.

I believe most people here do not even know what "RFC" stands for. See also my response in https://github.com/godotengine/godot-proposals/pull/1476#issuecomment-706575297.

The purpose of this repository was quite misleading from the start. Back in the days of feature proposals on the main repository, I've seen how features ranged from very specific use cases to proposals which received quite a lot of 👍s, none of them were closed, and I thought that GIP would just be a place dedicated for this purpose, with no changes or strict requirements.

But no, additional rules were created to allegedly increase the quality of proposals. But the mere existence of rules != quality. Only after a year of discussion, I totally get the idea behind GIP now.

Initially, GIP didn't have those rules and guidelines. It was prematurely announced on community channels before the proposal process was kind of established. The very fact that I had to fix some questions like in #396 tells that no initial effort was taken to make sure that those questions are even valid in the first place, that's quite neglecting, if you ask me. The system doesn't need to be "tested" on people to know that existing process is faulty.

Or actually start enforcing those rules now, go ahead and close all those nice-to-have proposals, because they don't belong to GIP according to existing rules, this will prove that the system is legitimate and functional, not mutually exclusive, and the decision process is not reserved to the sole discretion of the core developers. Most people don't even properly answer the question of "Describe the project you're working on". It means that 95% of existing proposals must be closed. Nowadays, me and even core developers just tend to fill out this question as "Godot Engine", and that's it. What's the point of that? I'm for clarity.

And we don't even have approval process (go/no-go), at least I don't see it happening publicly, even after a year of existence of GIP.

That said, GIP is still WIP. 😛

[clayjohn]

@Xrayez Please try to stay on topic. I know you have a lot of thoughts about the proposal process in general, but we need to try to center discussion around this proposal.

[Xrayez]

@clayjohn I know you may not like what I'm saying and I'm sorry about that, but I don't see how my previous post was off-topic. I just stated that there may be fundamental problems which need to be resolved instead, of course that required proper introduction... The only off-topic post is yours here, because you haven't even commented on the subject or suggested some kind of a solution to resolve the problem. 😛

Or do you actually think the problem doesn't exist?

Given that no consensus has been reached in #39 (which is very close to this proposal), my suggestion is to modify the first rule for submitting a proposal instead, something like this:

Current

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.

Suggested

1. Proposals that fill out the template completely will be considered. You are free to fill them in as you see fit, but do note that high-quality proposals are more likely to be accepted. The template is there to help you think on the matter, and may not always apply to your particular proposal. If the proposal misses some vital information as suggested in the template, it may be closed. If the proposal contains inappropriate content, it will be closed.

I believe that the suggested change reflects the present state-of-the-art more accurately, and that's easier than trying to change all existing proposals to conform to existing rules.

Note that alternatives for when a proposal gets closed are already given at "What to do if your proposal is closed" section.

EDIT: see a PR for this: #1650.

[YuriSizov]

Since we have discussions now, and we want to clean up the issues to make sure the proposals in there are actually actionable, the template becomes even more of a requirement than before. So I think we can close this as obsolete, but thanks for the idea!