Allow to discuss and present ideas freely for core and/or plugin development #47
Comments
|
Having a third repository makes it even more difficult to manage labels and permissions consistently, so I'm not sure about it. We'd also run into the issue of having people submit proposals and ideas to the wrong repositories. |
I don't think there is a need to label ideas at all.
This is an issue present in all repositories. We will never be able to fully avoid it. On the contrary, if we had an official Everyone who submits an idea has to have a Github account and come to https://github.com/godotengine: One click away from submitting a bug report or contributing to discussions. That's a low barrier of entry (unlike Regular users, less experienced users would have an official place to share and discuss ideas, small improvements of existing features, or missing features that are the reason they have not started a project in Godot yet. Advantages compared to a platform like Reddit:
|
I was thinking of having |
|
I too believe that this would be a good idea. The balance we need is a low-maintenance, official (and therefore, ideally GitHub-hosted) space in which to spark discussions on potential module/plugin/asset features. If, for example, someone opens a Proposal and they think it will be something that is needed to do in-engine, and then a contributor tells them that an EditorPlugin can do what they are requesting, then the Issue gets closed (potentially) and the case is closed. But the OP is still going to want a space in which to track the idea and discuss design/implementation with the community. The OP may not even be capable of implementing the idea they have, so they can't just keep it offline to themselves and just one day hope to find fellow interested users who DO have the ability to make it. I mean, they could do so on other websites, but GitHub IS "the social media" for tracking programming ideas amongst other programmers/designers. Reddit, Facebook, Discord, IRC, Pinterest, Instagram, Twitch, YouTube, and who-knows-what-else are not appropriate/effective platforms for having and maintaining such discussions (for several years potentially). If the Godot core contributors don't announce an official space for it, then the community will likely rally behind an unofficial one, still on GitHub, but it won't be as effective as if it were officially endorsed by the GitHub godotengine organization where the godot-proposals Issue template could directly refer people to it.
I agree with the others that we probably don't need to be as strict about managing labels on something like this. The point is having a space for non-contributors to have a more accessible place to share and discuss Godot ideas related to the engine at all (and maybe promote people within that group to be triagers if anyone expresses interest). The goal would be to remove all work from the main contributors team and give users a place to redirect their ideas to. So, something that is deemed suitable for a plugin may just have their Proposal moved to Ideas rather than closed outright, and people who already know an idea isn't suitable for the engine can just start there right off the bat.
If it is an official repository, then even the Proposal Issue template can be updated to recommend that ideas not matching the criteria go there instead. So if someone has the sense that they're suggestion is too lightweight, they can know where they should go. |
|
I've actually discussed this as an Issue before since there is no official place to discuss plans or designs around creating plugins for Godot (like blurrymind's Dragonbones integration or event stack visual scripting language concept). Previously, when someone opened an Issue in godotengine/godot with an idea for something, and that idea wasn't suitable for the engine, they would be met with tons of negative feedback about why they were even posting the idea, that it doesn't belong, etc. And the contributors are right in the sense that godotengine/godot really shouldn't be the place for that, but these kinds of things just don't have a space right now. Until there is one, you'll likely have a lot of frustrated content creators/users out there. That's where a lot of the negative feedback about the new GIP system is coming from, afaict. |
This actually explains why people tend to bypass discussing ideas in the first place and go straight towards implementation/PR so they can't be as easily rejected. Having a more welcoming place to discuss stuff would save a lot of unnecessary work in case the implementation is a plugin candidate. |
|
I think we also need repos where ideas will be buried and ignored by everyone. Jokes aside, currently almost all of contribution ideas go to "make gdnative" which is equivalent to "get lost". Because gdnative is bastard child and is quite unusable. It is much better to use your custom engine fork than gdnative, because at least your engine change will likely work on all platforms as long as you can compile the engine. Also it is much easier to use, no platform-specific files hanging around, no trouble building, everything was done for you and tested. As developers don't care much about gdnative, I consider the direction as "we don't want anything not made by us, do your own fork" motto. |
|
Perhaps the repository shouldn't be named as You might say that forums could be used for discussions. But as stated by @golddotasksquestions, GitHub has a lot more benefits for this, being able to cross-reference issues is my personal favorite 😛.
People tend to be guilty starting discussions, and no wonder. Trackers or TODO lists could also be created to gather related ideas and discussions together (notice these kind of issues would be forbidden with the current GIP process). There are more than 1650 open and closed issues labeled as |
Xrayez
changed the title
If GDNative is a "bastard child" and "quite unusable", then it's better to file bug reports about it than to complain. Tell the devs why and how. At the moment the problem with GDNative is its main developer has gone on to other things, so it needs someone who can take it over and work on it. I'm not sure it's fair to say that "developers don't care much about gdnative", though. |
I would feel less inclined to post under Posing an idea on If someone else later posts a very similar concept or idea the original poster can refer them to your issue (duplicate). Correlations and differences can be discussed. By placing an idea on the official Godot Github which contains THE SOURCE, it creates a minuscule sense of ownership. I'd already feel like as I am part of the project. The studios I work in had roughly 50 to 60 % of their employers working on smaller personal game projects - besides their full time employment. Producers, Artists, Coders, Designers, Audio, QA even people in HR. Industry wide, that's a huge number of potential Godot users who bring a lot of creativity and experience, even though their input might not meet the GIP standard yet. And that's just people who already work in the games industry. |
|
I made this "meme" and posted on Reddit, The process
|
|
I've updated/restructured/added some of the ideas in OP, so you know [edited]. 🙂 |
|
While I really like the idea of the proposals system and see it as a big improvement, I think there is a second great opportunity here. As mentioned earlier in this thread I think there is currently a big void between features being developed for core, and those being made as addons / gdnative / modules etc. The whole philosophy of Godot as far as I can see is to keep the core 'lean and mean' (if you'll excuse the windows analogy), and move as much of the functionality as possible into optional components (interpolated camera, cough). If that is the aim then we should surely try and move a little more towards treating the development of non-core features as first class citizens. I.e. if you make a proposal and it is deemed that it is better to be non-core, this should not be seen as a negative. After all, it should be seen as a success, that the core has been built in such a way as to make this possible. What would be great (although I don't know if possible) would be to have a parallel system for core proposals and non-core, and if something is deemed non-core, then the topic can be moved between the two (or vice versa), so that any discussion etc is not lost. Along with that I think there is potential for the more techy guys to streamline the solution for the rest of us for building GDnative and perhaps modules for different platforms. It should ideally be as easy to get something available via non-core as it is through core (or, even easier because the review process can be less stringent). Speaking as a developer, just as there is continuous integration scheme for the master branch, it would be nice to have an official CI for gdnative and perhaps modules too. So developers would periodically upload their latest stable version, and the official CI would churn out binaries, that any user could then download (from the IDE) and add to their local godot installation. Essentially most developers are more interested in programming than in running a bunch of builds for different platforms and faffing with distribution logistics. Well I know I am! 😄 |
|
Can't disagree, but moving features out of core is not architectural
decision, it is just resource management. So it is signal to "move out of
our sandbox"
and go elsewhere do your thing. So no, currently getting into core
feature-wise is very unlikely, so you have every opportunity do do
everything on your
own, which is out of sight, out of mind business. As everything which can't
be done out of core is "not needed in all games" too. So currently for any
contributor the best advice is not waste time but do your own engine fork.
You can be kind and make others easy to pool from you and make feature
branches. All bug fixes are generally upstreamed though.
So all features we can get currently are either made ourselves or by core
developers, we can't contribute features.
…On Tue, Sep 10, 2019 at 4:27 PM lawnjelly ***@***.***> wrote:
While I really like the idea of the proposals system and see it as a big
improvement, I think there is a second great opportunity here. As mentioned
earlier in this thread I think there is currently a big void between
features being developed for core, and those being made as addons /
gdnative / modules etc.
The whole philosophy of Godot as far as I can see is to keep the core
'lean and mean' (if you'll excuse the windows analogy), and move as much of
the functionality as possible into optional components (interpolated
camera, *cough*). If that is the aim then we should surely try and move a
little more towards treating the development of non-core features as first
class citizens. I.e. if you make a proposal and it is deemed that it is
better to be non-core, this should not be seen as a negative. After all, it
should be seen as a success, that the core has been built in such a way as
to make this possible.
What would be great (although I don't know if possible) would be to have a
parallel system for core proposals and non-core, and if something is deemed
non-core, then the topic can be moved between the two (or vice versa), so
that any discussion etc is not lost.
Along with that I think there is potential for the more techy guys to
streamline the solution for the rest of us for building GDnative and
perhaps modules for different platforms. It should ideally be as easy to
get something available via non-core as it is through core (or, even easier
because the review process can be less stringent).
Speaking as a developer, just as there is continuous integration scheme
for the master branch, it would be nice to have an official CI for gdnative
and perhaps modules too. So developers would periodically upload their
latest stable version, and the official CI would churn out binaries, that
any user could then download (from the IDE) and add to their local godot
installation. Essentially most developers are more interested in
programming than in running a bunch of builds for different platforms and
faffing with distribution logistics. Well I know I am! 😄
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#47?email_source=notifications&email_token=AAABPU6I33JN3DV2VEI2C23QI6OEDA5CNFSM4IUTFK6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6LCPBI#issuecomment-529934213>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAABPU3T2LEZNU7ZFPXVLOTQI6OEDANCNFSM4IUTFK6A>
.
|
|
@slapin I'm not really sure what you mean by your comments? People can contribute features. They do it to the engine's core ( Yes, I would agree that the fastest way for someone to do whatever they want with their code is to add it to their own fork of the engine (there's no approval process that way), but this Issue isn't targeted at the audience of people who only care about making their own stuff. It's about people who want to contribute features to the publicly accessible engine either by 1) adding a feature to the main engine repo or by 2) creating their own public repository with an addon/plugin/module. And the problem is that there is no official Godot tracker (like a GitHub repo with Issues) for keeping track of the second set of proposed changes (for people who make addon/plugin/module proposals but don't have the time/knowledge/experience/motivation to work on them - yet). This Issue is about establishing an official one, so, unless I'm mistaken in understanding what you said, I don't think you're comments were quite on topic. |
Or can make their own stuff. Many incredibly valuable improvement ideas, especially in the UI/UX department come from people who use the engine, but don't necessarily know how it works behind the curtains. Often these people even have a better idea what the software should do, because their perception is not tainted at all by the reasons why things are done one way or another. |
|
This is why I've always advocated for at least one centralized location. For example, the forum in 2014 or so (can't remember the exact date), but you'd instantly check it in the morning, or if you just randomly think about Godot / game dev stuff. It was the go-to place. Your topic could be seen not only by core developers, but contributors, fellow game devs, etc. It had a lot of different sections (scripts, tutorials, plugins). No upvote/downvote system, just a community where your Godot related ideas/topics could be seen and have an opportunity to flourish. That was really cool because it was like the hub for Godot. People can still do this now through the community channels (discord, godot dev forum, irc, etc, etc, etc). However, IMHO having that one "central hub" forum was ideal. I honestly believe more separating at this point is just not a good idea, we need more centralization! (if that's a word). That's why I was super excited to hear about the godot-proposals repo, and happy to see reduz posting about it on twitter / news announcement. |
|
@girng except that godot-proposals is specifically designed to filter out many of the ideas that would have been permitted to exist in something like Godot forums. That's kinda the point of this proposal. |
|
@willnationsdev Yeah, you are correct I misspoke at the end. I mean as an alternative to godot-ideas/godot-discussions And also
|
I don't want that either tbh, but seeing how restrictive the current process is now and my failed attempts to waive some of the restrictions in #39 I hardly see a better alternative (this proposal is made in a way to let you accept the other alternative in fact). So for now the only type of proposals I'd make are in fact those which would allow to introduce independent changes to Godot more easily (better module linking support, seamless GDNative infrastructure without having to write I learned that my needs are too specific to be even discussed. At the very least, these
So yeah, I'd change the title to this quote, but there are still ideas which are impossible to implement via plugin system and which could still be controversial. |
Xrayez
changed the title
|
@girng : Totally agree one place for everything would be ideal. However we have a vastly bigger and probably also more diverse userbase now compared to 2014. Since Github is also the place to report bugs, and submit proposals, I think it also should be the place to have serious discussions and flesh out ideas.
You are not the only one and I think that's a very problematic situation for the development of any editor, especially if it is open source.
So my point is we should encourage people to come out of their holes and communicate more, share their issues more. For this to happen we have to make sure every issue a user has, every concern is treated as relevant and important. The challenge should not be to prohibit the motivation to participate, but rather to channel the motivation users have to the right places. |
|
So are we doing this? What's the holdup. Who's the person who decides that this repo gets created or not or does somebody just have to do it? Who has the keys to this? Let's make it happen. |
|
@amisner2k it would have to be the godotengine organization admins who would have the GitHub authority to create new repositories affiliated with the organization (to get, say, a godotengine/godot-ideas URL). And it will probably have to wait for Akien and/or reduz to make a final call on it, perhaps after discussing on IRC with the other core devs (my guess). |
|
Cool cool......well if anything. Shouldn't hurt to create it and see how it goes. If for some reason it doesn't pan out it can always be deleted in the future. I just hate to see things die slow deaths with endless discussion. But yea, hopefully they see this and make it happen. I'm rootin' for ya, Will. :) |
|
Keep in mind, before further steps are taken, there would have to be consensus on the issue. Additionally, for this issue - in my opinion - there also needs to be more concrete decisions on how the alternative repo gets managed and moderated. Currently a handful of people put in an incredible amount of work to barely manage the current issues (Keep in mind we are currently failing). So any new system on top of the current one needs to reduce the workload of contributors not add to it. In my opinion that hurdle needs to be solved before creating a new repo. Not after. |
|
Everything I've heard so far about this is that it wouldn't require much if any workload of contributors to "manage". It also seems to be designed to reduce the number of issues in the main repo so that they can instead be dumped in this "ideas" repo. That's my understanding anyway, feel free to correct me if I'm wrong. |
|
@amisner2k We can't just invite the public onto a platform hosted by us and then just throw up our hands and avoid it. First of all, the content has to be moderated for spam, hate content, etc. Second, in order to be used, someone has to determine which issues are worth opening a proposal over. Third, very quickly we will reach thousands of suggestions, at that point it will be nearly impossible for users to find duplicates, accordingly many more duplicates arise which will inhibit productive discussion. This third problem will continue growing indefinitely (as it is now in the main repo). Just asserting that something won't add to the workload of contributors doesn't make it so. Many users also think that maintaining the current issue list is low-effort when in fact many people spend many hours a day just to keep it at its current level of organization. Lastly, and I know this doesn't go to your point. But I still don't understand the benefit of having this in a repository. Godot isn't suffering from a lack of half-baked ideas right now, in fact, we are drowning in them. We have no clear way of distinguishing good from bad ideas right now. Godot-proposals solves that problem, it cuts off half-baked ideas at the source. This proposal seeks to bring back all the low-quality proposals for same ill-defined gain. |
|
@Zireael07 I had initially created the Godot Extended Libraries organization targeted at that purpose, but I think repurposing that concept to a more generic organization, not targeted at just plugins, is a good idea. I have yet to move godot-next to GEL yet even though there is a discord for GEL. We should definitely create that organization. We can then start inviting people to the organization and large-scale migrating plugins to that organization. Edit: should I just rename the GEL organization and start inviting folks to it? |
|
Here's the icon we made for the Godot Extended Libraries organization. Feel free to use it if you want. The idea was to be a spellbook of some sort: recipes for executing magic (libraries and all).
|
|
@willnationsdev I think this makes perfect sense, you've contributed a fair share of stuff to Godot community-wise and you've already set it up, I could simply transfer |
|
@Xrayez Here ya go! https://github.com/godot-community Edit: Oh, whoops. Followed the |
|
Now, I don't wanna have to be the only "moderator" for the community, so if there is someone who wants to be super extra responsible and not horribly mess with other people's code in the repo.....now's the time to volunteer. lol |
Might be better as it's non-official in fact. Transferred just fine I think: https://github.com/godot-community/godot-ideas |
|
Given all this, I think that if we update the I think this Proposal is more or less closeable at this point. |
|
Yeah, lets see how it goes though so that maybe some |
|
Also, if successful we can link to it into the community channels doc and on the readme here. :) |
As been discussed in godotengine/godot-proposals#47, it seems logical to break down ideas which might be: * Core candidate * Module candidate (C++, close to core) * Plugin candidate (GDScript or GDNative) So respective labels and badges added in README.
|
This is amazing you guys! I love the solution you all came up with. I love what you guys are doing here. |
|
@Calinou Is there any hope of creating a reference to |
|
In the interest of avoiding any confusion with official godotengine channels, I have renamed the organization back to |
|
Updated As for renaming, "community" stands for "users" and "engine" mostly stands for "developers", so I'm not sure what other name could be chosen for this... @akien-mga and @reduz should really make the final call then, but there's clearly an issue for me here (and some others here), the reason why I started to discuss this early is to prevent users to become discouraged with the process, so I have the best intention, sorry if I've created any impression of hostility here, peace. |
|
@Xrayez I think it's too soon to do anything, and we haven't even tested the new system because @akien-mga was on vacation. We will have enough time to see how it works and how we can adjust it over time so most can be satisfied, so I feel that all this is an overreaction at the moment. Let's see how things work first and what can be improved before discussing any speculation about shortcomings. If you want to do your own system in parallel feel free to do it, but it won't be official, so it won't need any need official approval. |
|
The hard line of conflict will probably always be the dismissal of proposals that don't have user interest, or any practical use in existing projects (even if they sound cool), and this won't change because we want to avoid bloating Godot with stuff no one will use. That said, and as others mentioned, we are a lot more open on feedback for improving external plugin support, including the plugin API and GDNative C++ so extending as outside plugins is easier (it's kind of a hassle for a lot of things). You feedback for these kind of features that are on a gray area will be a lot more interesting if it's about improving plugin API development so they can actually be implemented externally. |
|
@reduz my overreaction is mandated by the survivorship bias which could be quite real here. People who want to make a proposal which doesn't match up to the standard/requirements could just decide to close the tab because most don't have any authority nor influence to suggest an alternative. And those who do notice potential problem would remain in minor group, so one could make a logical error that the issue is not really there nor it is objective enough to allow any changes to be made. I think discussing this won't hurt anything. No actions are needed for now indeed, let the system be tested, I go idle mode. Sorry for making it appear too serious of a problem. 🙂 |
|
@Xrayez Yes, but then again, all you have to do is explain how it would be of use to you in a real-life project. I think it's a fair requirement. |
|
Your only "risk" is basically a situation where:
This is a too corner case situation, and a terrible criteria for adding new features. If we accepted this kind of thinking, the project would quickly bloat with useless features for the sake of having maybe a very few amount of them that were useful. It's just not worth it. It just works much better the other way, when you find a real-life obstacle and can describe it, then you or the the community can work together and think of ways to overcome it. Our mission is about making something useful for others based on their real needs, not having fun adding features that we find cool, that no one currenty needs, so that may nor may not be useful. |
I think we all agree that godotengine/godot and godotengine/godot-proposals shouldn't be cluttered with such Issues.
I can personally see how devoting manpower to Issues with such vague usefulness could be viewed this way. It might lead to like-minded people finding each other. They might discuss it in depth. They might actually build something out of the idea. It might end up solving some kind of problem in the future. It's all so nebulous.
I agree wholeheartedly with these statements. Which is why I still think we have a gaping hole in our Issues at the moment. In particular, we do not have a proper tracker for issues where the submitter...
Examples include...
These entire categories of ideas don't belong in godotengine/godot because they aren't bug reports and don't belong in godotengine/godot-proposals because they aren't necessarily feature requests or enhancements for the core engine repository. Having a GitHub repo allows us to fully transfer away all issues in /godot that are more suitable for addons (like the Dragonbones plugin stuff that was recently closed). This is why GitHub is preferable over Godot forums and the like. A good example is #13. It would be convenient to have it built into the engine, sure. But if we decide it shouldn't go in the engine, then I suddenly have no prescribed place on GitHub to track the idea. This is where The godotengine organization could host something of that sort, but @Calinou suggests otherwise:
As such, I thought it better to have a separate organization that doesn't have an expectation of core dev maintenance and which has a separate "ideas" repo especially for tracking such things. Edit: if I'm wrong, and people do want such an ideas repo in the godotengine organization, then that would obviously be preferable. I could also see it being easier to preclude unnecessary Issues in /godot-proposals if 1) the addon/module/project ideas repo existed and 2) the /godot-proposals issue template referred people with plugin ideas there specifically. |
To summarizeThe expectation that the new GIP would be simply a separate place for discussing and proposing features is not met (at least for me). Instead, a new set of restrictions is added with an intent that the place doesn't become cluttered, promote high-quality proposals which are easier to maintain and review by the Godot Engine members (for a lot this is also a volunteer/unpaid work). Based on the feedback so far, I think it's very unlikely for something akin to We see how some people still ignore the proposal template, or fill out questions just because they're required to fill, so the quality of most current proposals is still quite low. Having said that, I think it would be good if users could choose whether they just want to share an idea which is "nice-to-have" and propose a feature which is "need-to-have", so please consider adding a link to unofficial The system needs more testing, the discussion is quite controversial and this particular meta proposal can be closed for now. Still open for discussion though. 🙂 |
|
i think this is pretty lame, i could use something like this, i had some pretty general \ broad feedback, and it was all closed away, it kinda puts me off from honestly bringing up any suggestions anymore, and i know how valuable feedback is, from a person who has used a piece of software, for the very first time, but i find it pretty dissapointing, when some of my thoughts get tucked away, while i see the leads, or other people, being able to freely share their thoughts, and to not have their ideas hidden away somewhere i think it's a shame, because godot has a ton of minor usability problems, which i've spotted
i was even going to propose, renaming the "spatial" stuff to 3D, and a whole other buncha things, but i guess realistically there's no real interest in that, from the most experienced users, whch is kinda dissapointing i've decided to just, gather up all these ideas, and i'll keep them to myself, and if one day i become experienced enough, i'll just apply the changes to godot myself if i can i mostly end up feeling like nobody takes me seriously, and honestly this is why i'm not a fan of open source communities - sure, the source code might be open, but most of the time people do seem a bit close minded, and i see a lot of elitism pop up whenever more major projects start to grow i think godot is cool, but it's not as accessible or as open as it could be, it kinda pushes me off away personally anyway |
Actually, reduz proposed exactly that not too long ago. And I believe that if you'd opened an Issue mentioning that suggestion, it's very likely it would have been received in a similar vein.
To each their own, but I always encourage people to share ideas. While some may be rejected, there is every possibility that some will be accepted. The more experience you get in understanding the project's requirements/goals, the more likely it is that suggestions will be accepted. And getting that experience takes time.
I have never known anyone on the Godot dev team to not take a proposal seriously. What I have seen is developers accepting or rejecting proposals based on their quality level and/or suitability for the engine repository. Of course, without me reviewing your past submissions, I can't really comment on this point effectively.
From what I have observed at least, most accusations of elitism I have seen appear to be misinterpretations of comments, like core devs > contributors or contributors > users. However, every time I see this happening, it is because the contributors in question simply understand the requirements of the engine repository better, and so their arguments are better grounded in the project goals. If a user likewise made suggestions that matched well with the project goals, then they would be equally valued. That is, the perceived elitism/favoritism seems to be a result of those people having a better awareness of the project overall, not because they're subjectively better somehow.
I'm sorry to hear that. I say all this only because I believe that everyone can eventually form effective suggestions as they improve their understanding of the project goals, including you (course, I say that without having examined your submission history, so take as you will). I myself have had huge amounts of work done and rejected, along with many ideas thrown out. But over the past 3-4 years of contributing, I've gradually gotten better at understanding things and forming better suggestions. And I'm constantly learning/improving in this regard. No one instantly gets that experience. Some people gain that experience faster than others, or can even pull in development experience in other fields to bolster their ability to pick up Godot's project design. Anyway, take this as you will. I'm just a random contributor voicing his thoughts. :-) I look forward to seeing you around, whenever. |
So far I've noticed a certain spectrum to this:
The proposal is only relevant if it adds something in a way that most people don't see/realize yet and which would elicit the "aha" moment for many (effectively being in the middle of the proposal spectrum) but:
which, depending on how you're likely to contribute to open-source projects, makes the whole proposal spectrum useless. This is why GIP process needs to be more open-minded, and/or needs better plugin/module/gdnative support (and better advertisement of it), so that people are less likely to derail/branch off like that. |
The bar is too high just to spark ideas here
Continuing an off-topic discussion from #39 (comment).
Note: I'm personally against segregation but there seems to be no consensus with maintainers so I'm just seeking alternatives.
Example repository
godot-ideas
It mimics the process of
godot-proposalswithout too much restrictions, and users are pointed to this repository if they feel like they could get approval from core developers, else it would be a nice place to discuss stuff without imposing too much rules.Problem
We've established previously that proposals could be classified as:
The "Nice-to-have" type of proposals, based on the official guide and feedback, are going to be closed eventually without them being considered for review, because allegedly they don't fulfill the actual needs and fix problems that users are dealing with on day-to-day basis.
While I completely understand the amount of "low-quality" proposals that are going to spawn if we waive the restriction of having to fill out every single question, the need to express ideas and be heard still exists, and we'd rather avoid dealing with frustrated users.
The listed community channels aren't as functional or reliable as they could be, see #47 (comment).
Human factor 🙂
I guess people wouldn't like their proposals to be "closed" even if they can be reopened by maintainers if deemed satisfactory or needed, there's enough of examples how this makes people discouraged and rather frustrated.
The feeling of guilt that people feel starting random and general-purpose discussions by having to type "wall of text" Problems with preventing "engine bloat" and the AssetLibrary godot#19486. This can be avoided with dedicated place for that.
Proposal
There should be an official repository for people to allow to discuss their ideas there. Maintainers are free to "ignore" these ideas so they don't really have to put much effort by having to read and understand them. Don't feel like users are demanding you to make it happen. Moreover, such repository would be a place for people to ask the questions like:
godot-proposals?Controversial topics would be a perfect fit for this.
Such repository wouldn't necessary be targeted for Godot core, but a place for people to kind of request independent developers to write modules/plugins for them, but it needs to be centralized. An author is free to open and close an issue on his own.
Also see alternative approach/reasoning in #47 (comment).
A list of proposals with mentioned issues or criteria
(if not relevant, see first edits in mentioned issues)
The text was updated successfully, but these errors were encountered: