Goost - Godot Engine Extension. See my own philosophy at the Goost documentation. It's quite short, but it uses a language suitable to express these kind of things, not necessarily those which stem from pure logical reasoning, but also take into account human relationships/experience, and emotional states (something which Godot prefers not to talk about, the way I see it, despite welcoming various minorities).
It also uses estimations, because some things cannot be measured, but nonetheless, make it easier for everyone interested in contributing to make good judgements about the project, and most importantly, attempts to save the time it would take both the maintainers and potential contributors going into conflicts in the first place by giving alternatives.
Basically, anything which describes values, assumptions, beliefs, expectations etc. That said, most decisions are not governed by logic, despite what logic may say about this.
Update 2021: I got excluded from Godot Engine organization as a member for trying to clarify something that I was not even aware of as a contributor, see for instance godotengine/godot-docs#4799, or allegedly trying to quote core members to prove my point against them for the sake of it (which is not the case, all I'm doing is seeking truth/consensus via means of discussion), and I feel like any new willing and capable contributor may fall victim to this kind of circumstances at some point in time eventually.
It's not possible to reach consensus if this kind of ostracism, cancel culture, is used to manage members within Godot organization. The usage of the button is the demonstration of power, unfortunately.
I used to be a regular Godot Engine contributor, and even a member in this organization, because I've been implementing feature proposals as requested by other users, creating and maintaining custom modules and unit tests infrastructure in Godot, contributing features and enhancements I was personally interested in as well, but with various success rates.
Describe the problem or limitation you are having in your project
I'm looking forward to using godot-proposals for that matter. 😃
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.
When I first started making feature proposals in the form of pull requests years ago, my features were not met with much enthusiasm. Having acquired more experience as both a contributor and even a software developer, I have to admit that some of them seem silly by now such as godotengine/godot#19276.
But as I got my hands dirty, I started to contribute features which seem to meet both my own needs and the needs of others, such as godotengine/godot#28013. I then learnt that no amount of "thumbs up" can guarantee that the features get merged, but at least the good feeling you get from that seems to cover up the feeling of rejection, to some extent.
From what I've observed, it seems to me that a lot of people don't seem to get the ideology behind Godot development, or in fact it may have changed recently or rapidly evolving over those years, and I'm not sure how the work is really prioritized and what features are made into the engine. For some time I feel like the dedicated 2D engine is being neglected, and that's actually the reason why I've chosen the engine in the first place.
People coming from previous experience with Unity/UE4/etc. seem to request similar features to be available in Godot too, which may not be actually in alignment with Godot's intended core philosophy. Talking about not meeting expectations, which can lead to disappointment, for no good reason.
I see no formal document which could formalize the development ideology/philosophy behind Godot. We have documentation on how to contribute (talk first, make sure that the feature is needed etc). In general, those pages describe the "what" and "how", but not the "why". Start With Why.
There's even Godot's design philosophy but it doesn't really target the engine developers/contributors themselves with the purpose of giving a good direction towards how the engine should be like, and has only introductory/selling point value for those considering trying out the engine for the first time, not necessarily developing features.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Write an official documentation page or document which fully describes the development philosophy behind Godot Engine which would be mainly targeted at those wanting to make sure that their own development philosophy is in alignment with Godot Engine's one before considering contributing.
The most important questions which I'd like to be answered personally are:
Are we aiming for something like what other commercial engines provide, or is Godot becoming a Linux kernel but in the game development field instead (despite having a dedicated editor)? That's important because that signifies that a lot of current proposals should actually be targeted for module/plugin/addon development instead (hence the need for Godot Ideas repository: #1476). If that's the case (and it seems like the case, according to some classes already being removed from core in Godot 4.0, such as InterpolatedCamera godotengine/godot#42113), this leads to the next question of whether Godot would be willing maintaining those features via plugins officially. If Godot's development is considered highly organic but aims to prevent bloat at the same time, then Godot should define things like Feature Removal Policy.
If Godot can be seen as an open-source game development kernel, does it plan to provide a standard library distributed alongside Godot? Inspired by C++ STL, I'd personally see this being as Godot Standard Library (GSL), which would be written as GDScript, GDNative plugins and packages, and even C++ modules, such as the one I'm currently working on: Goost.
If Godot aims to further remove features from the engine to prevent bloat, would those features be actually maintained by the core developers? That would be actually the most important question to answer, because if those features won't be maintained on the same level as Godot core, the maintenance burden will lie on the shoulders of other (non-core) community members, and the amount of donations Godot currently receives would become quite disproportionate.
If the purpose and the intention is not clear, we'll keep accumulating feature and enhancements proposals which go against existing development ideology, making it more difficult to actually focus on those proposals which could benefit the engine in its current state.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams
Link this document at GIP, so people can have a chance to re-evaluate their proposals and whether they actually fit the ideology.
If this enhancement will not be used often, can it be worked around with a few lines of script?
I think that Contributing and Godot's design philosophy pages might give some answers to this on some level, but I honestly feel like there should be a dedicated document which just translates what seems to be hidden gems inside the minds of geniuses in the form of text. I know it may be difficult to describe a particular way of thinking, but please consider this option. If the vision is not yet complete, lets call the document "The Future of Godot", because we all need to share the same vision to make the development process as smooth as possible for everyone involved: #1333.
Is there a reason why this should be core and not an add-on in the asset library?
Making a document like this can help people realize that most of their feature and enhancements proposals can (or rather should) be implemented via modules, plugins, addons (it may not be the case now, but I hope that this can become a reality in the future). Having a clear set of criteria regarding core development philosophy can help people accept the way the engine chooses what features are essential to realize its vision (which may or may not be in alignment with each individual's vision), and save the time it takes to implement them for core.
It shouldn't be all about attracting contributors from all around the world and taking advantage of the work they do for free, it's about defining Godot's core values and giving correct expectations to people. This way, the Godot project will respect people's own values and expectations. Otherwise, I'm afraid that existing approach may backfire against Godot as a project, leading to division of community caused by conflict of interest rather than mutual understanding that not every problem can be solved by Godot Engine.
Keywords: ideology, philosophy, vision, mission, end goal, goals, non-goals, principles, purpose, direction, intention.
Describe the project you are working on
Goost - Godot Engine Extension. See my own philosophy at the Goost documentation. It's quite short, but it uses a language suitable to express these kind of things, not necessarily those which stem from pure logical reasoning, but also take into account human relationships/experience, and emotional states (something which Godot prefers not to talk about, the way I see it, despite welcoming various minorities).
It also uses estimations, because some things cannot be measured, but nonetheless, make it easier for everyone interested in contributing to make good judgements about the project, and most importantly, attempts to save the time it would take both the maintainers and potential contributors going into conflicts in the first place by giving alternatives.
Basically, anything which describes values, assumptions, beliefs, expectations etc. That said, most decisions are not governed by logic, despite what logic may say about this.
Update 2021: I got excluded from Godot Engine organization as a member for trying to clarify something that I was not even aware of as a contributor, see for instance godotengine/godot-docs#4799, or allegedly trying to quote core members to prove my point against them for the sake of it (which is not the case, all I'm doing is seeking truth/consensus via means of discussion), and I feel like any new willing and capable contributor may fall victim to this kind of circumstances at some point in time eventually.
It's not possible to reach consensus if this kind of ostracism, cancel culture, is used to manage members within Godot organization. The usage of the button is the demonstration of power, unfortunately.
I used to be a regular Godot Engine contributor, and even a member in this organization, because I've been implementing feature proposals as requested by other users, creating and maintaining custom modules and unit tests infrastructure in Godot, contributing features and enhancements I was personally interested in as well, but with various success rates.
Describe the problem or limitation you are having in your project
I recall my enthusiasm back in the days: https://github.com/godotengine/godot/pull/30816#issuecomment-515438218...
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.
When I first started making feature proposals in the form of pull requests years ago, my features were not met with much enthusiasm. Having acquired more experience as both a contributor and even a software developer, I have to admit that some of them seem silly by now such as godotengine/godot#19276.
But as I got my hands dirty, I started to contribute features which seem to meet both my own needs and the needs of others, such as godotengine/godot#28013. I then learnt that no amount of "thumbs up" can guarantee that the features get merged, but at least the good feeling you get from that seems to cover up the feeling of rejection, to some extent.
From what I've observed, it seems to me that a lot of people don't seem to get the ideology behind Godot development, or in fact it may have changed recently or rapidly evolving over those years, and I'm not sure how the work is really prioritized and what features are made into the engine. For some time I feel like the dedicated 2D engine is being neglected, and that's actually the reason why I've chosen the engine in the first place.
People coming from previous experience with Unity/UE4/etc. seem to request similar features to be available in Godot too, which may not be actually in alignment with Godot's intended core philosophy. Talking about not meeting expectations, which can lead to disappointment, for no good reason.
I see no formal document which could formalize the development ideology/philosophy behind Godot. We have documentation on how to contribute (talk first, make sure that the feature is needed etc). In general, those pages describe the "what" and "how", but not the "why". Start With Why.
There's even Godot's design philosophy but it doesn't really target the engine developers/contributors themselves with the purpose of giving a good direction towards how the engine should be like, and has only introductory/selling point value for those considering trying out the engine for the first time, not necessarily developing features.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Write an official documentation page or document which fully describes the development philosophy behind Godot Engine which would be mainly targeted at those wanting to make sure that their own development philosophy is in alignment with Godot Engine's one before considering contributing.
The most important questions which I'd like to be answered personally are:
Are we aiming for something like what other commercial engines provide, or is Godot becoming a Linux kernel but in the game development field instead (despite having a dedicated editor)? That's important because that signifies that a lot of current proposals should actually be targeted for module/plugin/addon development instead (hence the need for Godot Ideas repository: #1476). If that's the case (and it seems like the case, according to some classes already being removed from core in Godot 4.0, such as
InterpolatedCameragodotengine/godot#42113), this leads to the next question of whether Godot would be willing maintaining those features via plugins officially. If Godot's development is considered highly organic but aims to prevent bloat at the same time, then Godot should define things like Feature Removal Policy.If Godot can be seen as an open-source game development kernel, does it plan to provide a standard library distributed alongside Godot? Inspired by C++ STL, I'd personally see this being as Godot Standard Library (GSL), which would be written as GDScript, GDNative plugins and packages, and even C++ modules, such as the one I'm currently working on: Goost.
If Godot aims to further remove features from the engine to prevent bloat, would those features be actually maintained by the core developers? That would be actually the most important question to answer, because if those features won't be maintained on the same level as Godot core, the maintenance burden will lie on the shoulders of other (non-core) community members, and the amount of donations Godot currently receives would become quite disproportionate.
If the purpose and the intention is not clear, we'll keep accumulating feature and enhancements proposals which go against existing development ideology, making it more difficult to actually focus on those proposals which could benefit the engine in its current state.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
I think that Contributing and Godot's design philosophy pages might give some answers to this on some level, but I honestly feel like there should be a dedicated document which just translates what seems to be hidden gems inside the minds of geniuses in the form of text. I know it may be difficult to describe a particular way of thinking, but please consider this option. If the vision is not yet complete, lets call the document "The Future of Godot", because we all need to share the same vision to make the development process as smooth as possible for everyone involved: #1333.
Is there a reason why this should be core and not an add-on in the asset library?
Making a document like this can help people realize that most of their feature and enhancements proposals can (or rather should) be implemented via modules, plugins, addons (it may not be the case now, but I hope that this can become a reality in the future). Having a clear set of criteria regarding core development philosophy can help people accept the way the engine chooses what features are essential to realize its vision (which may or may not be in alignment with each individual's vision), and save the time it takes to implement them for core.
It shouldn't be all about attracting contributors from all around the world and taking advantage of the work they do for free, it's about defining Godot's core values and giving correct expectations to people. This way, the Godot project will respect people's own values and expectations. Otherwise, I'm afraid that existing approach may backfire against Godot as a project, leading to division of community caused by conflict of interest rather than mutual understanding that not every problem can be solved by Godot Engine.