The proposal process doesn't seem very friendly, especially to the new person

[LikeLakers2]

I've noticed a problem with this repository, a problem which seems like it could push away a lot of people, and honestly one that's been on my mind for a while.

I've seen quite a few times where the response to a proposal seems like someone trying to figure out how to avoid implementing the feature... This isn't normally a problem, mind you (although I do think that the usual "you can do this with the current nodes and a script" isn't very helpful to people). What makes it a problem for me is that it often comes at the expense of not considering what we could reasonably do to help someone with what they want.

I should put a disclaimer: I don't frequent this repository anymore, but I do still read its issues from time-to-time (I have a habit of not cleaning out lists such as subscription lists). And I've seen one too many times where it feels like the responses given end up feeling like someone trying to say "no, and that's final, here's what you can do" rather than "no, but here's what we could do instead".

Don't get me wrong, I'm not trying to say that we can't say "no" in the way that we currently do -- but with how much we push the work onto the average proposal maker ("you can do this in GDScript"), rather than first considering what options we could implement to help them further their goal, it feels much like a place where ideas have to be accepted immediately or be rejected forever.

It ends up being, I think, a place where you have to already know how Godot is designed in order to be able to suggest ideas... and I'd have a hard time believing that the average person could figure that out that, given that I don't even have the confidence in whether I've done so myself, even after examining Godot's internals.

Again, I don't frequent this repository anymore, so please take this complaint as you will. Also, I apologize if it seems like a mess of thoughts, as I'm not always good at articulating my thoughts. I've just... ended up incredibly frustrated trying to think up ideas that I genuinely think would fit into Godot by default, only to feel as though they'd end up rejected because of how the proposal process works -- and so, I don't ever end up feeling like I can contribute good ideas because I'm not sure which ones are good and which ones aren't.

[Vlad-Zumer]

DISCLAIMER: This is just my personal opinion

I guess the main issue is the way the proposals are looked at and the nature of open source projects.

From looking around in this project, it seems that the feature request that are not successful do not concern themselves with the engine limitations. Another way of putting it is that there is a way, convoluted or not, to implement that feature on your own without having to modify the engine.

I think the reason this happens is that once a change is made to the core engine it has to be supported going forward, which would put even more strain on the active developers. From what I get Godot is still new and right now going through some big changes with Vulkan and AOT for 4.0 and thus maybe not the best time for quality of life improvements.

So to avoid taking ownership and being bogged down with maintaining small features they offer the tools to create them and ask the users to maintain them. This also has the side effect of allowing the features to become projects themselves.

[golddotasksquestions]

The way I see it: If you have a need, or feel impeded by a current process, and this is not about a bug, then it belongs here.
But I agree I would hope this is a place for open discussion and follows the "I personally don't share your need, but here's what you could try meanwhile, right now, until you get your feature" rather than the "no, and that's final, here's what you can do".
And luckily, I'm not so negative about it, because I see that constructiveness a lot here too. Though it's hard to keep up that positive mindset when confronted by the latter.

[KoBeWi]

Well, the process might seem unfriendly, because there are guidelines on how to create a proper proposal, which is there to filter out poorly written posts and people who want to throw random ideas they don't actually need. Even with this, we have 568 open proposals right now. It's not true that proposals are either immediately accepted or rejected forever. The overwhelming majority just ends up in limbo.

The reason is that if there's a proposal, even if it's extremely popular, someone has to implement it. If the proposal is really simple, it might get implemented in a couple of days even if it got less upvotes than some other popular proposal. With complex proposals, there's much much less chance that a random user will come and create a PR, so they will usually wait for a very long time.

you have to already know how Godot is designed in order to be able to suggest ideas

This is not entirely true, but well, you need at least know Godot before creating a proposal. If you are a newcomer, you should become familiar with the engine a bit rather than coming here on first roadblock and saying "Godot totally needs XYZ", where XYZ totally negates the engine's design/architecture or is already there. Honestly, the issue of godot-proposals not being an... idea dump repository... has been there pretty much since the beginning. The guidelines won't change. It might seem unfriendly, but on the other hand accepting everything isn't really productive (the limbo is endless you know xd).

Although I have one advice to people coming with their ideas. If you have idea that you think is good, and you make a proposal that meets guidelines, but still get a comment that makes you feel the proposal is "rejected", don't get discouraged. The proposal is truly rejected when it's closed (although this is not always final too). Fun fact: almost 80% of the closed proposals have Archived label. This means they were invalid - either duplicate, suggested already existing feature or didn't have a properly filled template. Many of them were closed by their creators. Not because they felt rejected and went away, but because they realized they actually don't need this in core. So if you meet with "rejection", reassess your proposal again and feel free to leave it open if you think it's a good idea. The "rejection" or "acceptance" means nothing actually, the final fate of the proposal is decided by the contributors. In worst case the PR implementing the proposal will not get merged, but most of the proposals sadly won't even reach this stage (the limbo).

That's how I see it. Unfortunately the fact that either something is in core or left up to users is a big issue here. The "official plugin repository" idea gets mentioned once in a while but so far it didn't happen. Still, the plugins would need maintainers, so it's not like we would get official plugin for anything 🤔

Anyways, there's a repo called Godot ideas, which has much less strict guidelines (if any) on accepting issues than the official repo. The fact that it's unofficial doesn't really change much, it's not like if you post something here it's more important or anything, just as I explained above.

[Xrayez]

I think I've expressed my opinion quite well in the previous comments here in the GIP if you look at the history so I don't see a point of regurgitating them (#47), but I agree.

It ends up being, I think, a place where you have to already know how Godot is designed in order to be able to suggest ideas...

I think this is where we have a great split and misunderstanding regarding the intention of this repository. The project manager once said that this is the place for people to write up technical proposals specifically (sorry can't seem to find the reference here). So, there's a difference between proposing and suggesting/requesting features. For instance, there was a "proposal" here which talked about splitting user suggestions from developers proposals specifically, despite it being written in an explicit and threatening language.

So again, this is where godot-ideas might be a good place for user suggestions which doesn't have to be technical in nature. But nobody wants to "maintain" anything. But I also have to say that, people come and go and we'll always find a maintainer, unless Godot's popularity goes so low that nobody dares to do anything at all, especially unpaid.

[LikeLakers2]

I feel I should clarify, now that I'm a little less sleepy (I'll admit I made this issue about an hour and a half after waking up).

My problem isn't so much that so many proposals get rejected (like KoBeWi mentioned, many of them are just in limbo), but that I feel there are way too few that end up rejected while simultaneously giving any semblance of ideas that might work in its place. I end up seeing too many answers that end up being "Yes/No" rather than "Yes/No but here's some similar ideas that might work better for us". It seems like there's an unwillingness to work with an idea unless the original proposal works without modification, and an unwillingness to help people learn what might make better proposals.

Additionally, when I mention that this place feels like one where you already have to understand Godot's design, it's because the proposal process and the responses seem like they make no attempt to help people better understand Godot's design. Sure, you're expected to have used the engine for a while, and maybe learned its design a little, but what of the people (like me) who have a hard time figuring out what that design is in the first place? I can hardly say what existing cogs of the engine would fit under my understanding of the engine's current philosophy, even having studied the source code of the engine, so I'm not sure how I could say whether my cool new node idea would fit well into the engine or not.

---

[Xrayez] I think this is where we have a great split and misunderstanding regarding the intention of this repository. The project manager once said that this is the place for people to write up technical proposals specifically (sorry can't seem to find the reference here). So, there's a difference between proposing and suggesting/requesting features.

If this is well and truly the case, then it should be considered that to the average person, "propose", "suggest", and "request" are effectively synonyms in this context. They all mean the same thing, or at least, the difference is so small that it's not even worth thinking about it. But if there is supposed to be some distinction in this context, then we should really be making that distinction obvious to anyone that uses this repository.

[KoBeWi]

I end up seeing too many answers that end up being "Yes/No" rather than "Yes/No but here's some similar ideas that might work better for us".

Well, I've seen many proposals and I don't recall many that ended up like this. Care to give any examples? Statements like that just seem vague to me.

I can hardly say what existing cogs of the engine would fit under the engine's current philosophy, even having studied the source code of the engine, so I'm not sure how I could say whether my cool new node idea would fit well into the engine or not.

Chances are that your ideas would be higher quality than from a random user that just started using the engine, even if you aren't confident about it.

[Xrayez]

Additionally, when I mention that this place feels like one where you already have to understand Godot's design, it's because the proposal process and the responses seem like they make no attempt to help people better understand Godot's design. [...]

Some corny/drama related proposal of mine as well: #575. 😄

[LikeLakers2]

I end up seeing too many answers that end up being "Yes/No" rather than "Yes/No but here's some similar ideas that might work better for us".

Well, I've seen many proposals and I don't recall many that ended up like this. Care to give any examples? Statements like that just seem vague to me.

Well I don't want to make anyone in specific out to be the bad guy, but... #770 (comment) was sort of the straw that broke the camel's back. If you look right above it, you can see my comment making a suggestion for what could be implemented instead, and then clayjohn made his comment towards the original proposal, saying what amounted to (in my mind) "do it yourself because we don't want to". (Disclaimer: Clayjohn's comment was made 14 minutes after mine, so I'm unsure if they even saw my comment)

Taking a brief look around, I found one other example: #663 (comment) ("You can do this kind of thing in your own code, without it being in the engine.", albeit aaronfranke later mentioned CollisionPolygon2D can make honeycomb shapes -- but I really think this would have been better off mentioned in the initial rejection comment).

That said, in the three pages of closed issues I looked through, I didn't actually see much of what I was referring to. I swear I've seen it a lot more, but perhaps as time has gone on, the issue has become less prevalent? Or perhaps it's more of what @golddotasksquestions mentioned above:

I see that constructiveness a lot here too. Though it's hard to keep up that positive mindset when confronted by the latter.

---

I can hardly say what existing cogs of the engine would fit under the engine's current philosophy, even having studied the source code of the engine, so I'm not sure how I could say whether my cool new node idea would fit well into the engine or not.

Chances are that your ideas would be higher quality than from a random user that just started using the engine, even if you aren't confident about it.

This doesn't really give me much hope, though. The problem I was trying to describe lies in not being able to comfortably understand the engine's design philosophy, which means that I'm never really sure if my ideas would be acceptable within the engine -- and even then, I would have a hard time figuring out if my proposals would survive anyways, because silly things like "You can code this in GDScript" could potentially get in the way.

Xrayez basically took the words out of my mouth over at the issue he linked, #575, in the opening comment:

When making feature or enhancement proposals to GIP, I often feel paralyzed by indecision which comes from lack of understanding of existing development ideology/philosophy/intention as seen by Godot members and seasoned core contributors, and a possible fear of rejection.

[Jummit]

I see it like this: This repo is for proposals, ideas and even just small suggestions. They can be discussed, although not like a court case where the maker of the proposal has to defend his proposal while others call out why it doesn't fit in core; because if it gets implemented or not is fully dependent on if someone makes a pull request for it.

Comments should only target the specific implementation and scope of the proposal, not question if it should even be implemented, because that is in most cases not constructive, and leads to arguments and drama. If it doesn't seem like a great proposal, let the "Votes" decide and close it if the ratio is too steep.

[aaronfranke]

Here's a proposal to resolve this proposal:

Make godot-ideas official, and link to it at the top of the template. Something like:

<!--
Please fill in *all* the questions below and don't remove any of them.
Proposals not following the template below will be closed immediately.

If you can't fill out the template or only have vague ideas of what your proposal
would look like, consider posting a discussion to the ideas repository instead:
https://github.com/godot-extended-libraries/godot-ideas
-->

**Describe the project you are working on:**

...or that but the repo is in the organization: https://github.com/godotengine/godot-ideas

[golddotasksquestions]

@aaronfranke What you are saying has been discussed at length in #47
Maybe it's time to reevaluate?

[mhilbrunner]

Personally, I'm not yet convinced this second repo is worth the additional work. The main repo is still barely useable with 5k+ open issues.

This proposals repo doesn't feel like it did move a significant amount of traffic off the main repo, but instead encouraged a new stream of issues (proposals) that formerly didn't exist, or not to such a degree, as we now explicitly invite proposals.

So I, personally, don't see the benefit yet. And I certainly don't see the benefit of yet another, third official repo.

[Calinou]

@mhilbrunner You're not wrong on the "new stream of proposals" part, but I still think this proposals repository was successful in making the proposal process clearer. Most proposals seem more well-thought out than they previously were, and many of them include mockups.

That said, a third official repository for issue tracking sounds excessive to me. Godot Ideas is specifically designed so that third parties can implement features tracked in that repository. I think we can keep it that way 🙂

[Jummit]

I would like a godot-ideas proposal just to get plugin ideas that people would actually use.

[LikeLakers2]

Currently, there are 9 community channels (not including GitHub, Q&A, and Twitter) that one could use to discuss their rejected idea, and none of them feel particularly good. Not to mention, it feels like a mess trying to get support for ideas (godot-related or not), much less find people willing to say "Hey, that's a cool idea, but I think it needs some changes".

Godot-ideas is supposed to solve that issue by being a centralized place for ideas for Godot. It's meant to make it easier for people to find and discuss random ideas they may have, thought-out or not. Even if people that do come to the repository don't always say "I think this needs some changes", at least it increases the likelihood. It's meant to be a place where people can foster their creativity, rather than feel confined here, hoping that they'll have just the right ingredients in their proposal to not be rejected.

Godot-ideas does not need to be in the godotengine organization -- it never needed to be. The repository doesn't need to be monitored by the Godot team -- Xrayez already handles that. What it needs is to be linked to in some form, whether it be in the issue template, or even in the messages that the Godot team gives when closing proposals.

If having to link it somewhere in this repository will somehow make it "official", so be it -- but please, if you're going to complain that it'll be a "third official repository", please elaborate on why you find that to be a problem. Currently, the "third official repository" argument seems like the team saying that they don't want to have to monitor or support it -- yet no such expectations ever existed beyond having to link to a repository.

---

That all said, I'm not quite sure Godot-ideas will be a complete solution to the problem -- but if it isn't, it's at least a start. Or at least, it feels like one.

[golddotasksquestions]

As long as it's not official, it won't be used. Evident by the existing "Godot ideas repo" no one is using.

[girng]

Currently, there are 9 community channels (not including GitHub, Q&A, and Twitter) that one could use to discuss their rejected idea, and none of them feel particularly good. Not to mention, it feels like a mess trying to get support for ideas (godot-related or not), much less find people willing to say "Hey, that's a cool idea, but I think it needs some changes".

One reason why I miss the centralized forum in 2015~. In my opinion, it was the Golden ages of the Godot community. Share scripts and art, talk about your project, post events, get support, akien, reduz and the "lead devs and core contributors" were active, etc. It was the go-to place for anything related to Godot and even sometimes just game development.

[Xrayez]

If having to link it somewhere in this repository will somehow make it "official", so be it -- but please, if you're going to complain that it'll be a "third official repository", please elaborate on why you find that to be a problem.

One of the "problems" I see is that users may actually start using godot-ideas repo just because of less restrictions, and then wonder why people don't use godot-proposals repo. 😛

As long as it's not official, it won't be used. Evident by the existing "Godot ideas repo" no one is using.

Yeah, but that's not necessarily true, at least at the moment. The thing is that, the development of the engine is backed by the efforts of professionals that people have trust in. And it's a matter of time before more people start becoming more proficient in both the development and the open-source community management which would would allow such a community to be on par with the seasoned engine developers, but on the level of plugin development of course.

I mean, it's not about it being official, it's about having an ability to be seen as someone who can create and maintain those features as an responsible organization. But I guess the "responsibility" doesn't really apply to open-source development since it's volunteer work. Yet again I feel like if we can draw clear vision and let new people do what they want, it's easy to create a self-growing community, especially when it doesn't have the limitations on the many features which can be implemented, imaginable or unimaginable, needed or wanted.

That's on the contrary with the engine development which aims to be as minimal as possible, catering to most core needs. Think about the engine as a Linux kernel, and the infrastructure of plugins, modules, packages as Godot distros. I personally think that's an inevitable course of circumstances, because: no, the handful of Godot Engine maintainers simply cannot cater to those needs, physically #779 (comment):

Personally, I'm not yet convinced this second repo is worth the additional work. The main repo is still barely useable with 5k+ open issues.

It's only not worth of additional effort because nobody from the core developers are interested in bloating the engine. On the contrary, there's an infinite number of ideas which can be implemented independently without much limitations.

On a side note, I'd also like to express my opinion regarding the somewhat strict PR review process. I think that somehow, maintainers are afraid that those new contributors are going to break something. While I don't deny the value of this process, in some cases this leads to an never-ending review-and-rebase cycle (have to go through "9 Circles of Hell" before a simple change in documentation can be merged, for instance 😄). In fact I know one highly experienced developer (on par with reduz, he's also within the top 100 contributors) who dumped Godot because of the slow review process and then abandoned a PR (which was luckily salvaged). I know because he told me about this in private.

This all contributes to an impression that the contributors are not as important, while it doesn't have to be like that. Just a little bit of trust and less fear is needed to further improve the relationships. If someone makes a mistake, someone else can fix it later.

[LikeLakers2]

If having to link it somewhere in this repository will somehow make it "official", so be it -- but please, if you're going to complain that it'll be a "third official repository", please elaborate on why you find that to be a problem.

One of the "problems" I see is that users may actually start using godot-ideas repo just because of less restrictions, and then wonder why people don't use godot-proposals repo. 😛

I see it a little more like this: People will start off with an idea. This idea will either get fleshed out on its own then posted here (where it could be tossed to godot-ideas), or will go to godot-ideas for help with fleshing it out. If an idea would fit within the engine proper (the definition of this seems to vary depending on who you ask), then once it's fleshed out at godot-ideas, it can be tossed over here with a summary of what was agreed upon over at godot-ideas. If an idea does not suit being in the engine, it will stay over at godot-ideas, until someone creates an addon for it.

I want to make clear that I do still see what you're pointing out, though -- and even with how I see it being used, I am also a little concerned that it may become that way. But barring other options being brought up, I would rather take the risk and allow a less restrictive environment to become known, because that would (potentially) allow more ideas to be fleshed out in the first place -- even if they aren't all going to be implemented in the engine itself.