Defining the proposal / GIP process, take 2

[reduz]

Introduction

After the lengthy discussion in #1, and further many discussions among core contributors on IRC, I'm putting together a simpler, yet more refined proposal process, which draws from previous discussions and aims to be simple and take on what we know for certain are problematic areas:

• The main issue tracker is flooded with feature / enhancement requests that are just too many to be discussed or reviewed.
• Proposals are, most of the time, too many, too vague and impossible to discuss, we need to change our approach to quality over quantity.
• External contributors often create feature/enhancement PRs that we don't know if are wanted, whether they solve actual problems, or if the way they are implemented (usability wise) is right. These are very difficult to review because we, as developers, don't even know this most of the time, so we would prefer they go via community filter. It's easier to review, discuss, approve or reject a proposal than a PR.
• The whole process must not become more bureaucratic for core contributors than it already is. In fact, the goal is to make it less bureaucratic, given that most core contributors are doing this work on their free time.
• We constantly get asked by potential new contributors what kind of work they can do and it's not always easy to answer. By better filtering proposals, the new system can also be used to better organize new and existing contributors.

With all this in mind, here's the new proposal for the process.

Overview

The idea of this document is to layout a workflow to take off load from core contributors (and Akien) from reviewing enhancement PRs. In most of these situations, enhancement proposals are questionable or debatable and require a large amount of time by core contributors to discuss, when they themselves may not even be sure of what the intended use cases are for them, or whether there is enough interest by the community

The intent is to find a workflow where proposals can be better discussed and prefiltered by the community, and those proposing need to do more work to justify and explain their ideas to make their intent clear not only to contributors but to the community.

This also aims to reduce the amount of proposals and ideas in our issue trackers and filter them. It also makes it easier for new and existing contributors to pick approved proposals to work on, with clear explanations on their use cases.

Following are the step by step process for proposals:

Process

1. Open an enhancement proposal issue:

We will use this repository instead of the main issue tracker. When opening a proposal as a new issue, the user will be first asked to fill a template that will go on top of the proposal, with the following questions on the issue, similar to when reporting an bug:

1. Do you need this for a project you are working on? If so, please describe your project and how this will help you.
2. Is this something that you will need to be using often, or that it can’t easily be worked around? (would be useful to more easily discard proposals that don’t need thiscriteria, not sure how to phrase the question better)
3. Are you able to submit a pull request if this proposal is approved?
4. Please describe the proposal:
5. Please describe the use case with a mock-up, video or diagram of examples on how it will be used: (use case and workflow needs to be crystal clear)
6. If you are a technical person, you may add some technical content on implementation, but use cases and usage will always take priority.

These fields need to be clear for your proposal to be approved. If a proposal is too simple or does not conform to these rules, it will be closed.

2: Get approval for your proposal.

You can seek approval for your proposal in two ways:

1. Ensure users are interested about discussing it. If you don’t see enough interest, you can try to gather some on social media. If you manage to gather enough discussion and interest, this may be reviewed and approved.
2. If someone is willing to do a PR, ask a core contributor, who may be interested in fast-tracking your proposal for approval.

If there is not enough community interest and no contributor interest, then the proposal will eventually be closed.

3: Creating a pull request

Whether you wrote the proposal yourself or someone else is interested in actually creating a pull request for an existing proposal, always make sure that the proposal is approved by a core contributor. Make sure all technical details on how it will be implemented are clear before doing this, feel free to ask core contributors for help if you need to.

4. Get your pull request tested

Before having your proposal reviewed, it’s important that other users test your pull request. Make sure to communicate to those who discussed the original proposal issue about it, so they lend a hand. We may also create some sort CI to get those pre-built for users for testing. (is this possible? I remember reading GitHub is adding something like this)

5. Proposal review

Contributors will often meet online to discuss PRs and will try to pick yours. If this does not happen, personally ask core contributors to review your proposal for merging.

Fast Tracking

Core contributors or owners of areas can fast-track this process and also approve external contributors to do it for them, the requirements and use case are clear or they discussed themselves a well understood problem beforehand.

Likewise, PRs opened, but that may need discussion can be closed and asked to open or go back to an issue in the proposal repository to agree on missing details.

Conclusion

This aims to be a system that puts the burden on those proposing instead of those reviewing, so we can better utilize the time and resources kindly donated by the community to the project.

[NHodgesVFX]

This seems like a good process. As far as seeing community interest for a proposed feature it seems like the way blender.community on right click select does it would work better then github. This way contributers and core devs can get a idea of what people want just by sorting by upvotes. not sure if godot has the resources to setup a site like this though. Maybe a open source solution is avaible? https://blender.community/c/rightclickselect/

[reduz]

@nate066 No need to, this github repo will be used for this.

[Ertain]

Great start to restructuring for new features or fixes. I hope that when the proposals are written and posted, most are easy to digest, are to the point, and the readers can support the proposals they agree on.

[nathanjwtx]

What will happen to existing proposals/feature requests? Will they need to be re-submitted?

[willnationsdev]

@reduz

Questions:

1. Do users who already have pull requests submitted need to create proposals here and gather support/description/etc. before they can expect their existing PR to be accepted? I'm guessing yes.

2. Should we outline/document/guide users (new and old alike) how they should identify which core contributors to talk to about which type of feature request / enhancement? As I understand it, most core contributors are specialized or more familiar with specific areas of the codebase. How do we guide people from "This is what I want to add to the engine" to "this is who I need to talk to in order to get it approved?"

3. How should we handle the fact that you ultimately have veto power on Issues, in such a way that we can effectively streamline what stuff you have to look at and figure out as early on as possible whether someone's concept would be approved? I speak on this as I know I've had several proposals that had a positive reception, and so I did the work of implementing them, but then I'd ultimately have to shut down the effort when you informed me that you didn't like the entire proposal.

   • My initial idea would be to have 3 labels in this repository's issues to indicate if they are approved, reduz-approved, and/or tested. You could then filter to only approved ones when examining a list of items and only ones that have all 3 would actually get merged, unless they were fast-tracked.

   I'm late to the conversation, so maybe you guys have already discussed and debunked that idea, idk. My success with using IRC has been hit and miss, so I usually just hang out on Discord, but that's not where all the meetings take place, so I'm pretty much always gonna be out-of-the-loop.

4. What system would you recommend if someone has a proposal that involves multiple interrelated, but independent features? Create two separate proposals and then have one state that it would rely on the other?

@nate066

Afaik, you can actually add a filter to GitHub issues to filter based on the number of upvotes they get. Here's an example for this repository.

[reduz]

@nathanjwtx

What will happen to existing proposals/feature requests? Will they need to be re-submitted?

Yes, following proper guidelines, most will be closed and asked to re-open properly here. If some of them have an important discussion they will be directly moved to this repo.

[fire]

The term in English is "fast-tracking" instead of "sidetracking." This term is the case of allowing core contributors to expedite the process GIP if "requirements and use case are clear or they discussed themselves a well-understood problem beforehand."

I recommend changing the term "sidetracking" to "fast-tracking"

Regarding the three label proposal. 1. approved, 2. reduz-approved, 3. tested.There is a bottleneck on Reduz approving contributions; therefore, I wouldn't create a tag for that. Perhaps the label can be named something else or removed.

I would only have: 1. approved, 2. fast-tracked, 3. tested

4. archived would match the existing issues workflow.

[reduz]

@willnationsdev

Questions:

1. Do users who already have pull requests submitted need to create proposals here and gather support/description/etc. before they can expect their existing PR to be accepted? I'm guessing yes.

For enhancement PRs, yes most likely.

2. Should we outline/document/guide users (new and old alike) how they should identify which core contributors to talk to about which type of feature request / enhancement? As I understand it, most core contributors are specialized or more familiar with specific areas of the codebase. How do we guide people from "This is what I want to add to the engine" to "this is who I need to talk to in order to get it approved?"

Users normally would not need to interact with core contributors (it would make our life impossible). Instead core contributors responsible of approving will check proposals. I think it makes more sense that those willing to create PRs interact with us, and for this they can always come to irc.

3. How should we handle the fact that you ultimately have veto power on Issues, in such a way that we can effectively streamline what stuff you have to look at and figure out as early on as possible whether someone's concept would be approved? I speak on this as I know I've had several proposals that had a positive reception, and so I did the work of implementing them, but then I'd ultimately have to shut down the effort when you informed me that you didn't like the entire proposal.

Well, if you read again, this is what this system is trying to encourage. Many of your proposals and contributions are great, but a lot of it is just things you wanted to do that nobody asked for, nor it was clear what they would be used for. By discussing proposals first and seeing if there is any interest, we can save the work on rejecting a PR due to core contributors not finding it useful or in demand. This is why so much focus is put on the first question: "describe your project and how this will help you."

• My initial idea would be to have 3 labels in this repository's issues to indicate if they are approved, reduz-approved, and/or tested. You could then filter to only approved ones when examining a list of items and only ones that have all 3 would actually get merged, unless they were fast-tracked.

Again, I don't think I've ever used veto power (I don't really think I have it either), My responsibility as development leader is to always promote discussion and agreement by community and contributors. If I'm against something, I'll put an argument about why, I won't just go and close a PR.

I'm late to the conversation, so maybe you guys have already discussed and debunked that idea, idk. My success with using IRC has been hit and miss, so I usually just hang out on Discord, but that's not where all the meetings take place, so I'm pretty much always gonna be out-of-the-loop.

Apologies about it, but most of us doing core work use IRC, where we often hold review meetings for all PRs. Many times it may seem like any of us just goes and closes a PR, but most of the time it was discussed with the other peers in a meeting before closing.

4. What system would you recommend if someone has a proposal that involves multiple interrelated, but independent features? Create two separate proposals and then have one state that it would rely on the other?

I have no idea, let's try and see how it works, but again keep in mind the points that were listed as requirements, the first one is key.

[willnationsdev]

@reduz Got it. Thanks for the detailed feedback!

Users normally would not need to interact with core contributors (it would make our life impossible).

Well, I'm talking about how you specifically mention talking to core contributors directly if you want to add a feature that has not yet garnered a lot of public support:

Ask a core contributor, who may be interested in fast-tracking your proposal for approval.

There isn't a clear way of identifying who would be best to talk to about what type of feature, etc.

Well, if you read again, this is what this system is trying to encourage. Many of your proposals and contributions are great, but a lot of it is just things you wanted to do that nobody asked for, nor it was clear what they would be used for. By discussing proposals first and seeing if there is any interest, we can save the work on rejecting a PR due to core contributors not finding it useful or in demand.

Yeah, I understand. ^_^ Looking forward to the new system. Appreciate you typing this all up.

[reduz]

@willnationsdev

Users normally would not need to interact with core contributors (it would make our life impossible).

Well, I'm talking about how you specifically mention talking to core contributors directly if you want to add a feature that has not yet garnered a lot of public support:

Ah, I mean mostly if you are willing to do a PR. Anyone is welcome to come to irc and ask something, but community feedback will always be more important.

Ask a core contributor, who may be interested in fast-tracking your proposal for approval.

There isn't a clear way of identifying who would be best to talk to about what type of feature, etc.

If you ask in #godotengine-devel who is responsible for some area, you will most certainly get an answer. If you just ask whether anyone would be interested in something, that's something that will not get much enthusiasm because most of us just don't really know or care. It's better for the community to define what they would find something useful for.

[willnationsdev]

FYI, I'd add a GitHub Issue Template sooner rather than later as I'm sure this repo is about to get flooded with new Issues, lol.

[reduz]

@willnationsdev This will happen when we change the issue template in the main repo to specify that only bug reports are allowed, and that proposals will have to come to this repo.

[willnationsdev]

^ Just realized that this means the number of Issues in the godotengine/godot repository will actually reflect the number of bugs that exist in the engine. That should help stop people from being warded away from the project by a nothing but a wayward glance at the Issue count. XD

[KoBeWi]

Does that apply to ALL enhancement issues? Including usability ones? What if someone suggests a cosmetic change, which isn't a bug report, but could make life a little easier? Like allowing to filter options somewhere, adding an alternate way to do something (e.g. rename scripts from Script Editor) or rearranging some icons/menus?

This would be a good example of such thing: https://github.com/godotengine/godot/issues/24542. It's not a bug report, wasn't really requested, but didn't have much impact either and PR that closed this was literally one line. Will such random and trivial issues have go to this repository and through the whole process too? Or does it apply only to "big" proposals? And where's the line then?

[reduz]

@KoBeWi drawing the line is difficult, so at the beginning yes. We may eventually understand the system better and over the long refine the criteria.

[kone9]

A monthly voting system

[reduz]

@kone9 There is not going to be any voting. This is an open source project where everyone does whathever they want, whenever they want, so it's entirely up to contributors to decide which proposals to do.

[vnen]

@KoBeWi for simple enhancements you can do a proposal and ask a core contributor/code owner to fast-track the process with the argument that it improves usability and it's a small change. If it's really that good and simple I'm sure the owner will see the value and allow the fast-track route.

[aurodev]

^ Just realized that this means the number of Issues in the godotengine/godot repository will actually reflect the number of bugs that exist in the engine. That should help stop people from being warded away from the project by a nothing but a wayward glance at the Issue count. XD

Definitely needed!

[follower]

1. Perhaps a pointer to .github/CODEOWNERS might be helpful for people wanting to know which core contributor(s) are primarily involved with specific areas.

2. Re: delineation between "enhancement of existing feature"/"feature addition"--it is presumably always going to be a grey line but perhaps we could, for example, look to the criteria used by Python in the PEP process as guidance?

3. Based in part on my observations from the conversation around the PR to add bbcode font size support to RichTextLabel I get the impression there could be some value to encourage people to try to implement at least an initial proof-of-concept in GDScript rather than jump straight to engine C++ or provide nothing.

   A proof-of-concept requires less work than PR-ready code upfront & gives a concrete implementation to discuss & identify potential issues. It also means that if people need a feature now that they can at least get something.

   And when CoolNewFeature.gd is seen included in 500 real-world projects but there's, say, concerns around performance or need for an in-engine integration hook point, then there is real world usage to guide prioritization/in-engine implementation. (e.g. Maybe rather than adding a "font size tag" feature it's better to add a "GDscript accessible unknown-tag-encountered hook" feature).

   Obviously GDScript can't do everything but particularly since the addition of class_name I think GDScript's capable of a lot more than people realise.

   It would also allow the answer to a proposal to be a more positive "can you or someone else provide a GDScript proof-of-concept" rather than "No" or "Not at the moment".

   Encouraging this would also invite tangible code contributions from a wider group of potential developers.

[golddotasksquestions]

KoBeWi for simple enhancements you can do a proposal and ask a core contributor/code owner to fast-track the process with the argument that it improves usability and it's a small change. If it's really that good and simple I'm sure the owner will see the value and allow the fast-track route.

I am concerned this process will further diminish involvement of users who are not contributors themselves or much involved in the community but just USE the engine for their purposes (aka by far the vast majority of Godot users). Getting more of those users involved should be at the forefront of concerns for any open source project imho, because once a user has submitted an proposal even of the smallest kind, they will immediately feel a lot more invested into the project as a whole. This then in turn can lead to more bug reports from this user, more involvement in the community and discussions and maybe even someday a PR from that person. For this reason I think we should establish the most accessible structure possible, that encourages people to submit proposals for small enhancements, not make it harder for them by requiring a social media rally (not everyones cup of tea), or to research to code owners. If I as general user who is not involved yet and does not care much about involving myself yet, seen good proposals for small enhancements closed, just because they ran out of time and apparently been opened by someone who is not as well connected as a hand full of other users, I would really hesitate to involve myself too. Because why? Only to see my spark of concerns/ideas/improvements/enthusiasm die or forgotten?

I liked the sound of @akien-mga s summery in #1 better, where he stated:

Proposals for substantial changes have to go through the GIP process.

    "Substantial" is the key here. Consensual proposals which don't require a substantial amount of code/design discussion can go from the "approved issue" to a PR on the code repository directly.

In the long run, setting up a website like https://blender.community/c/rightclickselect/ as @nate066 suggested might be a very good idea.

For now, I think making it as clear as possible to a general user (who is not necessarily a CS student) how to differentiate between a bug or a feature request and examples for substantial vs minor feature proposals within the issue submit form would be necessary.

TL;DR: To facilitate involvement and therefore Godot's growth:

• make it as easy and accessible as possible for literally any Godot user to submit small ideas to improve Godot, help them understand what is "small" and let this information flow to code owners and contributors in that area
• make sure those Godot users feel heard and validated when they do so

[reduz]

@golddotasksquestions The problem is that the amount of content in this regard submitted daily is enormous, and it is only going to get worse. Allowing users to easily express what they want, without going into detail, only results in nobody having the time and interest to check and discuss all those proposals. In the end also, contributors just do whatever they want because this is an open source project, not a company, so there is a complete disconnect.

The point of all this is that, proposals need to be less and more detailed, this will considerably increase the chances of them being actually discussed and approved, so contributors can tell more easily what they can pick up and contribute with.

We are also not going to use any external site for this, because for organizational purposes, GitHub allows much better cross referencing of issues.

[KoBeWi]

The only disadvantage of GitHub is that you need an account. Not only to create proposals, but also to upvote them. Not everyone has an account here, which might be a problem when trying to get bigger community input.

[girng]

I personally think the main issue tracker should be for bugs/issues that make Godot unstable. I really like the concept of GIP.

[golddotasksquestions]

@reduz I understand what is being discussed here. I read everything and over at #1 and share your reasoning and intentions. I made my comment because it might be easy for people who engage with one another here, who had a Github account for a long time or use it daily, to forget how if is for people who don't have a Github account, who are not engaging in such a community already, who first and foremost want to use software. These people are very valuable. Their opinions are as well. The are the majority after all (Just compare the download numbers, or Discord and subreddit members to the people who regulary engage here on Github)

I would like to bring attention to the question how we can include those people who first and foremost use Godot (and not contribute as of yet).

This GIP process here and Godot as a whole seems like a very democratic form of collaboration which aimed to cater to all it's users needs. "What users want ...", "If there is enough support ...", "If enough users express the need ..." That's all great and really beautiful, but devs will also get a skewed image of those wants and needs if only a small group of hardcore users and contributes are actually participating. Naturally, users who contribute engine code and who are very active here often often have a strong "backend" focus in their interest, while users who do not participate have their focus on using the tools provided to create a game. Those groups don't always have the same needs or understanding of issues. For better games, for a better tool, the barrier between them needs to be as thin as possible.

Separating bugs from features is definitely a good, probably very overdue, step forward. I think also separating minor improvement requests (like these for instance: https://github.com/godotengine/godot/issues/27782 , https://github.com/godotengine/godot/issues/27276) to bigger feature proposals is a good approach. GIP makes a lot of sense for such bigger proposals.

[reduz]

@golddotasksquestions As I mentioned before, the intention here is to make things easier for developers, not users. This puts more burden on users and it's completely intended, simply because most of our contributors don't have the time and resources to interact with every little thing the community does.

Also, drawing the line on "minor improvement requests" is grey and debating what constitutes "minor" would end up being a major discussion. This is why I prefer there is no such distinction at the beginning and, once the system is working we can see how to improve it.

[golddotasksquestions]

I completely agree the focus here is to make things easier for developers and contributors, having a "burden of prove" and everything else discussed here is good.

Ways to archive more oversight and less work for could be a better form to submit such proposals. Separation in different categories. Helping users to self-seperate in broader categories (and let issue wranglers worry about odd cases), and therefore help contributors to find issues they have feel responsible for or have interest in. Maybe allow contributers to "subscribe" to certain categories.

But I don't think these improvements should happen on the cost of accessibility for anyone participating by making code-owners persuasion a requirement, actively discouraging participation via auto-closing after a period of time or punishing a users lack of social media presence.

[willnationsdev]

@golddotasksquestions

Separation in different categories....and therefore help contributors to find issues they...feel responsible for or have interest in. Maybe allow contributors to "subscribe" to certain categories.

GitHub does not support subscribing to certain categories of Issues. Users can subscribe to individual Issues, and they can configure their Watch settings for a repository to be on high alert so that they are alerted with every new Issue/PR, but they cannot configure GitHub to send them notifications when Issues meet certain criteria.

The alternative is that the triage team goes through and adds labels like topic:editor, topic:mono, topic:gdscript, etc. to Issues and then users can filter Issues by labels to help narrow down where their interests are, but it's up to users to set up that search themselves (and bookmark a link for it, if desired for quick access).

But I don't think these improvements should happen on the cost of accessibility for anyone participating by making code-owners persuasion a requirement, actively discouraging participation via auto-closing after a period of time or punishing a users lack of social media presence.

I think the disconnect here is that someone somewhere along the way has to approve the changes before they will ever be merged. Most often that is reduz, akien, or one of the other codeowners like vnen, neikeq, etc. I suspect the over-arching goal is to broaden the scope of codeowners' involvement in merging code, in order to lessen the responsibility on reduz/akien who, again I only suspect, share the brunt of the work.

The balance that needs to be maintained carefully is going to be when a proposal is deemed fully discussed/decided-upon and what that means for whether the Issue is closed. It will be the core contributors who start making these decisions, based on the criteria outlined in the OP. If, however, the determination is up in the air, i.e. it is possible there could be support for it, then it will probably be left open so that people have the opportunity to voice their interest in it.

At that point, it will be up to someone interested in it, who has seen it, to share it around and gather support for it (not necessarily the OP of the proposal), and if a long period of time goes by with no one showing any kind of interest in it, then that is indicative of the feature not having enough support to be implemented (which...makes sense from a contributors' standpoint).

If a proposal exists and is a good proposal, but it doesn't have any support behind it simply because no one has seen it (for whatever reason), then that isn't something the contributors have a responsibility - or even a capability - to fix. Proposals are on GitHub. If the average Joe wants to have a say in what gets made, they have to come here to see it and offer their support. Many people don't do that though, and in those cases, it is the OP's (or a like-minded GitHub user's) responsibility to bring it to people's attention on social media if they expect the situation to improve. The repository maintainers and contributors do not have a role in rectifying that situation.

Edit: I share your motivation in wanting people to be able to accessibly find and support the features that matter to them, but by nature of the medium, people have to come to us. When they don't, it's their own fault for not being involved, just matter-of-factly. It's out of our hands.

[puchik]

veto power (I don't really think I have it either)

Are you sure, great leader? 🤔

https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

On topic, it does seem that asking for social media support for smaller PRs may be problematic. At best you're going to post on Reddit or Twitter and hope people bother to log into GitHub (if they even have an account) and upvote the PR. Feels like the amount of attention/proof it needs should scale with the size of the PR.

[xsellier]

In my opinion, @reduz concerns are legit. The number of bugs/feature proposals has exploded.

Consolidate information

The average user, you, me, everyone basically, when she/he encounters a bug, she/he opens github and searchs for an issue. If she/he can't find anything, she/he opens a new issue. But here it is, in github when you do a search you only search in the open issues by default.

Issues and the master branch

Bugs are mostly fixed in the master branch and sometime, if possible, they are cherry-picked to the older branches (2.1, 3.0, 3.1). Let's say you started working on a game back in 2017, with version 2.1. You spent almost 2 years working on it. When Godot Engine 3.1 is released, it is not backward compatible, and it will require you to spend a lot of time porting your game to the latest version. So you skip it because you cannot afford it and v2.1 is supported (no new feature but bug-fixes).

Now, let's say you encounter an issue in Godot Engine v2.1. You search on github but you don't find any issue that matches your bug. So you create a new one. Godot's maintainers start helping you and they found another old issue that matches your bug. But the issue is closed or archived because it has been fixed in a later version of Godot engine. There is a lot of issues in this case. Here is a very very small list:

• https://github.com/godotengine/godot/issues/12307
• https://github.com/godotengine/godot/issues/7288
• More (not all of them)

So you opened a new issue, and you bothered people that already knew the issue. So you've just wasted their time and yours. A solution to this problem would be to not close an issue if the version in which the issue was opened does not contain the fix (I'm not talking about patch version but major/minor)

Regressions

The lack of regression tests of Godot Engine makes it impossible to know if a bug is really fixed. Maybe it is fixed for MacOs but still here for Windows for example... With a codebase of several hundred of thousands of lines of code, it is impossible to test the modifications without spending a considerable amount of time. So asking the contributors to test the PR themselves is not enough. Godot engine needs regression tests.

[aaronfranke]

When it comes to identifying which core contributors to ask for helping/reviewing, it would be nice to expand the CODEOWNERS file. For example, right now there's nobody listed for VisualScript - even if there's nobody stepping up to actively write code for it, it's still good to list somebody that can be contacted for review if others propose and implement features for it.

Also, we could consider making the list more specific, in case some contributors often contribute to a small set of files or folders, it would be nice for other contributors to be able to find them easily and ask for feedback. I'll gladly look over changes to modules/mono/glue/Managed/Files even if I'm not the final say or can't maintain the whole module.

[LikeLakers2]

I have to wonder, if we need to make feature proposals first, what of PRs like my PR https://github.com/godotengine/godot/pull/30738 that are fixing an issue (exported properties labeled type "Script" did not function properly in the inspector) which ends up adding a new feature/enhancement (you can now export "Script"-type properties, though they will not be instantiated automatically)? On one hand, it's sort of a bug-fix which means it wouldn't need a proposal. On the other, it's an enhancement and thus should need a proposal.

How would we theoretically handle those?

[Xrayez]

I may be regurgitating something already but just giving my feedback.

It's easier to review, discuss, approve or reject a proposal than a PR.

I think there's a reason why some people prefer going straight towards implementation rather than starting a discussion so as to not interrupt the creative process (also known as "the flow", but some call it OCD/ADHD 🙂). In fact I feel like some of the features might start as an experiment which would snowball into an actual implementation eventually.

At the very least, if the implementation is obvious and simple, it should bypass the GIP process and be handled within the main repository, referring to https://github.com/godotengine/godot-proposals/issues/1#issuecomment-495249640 as mentioned by @golddotasksquestions.

Ensure users are interested about discussing it. If you don’t see enough interest, you can try to gather some on social media.

Shouldn't GIP itself be used to gather more interest? I cannot know for sure whether something is worth discussing without discussing it in the first place.

So I think there should be two kind of proposals (or deemed as such):

1. Ideas which are still being worked on (literally developed on a level of screenshots, diagrams etc). These should be labeled as Work-in-progress ideas to give it a chance to adapt against user feedback, within the same GIP framework.
2. Proposals which are ready conceptually (and ready for review by core contributors).

Perhaps I misunderstood some of the ideas/intentions here though.

The whole process must not become more bureaucratic

Perhaps we should also refrain from using this word then.

[willnationsdev]

@Xrayez Why not instead make "work in progress" the default and have a ready label that indicates an Issue has been fully fleshed out and approved, as a means of stating to contributors that "this is a ready-to-implement proposal"? Perhaps accompanied by an updated implementation to-do list of tasks to make in the code in the OP or one of the most recent comments?

[Xrayez]

@willnationsdev yeah I think this would also prevent the devs from prematurely closing/rejecting incomplete proposals that way. 😛

[reduz]

@Xrayez Definitelty not. Please read again the reasons why in the OP.

We core contributors more often than not have no idea what to do with PRs that do enhancements, whether they are needed, wanted by the community, deciding whether the usability is correct, etc. In the end we end up wasting a lot of time debating that, when the community can better address all this in a proper proposal.

This is why PRs that add features or enhancemets will be closed if there is not a discussion here that precede them. The only way is to get permission by a core contrib to fasttrack it.

[Xrayez]

Please read again the reasons why in the OP.

I do understand the reasons, but I don't think they are as severe as they are portrayed.

I created a whole repository just to demonstrate my idea (pun unintended!) of how I see this from a user perspective.

So in effect this is like pre-approve stage I was mentioning.

[reduz]

@Xrayez again. The threshold for your reasoning is subjective and drawing the line right now is impossible. For now, PRs like the ones you mention will be closed. In the future we may figure out objective rules, but we need to see how everything works first.

[golddotasksquestions]

Hmm, I guess this whole discussion would be unnecessary if the title of the blog post would have been more honest: "No feature proposals or improvement suggestions on GitHub allowed anymore, unless those features are proven to be needed in existing Godot projects and cannot possibly be worked around in GDScript or by writing Plugins"

[reduz]

@golddotaskquestions More or less, yeah.

Unfortunately it's the only realistic way proposals can be filtered, evaluated and prioritized, else the alternative is them being outright ignored like now.

[LikeLakers2]

As mentioned in the referenced PR just above this comment, as well as a comment from earlier in this issue, I'm unsure if I should be making a proposal issue on this repo for the sort of PR that could qualify as both a bugfix and an enhancement. Would anyone here be able to help me on that matter?

[Eoin-ONeill-Yokai]

I have some reservations about this new design for Godot proposals.

While I understand and sympathize with the problems that existed in the previous pipeline and the intent behind this new system, the current idea of routing all proposals to a separate repository raises a few questions. Looking at each of the old pipeline's stated problems, does this new pipeline adequately solve them?

1. Too many issues.

Does this actually reduce the number of issues that Godot currently has or will receive, and is that actually a good thing? Simply moving proposals from one repository to another won't decrease the number of proposals that people submit--like moving books from one shelf to another, it only changes the location and organization. It also doesn't guarantee that proposals are submitted to the right place or less likely to need filtering by core team members. On top of that, since github can already isolate bugs from proposals (for example) using labels, how does adding a second repository benefit organization?

I also find myself unsure whether "too many issues" is actually a correct assessment of the problem. From my experience so far, bug reports, feature ideas, pull requests and other [high-quality] forms of community contributions are not only a good thing, but a very necessary component of prosperous open source projects. Is the problem really the quantity of these things, is it the organization, or is it the quality?

2. Too many shallow issues.

If the problem is actually too many shallow, vague, or generally low-effort proposals, then I think that this may not be very effective. First off, having rules and guidelines is absolutely a good thing and makes a lot of sense. However, this is the internet, and (for a variety of reasons) simply having rules doesn't mean that they will be followed, and it'll still be up to the core team to review, filter, move, and close shallow issues.

The second, and in my opinion more pressing, issue has to do with the concept of upstreaming, which is at the heart of almost all open source projects. Whether you're a solo developer or a game studio, one of the big benefits of an engine like Godot over something like Unity (for example) is being free to make changes to the engine that you personally see as beneficial to what you're doing or how you work. Sometimes, these changes are specific to a certain project or workflow, and that's fine. However, other times, you may feel that some change that you've made may be beneficial upsteam--that is to say, Godot Engine itself and its users in this case. This raises two, very fundamental questions: (a) does Godot Engine want upstream patches from individuals and studios? And, if so, (b) what does the upstreaming process look like under this new system?

If I work for "Studio X", and I have a patch in my own fork of Godot that is already designed, implemented, and (I think) quite good. Should I attempt to submit this patch upstream and how? My understanding of the new proposals repository leads me to think that you (the core Godot team) want to be involved as early as possible, from the design to the implementation. Does that mean that you are no longer interested in upstream patches? Or does that mean that people with concrete, and in some cases, complete implementations simply need to go through the motions of submitting an abstract proposal before submitting their patch?

If so, then I have a few concerns. (a) Making it harder to upstream patches means that people are less likely to do it, which ultimately means that Godot may potentially lose out on high-quality upstream feature submissions. (b) People with concrete ideas and working implementations who still want to upstream may need to "pretend" that their features aren't implemented, and, in lieu of concrete PRs, you end up with more issues that are abstract or vague.

3. Unsure about PR usefulness and quality.

This might work. If the only ideas that make it to the PR stage of the pipeline are ideas that have been co-developed by the core team and the community, then I think that you will feel that the general usefulness and quality of PRs is high. Proposals that you don't like will not advance, while the ones that you do like will advance under your guidance.

However, I'm personally not sure how that's different to the old process of receiving a PR, reviewing it, discussing it, developing it, and eventually accepting or rejecting it. This leads to the next point...

4. Harder to review patches (PRs) than proposals (issues).

Is this really the case? Proposals are essentially ideas, and ideas are (at face value) very hard to accurately qualify to the point that they can be accepted or rejected early. Sometimes even "good" ideas are held back by a poor implementation, and (outside of some very extreme cases) it can hard to fairly judge an idea to be "bad" outright. If we were scientists, we would call a proposal an "hypothesis"--something that can't be qualified without some degree of testing or further exploration. To put it another way, how do we know when a proposal is good enough to be greenlit? And, when it comes to closing issues, how do we know when a proposal is not good enough to keep open?

---

Some other questions that may be worth consideration: (a) Does this speed up or facilitate the process of integrating patches? (b) Does this make people (from hobbyists and hackers, to professionals and studios) more or less likely to contribute? (c) Will this make people whose patches or ideas are rejected less salty or less likely to take things personally? I have some thoughts on these too, but I'll save it for another time...

So, I know this is long, but as someone who likes Godot, wants to contribute to it more in the future, and wants to see it continue to thrive and grow, I felt like it was worth taking some time on a rainy Sunday afternoon to express myself. I'd like to say that my few experiences contributing to Godot so far have been very positive, and I hope that the types of patches that I've been contributing have been net positive for Godot as well.

[aaronfranke]

does that mean that people with concrete, and in some cases, complete implementations simply need to go through the motions of submitting an abstract proposal before submitting their patch?

As I understand it, yes, but the proposal doesn't have to be abstract and can/should mention actual use cases. Features should be discussed to see if it would be beneficial for everyone. A concrete and fully complete implementation of a feature doesn't mean it's useful to others, and if it's not useful to others then it's not worth upstreaming and continually maintaining. It's also possible that a feature designed for one use case could be made to work with many more use cases if it's generalized.

[willnationsdev]

@Eoin-ONeill-Yokai

I'm not a core contributor exactly, but here are my thoughts on things based on my observations so far:

Does this actually reduce the number of issues that Godot currently has or will receive, and is that actually a good thing?

If the rate at which proposals are submitted is too high, then core contributors won't even have time to address them. They will be struggling simply to triage them accurately, let alone actually get any work done. As such, none of the Issues will actually get worked on by anyone which, by default, makes the creation of Issues at that rate a bad thing. The new system is designed to reduce the volume of incoming Issues which directly counteracts this effect (meaning it is a "good" thing).

How does it help reduce the load? By precluding the creation of proposals that will not lead to an engine source code change.

The changes also affect another important change: when examining a PR, the use case and community-support of a proposal are not always clearly defined. The new template demands more information from the proposal creator, clarifying the context, requirements, implementation details, and benefits of the proposal.

By disregarding the vast majority of Issues in godotengine/godot and instead only addressing the proposals in the new repository using the new template, core contributors are relieved of the burden of needing to identify all of this information for the poorly backgrounded proposals in the old repo.

like moving books from one shelf to another, it only changes the location and organization.

Rather than just moving a book, it's like someone is re-organizing their shelves by taking a book down from the old shelf, reading it, adding notes, underlines, and tabs everywhere with a summary and analysis attached, and then placed the now-updated book in the "Annotated" shelf. Only, the core team aren't the ones doing that work anymore. Now they need only read the summary/analysis.

From my experience so far, bug reports, feature ideas, pull requests and other [high-quality] forms of community contributions are not only a good thing, but a very necessary component of prosperous open source projects.

I don't think anyone on the core team disagrees. The problem is that most Issues are not high-quality and submitted PRs don't always provide adequate background.

I can speak from my own experience here. I have written some VERY hefty PRs that I believed solved various problems very well, but which were never thoroughly peer-reviewed properly at the Issue stage. The result was that the PRs I worked on were often more complex than necessary or just completely useless when no one stepped forward to say that they actually would use the features the PR added. The use case in actual live projects wasn't clear. How much people actually wanted the changes wasn't clear. Whether alternative solutions/designs even existed or were being worked on wasn't clear (is this really the best solution?). All the core team's work in reading the PR and evaluating it ended up being a waste of time because all of this important information just wasn't there.

Is the problem really the quantity of these things, is it the organization, or is it the quality?

The quantity and quality are both a problem. And the hope is that by enforcing a high quality (and auto-closing ones with low quality), the quantity will remain sustainable for the limited bandwidth of the core team.

However, this is the internet, and (for a variety of reasons) simply having rules doesn't mean that they will be followed, and it'll still be up to the core team to review, filter, move, and close shallow issues.

Of course, rules may not be followed, but now there is a proper pretense to close issues early if the user hasn't done the front-work of making a detailed and relevant proposal. The team will be able to tell, at a glance, if a proposal has enough information (if not, and the user doesn't respond soon to requests for a more thorough proposal, then it gets cut), and the wording of the template itself deters people from making frivolous proposals.

does Godot Engine want upstream patches from individuals and studios?

Of course. That'd be great.

what does the upstreaming process look like under this new system?

They should open a Proposal for what their changes to upstream would look like, give a description of the context of the program they were writing, what problem they ran into, how their changes helped fix that problem, why it couldn't just be solved with a simple script, why it is necessary in the main engine repository (instead of just as an external addon), and provide a visual example of the changes in action.

This vastly speeds up the core team's ability to evaluate whether a PR submitted by this Studio X developer should actually be merged or not.

Just because you solved a problem for your project and like the way those changes affected your Godot build doesn't mean other people concur (or that other people don't have better approaches in mind for solving the same problem). Everyone should go through the official proposal process.

If I work for "Studio X", and I have a patch in my own fork of Godot that is already designed, implemented, and (I think) quite good. Should I attempt to submit this patch upstream and how?

See above.

Or does that mean that people with concrete, and in some cases, complete implementations simply need to go through the motions of submitting an abstract proposal before submitting their patch?

This, except for the abstract bit. The more specific they can get, the better.

Making it harder to upstream patches means that people are less likely to do it, which ultimately means that Godot may potentially lose out on high-quality upstream feature submissions.

I suspect that the core team would say, "So be it. It's better for us to verify that the changes are desired rather than merging code willy-nilly. But if the people believe that strongly in it, they can always contact us directly on IRC and discuss having us fast-track their changes."

People with concrete ideas and working implementations who still want to upstream may need to "pretend" that their features aren't implemented, and, in lieu of concrete PRs, you end up with more issues that are abstract or vague.

No need to pretend. In fact, having the feature already implemented in their Godot version makes demonstrating the usefulness and mockup portions of the proposal a heck of a lot easier. XD Just show a before/after with a latest stable build and their build for the usefulness part and take screenshots for a "mockup". They can also give much more detail about the relevant code changes involved which helps a lot in dissecting whether it's a good approach.

If the only ideas that make it to the PR stage of the pipeline are ideas that have been co-developed by the core team and the community, then I think that you will feel that the general usefulness and quality of PRs is high.

This is the idea. I've already covered how this is different from the old process (bookshelf transfer analogy).

Proposals are essentially ideas, and ideas are (at face value) very hard to accurately qualify to the point that they can be accepted or rejected early.

They are ideas, yes, but they are ideas without context. They simply say, "I have this change I would like to make. There is some problem I've dealt with and this fixes it. Here you go." Rather than, "Here is a documented case of a real task not performable due to a problem. Here are my changes. They fix the problem exactly in the way that has been previously discussed at length by the community. The community approves of these changes and has already had plenty of time to digest and debate them. All you need to do is verify that the code is correct, rather than figuring out all this other stuff that's not relevant to the code itself."

it can hard to fairly judge an idea to be "bad" outright.

When an idea is just an idea without the accompanying context, it amounts to clutter that slows down the work of core contributors. Ideas should go somewhere else (#47 hint, hint core contributors!) so that people who aren't actively working on the engine can have a place to track them, not slow core devs down, but also develop those ideas into full-blown proposals if they ever get to that point.

To put it another way, how do we know when a proposal is good enough to be greenlit?

When people have spent a reasonable amount of time discussing a properly detailed proposal. I did suggest the creation of an approved label, but never heard back on that idea.

And, when it comes to closing issues, how do we know when a proposal is not good enough to keep open?

If a core contributor requests that the proposal be updated with more information and the person doesn't follow through with the request within a few days. I would guess anyway. Sounds about right.

Does this speed up or facilitate the process of integrating patches?

Tremendously. Have already stated as much in prior answers though.

Does this make people (from hobbyists and hackers, to professionals and studios) more or less likely to contribute?

My guess is that it would make people less likely to contribute by a small margin as those who are tentative about getting involved with an open source project in the first place - with little experience contributing to anything - would likely feel intimidated by the amount of information being requested of them. And hey, those people might have good ideas, who knows? But if people wouldn't have had time to hear them out anyway, then all that would be happening is everyone involved wasting their time.

Will this make people whose patches or ideas are rejected less salty or less likely to take things personally?

I have most certainly gotten salty, even with the existing system. I don't think these changes will necessarily make someone more or less salty (so long as #47 is dealt with so that addon/plugin/module changes have a place to live properly). If you are asked to provide the necessary information, and don't, then that is your own fault for not providing the context of your request adequately. I think that core devs will be lenient with those who actively update their information appropriately and less lenient with people who make a one-off, low-effort suggestion and then barely respond to replies.

I'd like to say that my few experiences contributing to Godot so far have been very positive, and I hope that the types of patches that I've been contributing have been net positive for Godot as well.

Glad to hear that, and I'm guessing they have been, based on your thoughtfulness and depth here. :-)

I myself have had a, what I perceived to be, a very mixed bag of reception for PRs, mostly because I fell victim to being exactly the kind of person whose requests they rejected. And in retrospect, I can see exactly why they rejected every one of the PRs they did. I was blind to my own desire for these features without the preparedness to back them up in terms of use-case, benefits, and/or mockups. I see better ways of doing things now and have become more active in engine changes again after, for a long time, relegating myself to plugins, not wanting to be very involved in engine changes. Then I found that much of the plugin work I'd done was chump change compared to the effect a proper engine change would've made for solving those problems.

And while in some sense, it might have felt like wasted effort, on the contrary I have now done the work of verifying whether the stuff is doable from a scripting side and have a better understanding of the problem domain, how the engine needs to change to enable better scripting solutions, and can provide examples/mockups of what the changes could look like if implemented. This process has made me need to do the work of proving the effectiveness of my changes and go into more detail about why it's important. And all of that helps give context to any PRs that would be associated with them, increasing the chance that they get accepted (so work actually gets done).

[kone9]

I would love to have 2 options for the language one where the language of the program environment is chosen and another option where you can choose the language of the tooltips. This is something I always say to all program developers, since maintaining the interface in English helps make the tutorials universal, however having the tooltips in the language of each one helps to understand the tool ... I think that it is very important to have the tooltips and the language of the editor separately. In my case I speak Spanish and use blender3D and what I do is keep the interface in English, but the tooltips in Spanish, it doesn't matter if the guy who does a tutorial speaks in Japanese, while the interface is in English I understand what he does looking the procedure and if I have any doubt, I have there the toolstips in Spanish to understand the tool a little more ... I hope they implement it, I think this is something very necessary and is a concept that I only saw in Blender3D ...

[willnationsdev]

@kone9 Did you perhaps mean to create an Issue? What you commented has little relevance to this Issue. You should make a new one that fills out the Issue Template so that the community can review your proposal more effectively. Thank you for your suggestion though.

[Eoin-ONeill-Yokai]

As I understand it, yes, but the proposal doesn't have to be abstract and can/should mention actual use cases.

By abstract I don't really mean vague, poorly-formed, or like a Picasso; I mean to say abstract as opposed to concrete. I should also mention that concrete doesn't mean inherently good or worthy of acceptance, nor does abstract mean inherently bad. Code and design are concrete, ideas and are abstract. Generally speaking, it's much easier to make objective judgements of concrete things than abstract ones.

By virtue of the fact that proposals (issues) do not contain actual code, they are inherently less concrete than even a work-in-progress or proof-of-concept patch (PR). Thus, in the very common case of upstreaming, where an individual or studio already has a patch ready for submission, asking them to first submit a proposal is going from something concrete to something abstract.

Of course, whether it's via an issue or PR, ideas should be well reasoned and explained, but that's not really what I'm alluding to.

Features should be discussed to see if it would be beneficial for everyone.

Agreed. But, whether that happens as an issue on this repository, or a PR on the actual repository is the crux of this change, and I'm not sure that doing it here makes anything faster or easier for anyone. 'Bad' proposals will still need to be triaged, reviewed, asked for changes or closed. 'Good' proposals will now need to be, somehow, greenlit so that whoever is responsible for implementing that change can know to submit a PR.

If 5000+ issues come in, whether it's here or there, there is still an associated maintenance burden, and if every patch needs to have two rounds of approval (proposal first, PR second), the maintenance burden may actually become worse. That's assuming, of course, that contribution doesn't decline in general, which we all hope to be the case, because a general decline in contribution would definitely be a bad thing.

A concrete and fully complete implementation of a feature doesn't mean it's useful to others, and if it's not useful to others then it's not worth upstreaming and continually maintaining. It's also possible that a feature designed for one use case could be made to work with many more use cases if it's generalized.

This is also totally right, and the opposite is also true. There are occasions in every open source project when a patch request comes in that is useful to others almost right away, or close enough that a simple request for changes is adequate in getting it where it needs to be.

In these cases somebody submits a PR, reviewer asks for a few changes, submitter makes those changes, and when everything looks good and meets approval requirements, the patch is merged. Those are "good patches", and one my main concerns is that, by introducing more steps, this system will make it harder for people to submit (and therefor, for Godot to receive) good, useful and desired patches.

(Keep in mind that we're not talking about random "hey I unilaterally rewrote the entire node system, plz pull" type of PRs that can be easily rejected outright for obvious reasons. Because, from the sounds of it, even small, reasonable patches and minor feature submissions will become a multi-step process for both the submitter and the reviewers.)

[vnen]

Well, @willnationsdev addressed very well the points of @Eoin-ONeill-Yokai. I still want to add a bit of my opinion on the points, which are all valid concerns.

Does this actually reduce the number of issues that Godot currently has or will receive, and is that actually a good thing?

Yes. It's not only moving. Godot is now requesting a higher quality barrier for feature and enhancement proposals, so this will diminish the volume of new issues in the main repository and it's natural that issues here are rarer (or they can be insta-closed by not following the template).

It is a good thing because less issues means more time per issue that a contributor can give attention. There was a time when I read every single issue and comment in the repository, so I could easily pinpoint duplicates. Now there's no way I'm gonna clear my over 7000 notifications any time soon and I can barely pay attention to the ones I'm actually participating. Reducing the number of new issues is a good thing (just because Godot has too many issues and too few people).

If the problem is actually too many shallow, vague, or generally low-effort proposals, then I think that this may not be very effective. First off, having rules and guidelines is absolutely a good thing and makes a lot of sense. However, this is the internet, and (for a variety of reasons) simply having rules doesn't mean that they will be followed, and it'll still be up to the core team to review, filter, move, and close shallow issues.

People won't follow the rules. But if Godot has a clear ruleset of how to present a proposal, then they can politely ignore anything that doesn't follow the rules. Honestly, I think it's okay even to setup a bot that automatically closes issues without the template. If people want to be heard, they have to follow the rules. I know this will generate backlash, but I believe that being obviously ignored is better than being implicitly ignored just by the sheer amount of new stuff that buried your idea.

However, I'm personally not sure how that's different to the old process of receiving a PR, reviewing it, discussing it, developing it, and eventually accepting or rejecting it. This leads to the next point...

Problem is the time. Reviewing a PR today means trying to discuss whether or not it is wanted and if the API is generic enough to be useful for many projects and if the implementation is okay in terms of design (and, of course, in terms of actual code). This means core contributors spend a lot of time in PR review meetings discussing those things, and there's a lot of new PRs being opened at the same time.

At the same time, the PR author will receive many comments that "there's a style error", "there's a typo here", "this variable could have a better name", "this could be extracted to a new function", "it needs to fix a conflict", "it needs to rebased on master", and a lot more that is related to details of the implementation before the feature was accepted in general. PR authors tend to fix those small issues quite quickly, but then have to wait for a PR review meeting for the core contributors to see and then decide that "the design is not the Godot-way and should be written in a different way". PR authors definitely get upset when this happens (and understandably so), since they worked on maintaining and rebasing their fork for quite some time and they discovered that the code wasn't going to be used.

With the proposal system, a PR won't be open (or won't remain open) before the feature itself was discussed in depth with the community and core contributors. So when a PR shows up, Godot can tell it follows the wanted design and the contributors can simply see if the code is functional and performant enough.

This will save time (and frustration) from both core contributors and PR authors. Even if it means less pull requests in quantity, it will increase the merged PR ratio and decrease the time a PR remains open. IMO that's better than what Godot has now.

4. Harder to review patches (PRs) than proposals (issues).

As a said above, reviewing a PR is more than just looking whether it's functional, there's a need to see if the proposal is really wanted and follow a generic design that can be clear and useful to many people.

Is this really the case? Proposals are essentially ideas, and ideas are (at face value) very hard to accurately qualify to the point that they can be accepted or rejected early.

It is hard to reject or reject ideas early. That's why there are open PRs that are almost two years old. The problem of having them there is that they take space of new stuff and there's the obvious question that's hard to answer: "when are they going to be reviewed again?"

Sometimes even "good" ideas are held back by a poor implementation, and (outside of some very extreme cases) it can hard to fairly judge an idea to be "bad" outright. If we were scientists, we would call a proposal an "hypothesis"--something that can't be qualified without some degree of testing or further exploration. To put it another way, how do we know when a proposal is good enough to be greenlit? And, when it comes to closing issues, how do we know when a proposal is not good enough to keep open?

I understand the point of these questions but they are valid with or without a proposal system. What the system wants to mitigate is the subjectiveness of it all. If Godot has clear and detailed guidelines for proposals, it should be easier to see whether or not each proposal is a good fit.

The system provides a set of questions that can easily (well, at least easier than the current system) discard proposal. If it's a project-specific thing, or if it's not used often, Godot can relegate that to a plugin and not create a new feature in the engine.

OTOH, Godot will know about the good proposals, They will be heavily upvoted and a core contributor will approve it when that happens.

Some other questions that may be worth consideration: (a) Does this speed up or facilitate the process of integrating patches?

Yes. When a proposal becomes a PR, the review will be faster than it is now, because only the actual code needs to be reviewed, not the design decisions. It also means that PR for bugfixes can be looked faster, since the review is more streamlined, less stuff will be left behind.

Of course, making a proposal and getting enough rep to be able to create a PR might make it slower in general from time of creation to the time of merge. But IMO it will save time of both PR authors and mergers as I stated above.

(b) Does this make people (from hobbyists and hackers, to professionals and studios) more or less likely to contribute?

Probably, yes. Honestly, I don't think Godot lacks in proposals though. Also, remember that bugfixes can be solved directly by a PR, it doesn't need a proposal. For bug reports, they are much more simple than a proposal, so it's much more approachable. Less issues with higher quality is better in my view, since it makes easier for them to actually being seen.

(c) Will this make people whose patches or ideas are rejected less salty or less likely to take things personally?

I think so. As I said above, many PR authors get frustrated when their code change is rejected a month after it was opened, after they solved conflicts and made small corrections. Those are less likely to open a new PR.

An idea that is rejected has a lower effect, because the work is more about the semantics of the proposal and the author only needs to argument their idea. No need to be doing small maintenance on work that won't be accepted. Also, rejection and acceptance will mostly come from the community, not from the core contributors. People are more likely to accept that the community don't want what they propose than when there's one guy with a Member tag rejecting it. The process makes it less personal.

---

We do have to see if this is a benefit, so the questions are valid. But I don't think what Godot has currently is sustainable, so there's definitely some change needed. I believe that the system proposed here is a good starting point.

[Eoin-ONeill-Yokai]

@willnationsdev Hey Will, thanks for the detailed reply! I'll reply to as much as I can.

How does it help reduce the load? By precluding the creation of proposals that will not lead to an engine source code change.

But how? I'm not sure I understand how pushing ideas from one github repo to a different repo actually does that. It's still going to be possible for people to freely submit ideas as issues (which don't carry any code), and those ideas still need to be triaged, organized, and generally vetted by the core Godot team. Nor does it reduce the likelihood that proposals (even those that start strong) get held up, stalled or abandoned before ever being made concrete, let alone being merged.

...when examining a PR, the use case and community-support of a proposal are not always clearly defined.

Sure, but why not simply improve the template for the PR process and require these sort of base-level things from submissions? If somebody submits a patch and they fail to make it clear what it is, who it's for, and why Godot Engine would benefit from merging it, they could simply be asked to refine their PR and provide more information.

Unless something is going over my head here, the new system doesn't seem to make it any less possible to write a bad proposal than writing a bad PR under the old system.

By disregarding the vast majority of Issues in godotengine/godot and instead only addressing the proposals in the new repository using the new template

Do you mean to say that the backlog of proposals in the old repo are just going to be disregarded in an attempt to wipe the slate clean? I'm not so sure about that...

The more specific they can get, the better.

Ok, but assuming they've taken the steps to adequately explain and justify their submission, what's more specific than an actual patch?

As the old saying goes "the proof is in the pudding". People can talk back and forward online for days, weeks, or years about whether a proposal might work or what ramifications it might have, but in many cases a patch (which shows, very concretely, what will change and how) is the best way to convey an idea--because people can take screenshots of it, because they can review the code, and because anybody can build and run it for themselves. As such, even the best proposal won't be as specific or concrete as a PR.

I suspect that the core team would say, "So be it. It's better for us to verify that the changes are desired rather than merging code willy-nilly. But if the people believe that strongly in it, they can always contact us directly on IRC and discuss having us fast-track their changes."

Well, nobody's talking about "merging code willy-nilly", and to say that some people will be having patches fast-tracked kind of contradicts the "everybody should need to submit a proposal" statement from before. Frankly, that does sound a bit bureaucratic, and avoiding that was one of the explicit goals of this change.

I myself have had a, what I perceived to be, a very mixed bag of reception for PRs, mostly because I fell victim to being exactly the kind of person whose requests they rejected. And in retrospect, I can see exactly why they rejected every one of the PRs they did.

Everybody has code rejected in open source, it comes with the territory and I try to never take it personally. Not every idea is a good one, nor every implementation, and sometimes good ideas and implementations are rejected simply because the project doesn't think they're a good fit for their overall strategy. That's Ok, and I respect the right of people who maintain and lead open source software projects to make the decisions that they believe are in the best interest of their project! :)

At any rate, I've run out of time today and I know I didn't respond to everything that you wrote, but I really appreciate your input.

Honestly, I'm still not totally convinced, but that's fine and I'm happy to try to work within whatever framework the core team decides to go with. I just hope that things work out for the better and that the result is net-positive for Godot and the surrounding community.

[vnen]

How does it help reduce the load? By precluding the creation of proposals that will not lead to an engine source code change.

But how? I'm not sure I understand how pushing ideas from one github repo to a different repo actually does that. It's still going to be possible for people to freely submit ideas as issues (which don't carry any code), and those ideas still need to be triaged, organized, and generally vetted by the core Godot team. Nor does it reduce the likelihood that proposals (even those that start strong) get held up, stalled or abandoned before ever being made concrete, let alone being merged.

It's not only moving, it's requiring a higher quality for them to even be considered. Proposals that don't follow the template can just be closed. Yes, someone will have to do it, but it's easier than having to decide up-front whether the proposal is feasible or not (with the alternative being letting it to rot like happened to a lot of old proposals in the main repo).

Stale proposals can be closed. If they gain traction again they can be reopened. Some of those things can be automated, even.

...when examining a PR, the use case and community-support of a proposal are not always clearly defined.

Sure, but why not simply improve the template for the PR process and require these sort of base-level things from submissions? If somebody submits a patch and they fail to make it clear what it is, who it's for, and why Godot Engine would benefit from merging it, they could simply be asked to refine their PR and provide more information.

Unless something is going over my head here, the new system doesn't seem to make it any less possible to write a bad proposal than writing a bad PR under the old system.

Because it gets in the way by cluttering the PR queue. Even with labels it gets harder to manage. Also, PRs contain code, and as I said in the other post, other people will comment on code details before the proposal is even considered. by the core team. By having only the proposal, the focus can be directed.

By disregarding the vast majority of Issues in godotengine/godot and instead only addressing the proposals in the new repository using the new template

Do you mean to say that the backlog of proposals in the old repo are just going to be disregarded in an attempt to wipe the slate clean? I'm not so sure about that...

No, see @reduz's comment up there: https://github.com/godotengine/godot-proposals/issues/10#issuecomment-527578702

Proposals that have a discussion and reactions will be moved to this repo. Is likely that most will be closed, but they can be reopened here following the guidelines.

The more specific they can get, the better.

Ok, but assuming they've taken the steps to adequately explain and justify their submission, what's more specific than an actual patch?

As the old saying goes "the proof is in the pudding". People can talk back and forward online for days, weeks, or years about whether a proposal might work or what ramifications it might have, but in many cases a patch (which shows, very concretely, what will change and how) is the best way to convey an idea--because people can take screenshots of it, because they can review the code, and because anybody can build and run it for themselves. As such, even the best proposal won't be as specific or concrete as a PR.

I don't see why a patch can't be part of a proposal. A reference implementation is a great guide. But it tends to move the focus from the actual usefulness/design of a proposal to the actual code. A PR is just too concrete and discussion is often derailed.

I suspect that the core team would say, "So be it. It's better for us to verify that the changes are desired rather than merging code willy-nilly. But if the people believe that strongly in it, they can always contact us directly on IRC and discuss having us fast-track their changes."

Well, nobody's talking about "merging code willy-nilly", and to say that some people will be having patches fast-tracked kind of contradicts the "everybody should need to submit a proposal" statement from before. Frankly, that does sound a bit bureaucratic, and avoiding that was one of the explicit goals of this change.

The thing is that core contributors (i.e. people who contributed a lot over a long period of time) have "earned" the right to skip this process. It should be less bureaucratic for core contributors. Even they must submit a PR which will be reviewed and may be rejected by the others. They just can skip the proposal step, and allow others to do the same. If someone has a lot of good proposals Godot may also want to "promote" this person to a core contributor.

Maybe there should be a list of who is or isn't a "core contributor", but OTOH we don't them to be harassed by everyone wanting to get attention for a proposal.