Godot Proposals: How to Submit a GIP

Choosing a Godot proposal issue or discussion

godotengine/godot-proposals solves a governance problem rather than a runtime problem. Godot is a community-driven engine, so proposed changes need a public place where users can define the problem, compare possible solutions, and discuss whether the proposed behavior belongs in the engine. The repository separates this process into two routes according to how far the idea has progressed.

Use Discussions for a general improvement idea that does not yet have a complete design. The README says a discussion can be started in any form. This makes Discussions the lower-constraint route for testing interest, collecting examples, and identifying whether other community members have encountered the same problem.

Use a proposal issue when the change is already specific and the author has prepared a detailed description. A proposal issue is intended to contain enough design information for the community to discuss it. It must make necessary design decisions rather than presenting only a feature request.

This distinction affects where effort should go. Starting with Discussions can prevent an incomplete proposal from becoming an issue that has to be rewritten. Starting directly with an issue is appropriate when the motivation, scope, and proposed solution are already defined. The repository README also encourages contributors to build on existing ideas and attribute them appropriately when turning an idea into a more concrete proposal.

Researching duplicates, workarounds, and plugin alternatives

The first requirement is research before submission. The README directs contributors to discuss the problem with the community, search existing proposal issues and Discussions, search the internet and Godot Asset Library, and look for addons that could solve the problem without changing the engine.

That last check is a meaningful boundary for the repository. A request may describe a real inconvenience while overlooking an editor plugin, asset, or another solution that works outside the core engine. A proposal becomes stronger when it explains why the available workaround is insufficient for the stated need.

The description should explain the underlying problem rather than merely naming a missing feature. The README uses baking a cake as an example: the useful framing is the desired outcome, while flour represents one possible solution. Applied to Godot, a proposal should explain what a user is trying to accomplish, what prevents the current approach from working, and which workarounds have already been tried.

Related proposals should be linked so reviewers can distinguish genuinely new ground from an existing request. If an idea substantially overlaps with another proposal but is more detailed, the README says contributors may support that proposal and discuss it instead. If the overlap is not substantive, a comment can be used to explain why the new proposal should stand on its own.

Writing an actionable Godot Improvement Proposal

A proposal issue must contain a well-developed idea, not a short feature request. The README requires authors to use their own words and expressly prohibits using an AI or LLM to write the proposal. It also says AI-written proposals can be difficult to read and may invent facts or solutions that will not work.

The proposal needs context, a specific solution, and enough detail for discussion. Images, mock-ups, diagrams, and code may be included when applicable. These materials are not mandatory in every proposal, but they can expose design questions that prose leaves unresolved.

The solution section must cover the necessary design decisions. A proposal that says Godot should add a feature, without defining its scope, interface, or behavior, is not actionable under the repository's stated rules. Ambiguous proposals can be closed. One issue must also correspond to one proposal; combining multiple feature requests makes independent evaluation harder.

There is no requirement in the README to assign an implementation version, provide a release schedule, or include executable setup code. Those details are absent from the proposal rules, so this review should not be read as a promise that every proposal receives a delivery date or becomes part of Godot. The outcome depends on community evaluation and approval by Godot maintainers.

Reviewing Godot proposals through support and maintainer judgment

The README describes proposal evaluation as an ongoing process rather than a fixed scoring system. Maintainers consider whether the proposal follows the rules, how much support it receives, and additional technical considerations. These factors are balanced, and maintainers retain discretion over how they weigh them.

Support is not described as a simple acceptance threshold. A proposal with little initial support may receive more attention later, while a well-supported idea still needs to satisfy the technical and procedural requirements. Contributors who want attention for an idea may share it through Godot community channels.

No proposal can be merged without approval from Godot maintainers. The README also states that an accepted discussion or proposal may eventually be implemented by a motivated Godot contributor, but this is not a delivery commitment. The repository has no GitHub releases, and the documentation does not define a version schedule for proposal outcomes.

The public discussion stage also has an enforcement boundary. A rejected proposal may indicate that the engine-level solution is unsuitable even when the underlying problem remains valid. In that case, the README suggests finding another approach, including implementing the capability as a plugin or a GDExtension.

Browsing proposals and beginning a first contribution

This repository is not an installable Godot package, so there is no installation command, build step, runtime configuration, or plugin setup documented for it. Its practical entry points are its web repository, the Godot proposals viewer, and the Discussions area. A first contribution begins by reading the proposal rules and selecting the route that matches the maturity of the idea.

For a broad idea, open Discussions and describe the improvement, the problem behind it, and any evidence of interest. For a defined change, prepare a proposal issue with the context, design decisions, workarounds, and related links required by the README. Before opening either route, search the repository and check whether an addon already provides an acceptable solution.

If a proposal is closed, the README recommends checking the closure reason. An invalid proposal needs more detail and compliance with the rules. A duplicate should be reviewed against the linked proposal. A rejected proposal may require a different solution, possibly outside the engine. The contributor's chat is the documented route for asking maintainers to reconsider a closure.

The repository was not archived, and its last push was on 2026-09-15. That records recent repository activity, but the README still describes a community review process in which acceptance and implementation remain separate decisions.

Choosing between Godot core work, plugins, and GDExtensions

The main alternative to an engine proposal is solving the problem outside the engine core. The README specifically names plugins and GDExtensions as possible answers when a proposal is rejected or when an addon can address the requirement without an engine change.

The distinction is architectural. A plugin or addon can provide behavior within the documented extension paths without requiring a new core capability. A GDExtension is presented as another route for implementing functionality outside core, while the proposal repository is for proposing a change that maintainers might approve into Godot itself.

This makes godotengine/godot-proposals the wrong repository for a crash, defect, or issue that cannot be attributed to a missing feature. The README directs such reports to Godot's issue tracker instead. It is also the wrong place to submit a request that could already be handled by an addon, unless the proposal explains why the existing solution does not meet the requirement.

The project is therefore a decision filter as much as an idea archive. Its rules ask contributors to establish that the problem is real, engine-level work is warranted, the intended change is specific, and the proposal has not already been covered. License information is limited to the repository's MIT designation, with no additional licensing model described here.

Editorial conclusion

Godot contributors should use this repository when they have researched a specific engine improvement and need a reviewable design proposal. Developers seeking bug fixes should use Godot's issue tracker instead, while people with only a general idea should start in Discussions. Before submitting a proposal, verify that no existing proposal, discussion, addon, or asset already addresses the problem.

Frequently asked questions

Official sources

1. godotengine/godot-proposals on GitHub
2. Issues
3. License: MIT
4. README