Post

Why do submissions get ignored? Volume of submissions is just too high. Answering properly takes a lot of time. Some contributors can’t take a no, no matter how polite. It’s a stressful situation for everyone.

This organically leads to shiny proposals with barely any use, drama discussions, and endlessly open PRs that will never get merged no matter how much they are worked on.

How can you help? Understand this rationale. Think about whether it’s useful now, rather than in the future. Think like a Godot developer.

Introducing an idea: Feature Scoring, to rate a feature to measure if it should be merged or not. Measuring would be on a CRIS score. Complexity, Reach, Impediment, Stakeholder.

Example of symbol refactor: Complexity went from 0.1 to 0.9 by a suggestion to make it easier to implement. This would make it score much higher.

Why do this? What would it fix? Have an objective method for reviewing. Help submitters understand why they get accepted or ignored. Give definitively answers to requests. Project staff from harassment from those who can’t take feedback.

I asked: What about feature requests for things that would create new users of Godot that do not yet exist? The reach may be users who aren’t there yet, the impediment is those users are not there yet at all, and the stakeholder cannot exist as those users are not there yet.

Answer: Yes, but we ran into this with visual scripting. People kept asking for a ‘Blueprint like’ node system, it was built, and then nobody used it, so it was removed again in 4.0 So their experience has been to not just build things that “would add new users”, but instead service existing users.

0 reposts8 likes

This was something that was contributing to my desire to try Godot for a personal project a while ago. It's probably smart for Godot, at least right now, to make+maintain what is needed rather than what isn't (currently) used. They can always add this stuff later when the value/cost changes.

by all accounts (including their own at the time) it was more that they set out to do a blueprint-like node system and did not successfully do it because they didn't really understand the task, so they wisely stopped wasting their time

The problem with visual scripting, is it is incredibly segmented. New users might use it but existing ones don't, which is bad for gaining traction. You need a lot of outreach effort. They are missing things that empower existing users AND unblock new users.

Godot is - both by necessity due to a tiny dev team and by choice due to a very disciplined dev process - very rigorous with its features. Blueprints were a large and labor-intensive feature that was not seeing user takeup to justify maintenance, and was seen as better served by a 3rd-party plugin.

Worth mentioning that this was done during the development of v4.0, which was an almost ground-up rewrite - so keeping blueprints wasn't just a matter of leaving them be, it would have required active effort to reimplement in the new engine. A number of features got axed in 4.0 for the same reason.

(Personally I worry this creates an echo chamber that eventually solidifies into concrete barriers where progress isn’t possible because only what currently exists is allowed. Blender had this same issue until they finally relented and did a UX pass that then skyrocketed their userbase)

I wasn't at the Godot Engine conference presentation, but I can imagine how Godot Engine CRIS tries to focus research and development energy from frontier technologies to the improvement of existing features.

Like Godot Engine CRIS ranking tries to fix the foundational stack of existing features vs improving frontier technologies.