Improve communication by sharing high-level overviews of broad goals/engine direction in an accessible manner.

[lander-vr]

Describe the project you are working on

I'd like to offer some insights from the perspective of someone who's not deeply involved in engine contribution, as someone who has been around in Blenders ecosystem for quite a long time, has seen Blender grow as a user, and as a freelance artist with experience in indie and in AAA. My motivation to write this comes from the recent discussions taking place in https://github.com/godotengine/godot/issues/75440, however, this has been on my mind for some time now.

Describe the problem or limitation you are having in your project

I believe that that discussion, along with earlier discussions that have appeared on a variety of platforms, is appropriate evidence that there is not an insignificant amount of misunderstanding between users and the direction of development. I can imagine that for folks deeply involved in development it might be easy to forget that it is very difficult for average users to build reasonable and realistic expectations regarding what the current engine direction is. Most "regular" users are not contributors or folks wading through the depths of GitHub, and besides GitHub not providing a great high-level overview, most users (Including myself) don't have the appropriate knowledge or experience in developing a project like Godot to deduce what is important and what is not as important for the larger scope: Most folks using the engine are game developers and not engine developers. Given there is not an abundance of official articles providing overview regarding current priorities and goals, this makes it very difficult for regular users to keep track of current priorities and goals.

Clay's rendering priorities articles on Godot's blog page are exemplary in my opinion, and it would be great for users to be able to refer to similar articles made with broad priorities in mind instead of specific features. When particular priorities or needs are identified by the core team, and it is decided that there will be a response to those needs, a periodic article broadly describing these needs and priorities make sense. Be it based on version/release, yearly, quarterly, random..., but occasional as opposed to rare, trying to ensure there is information relevant to today. I understand the needs from the community don't shift from one minute to another, which is why doing a set periodic update might be a good way to occasionally re-evaluate and communicate current priorities.

Blender has done this as well throughout the years to different extends, serving to provide a broad overview to average users over the current state of the software, and in which areas users can expect improvements in the relatively near-term, without serving as a strict internal planning tool. But also through other channels like Pablo Dobarro's Blender Today livestreams (Of which clips regarding updates of particular features were also shared regularly), which allowed accessible direct interaction for users/non-contributors to keep up to date and ask questions. And also through developments that were guided by projects from the Blender Studio, of which occasional updates are also shared. Some examples: https://code.blender.org/2013/06/blender-roadmap-2-7-2-8-and-beyond/ https://code.blender.org/2021/10/blender-3-x-roadmap/ https://www.blender.org/development/projects-to-look-forward-to-in-2023/ https://www.blender.org/development/projects-to-look-forward-in-2024/

Godot has provided information like this in the past, but from the perspective of a user of the engine it seems far too rare, and I currently can't seem to find an article or official statement relevant today that offers information about which current direction is being taken or which needs are being responded to. Most of Godot's articles, except for Clay's rendering priorities, seem to primarily state what has been done, not priorities for a future release.

The latest article I can find talking about direction for a particular release is from November 2022, prior to the 4.0 release, where it was stated 4.1 would focus on stability, performance, and usability: https://godotengine.org/article/release-management-4-0-and-beyond/ I haven't been able to find information about goals for 4.2, 4.3, or what will be the overall aim of 4.4.

I'm not saying the following is the case, I'm sure internally there are broad goals kept in mind for releases (Illustrated by Juan's comment I quote in the next bit), but from an outside perspective this makes it look like there's no or little internal direction.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

https://github.com/godotengine/godot/issues/75440#issuecomment-2007382229 @reduz

The problem is that, currently, the main focus is improve performance and loading times, reducing stutter, improving shader compilation times, improving the mobile renderer, getting the engine to run properly on Apple devices, etc, as well as implementing more basic features that are needed. ... Once all this happens (I hope during this year) it will be much more feasible to work on higher end rendering features. I hope you understand right now there are more pressing things that have to be solved.

That, in my opinion, is exactly what should be shared in a more direct and distinct manner (i.e. through Godot blog posts): Broad high-level goals and overall project direction with some minor clarification, whether it's about technical matters, community, project management, etc..., accessible outside of GitHub.

Not meant as specific feature promises (I understand that's difficult to do in OSS) but giving users an idea of where priorities are being set at the moment.

This would allow average users to temper and guide their expectations, provide the opportunity for people both inside and outside the Godot community to easily keep track of where the engine is headed, and potentially be an opportunity to steer contributions. I would imagine more communication regarding engine direction, besides leading to more informed users, would also lead to more folks and studios interested in adapting and investing in the engine, simply because they can see where priorities lay.

I think both the community, engine developers, and Godot itself would greatly benefit from everyone being more on the same page. I would love to hear what others think about this proposal, and hope it can be discussed in good faith.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

/

If this enhancement will not be used often, can it be worked around with a few lines of script?

/

Is there a reason why this should be core and not an add-on in the asset library?

/

[WickedInsignia]

Thanks so much for this write-up! Hopefully this will be treated better and considered more thoughtfully than my own (which was admittedly very direct, but also what I considered to be very necessary). Communication like this is essential to maintaining contributor morale and as a reference point for developers who depend on Godot for their projects. Keeping users and contributors in the dark leads to dissonant development efforts or users that have no confidence in the engine meeting their needs. Users feeling that Godot is generally directionless is a criticism I've come across often.

Very glad that you've taken the time to continue this important topic! I've enjoyed your spatial audio videos in the past too, they're quite lovely.

[MilesFarber]

Palworld will never be ported to Godot.

[yosoyfreeman]

Palworld will never be ported to Godot.

This is by far the most disconcerting comment i seen in the history of Github.

[coppolaemilio]

Thank you for the proposal. I just want to say that this is already in the works. We started working on getting it done before this proposal was opened, and we are still working on it. I don't know which final form it will take when public, but it is something I'm personally looking forward to see.

Clay's rendering priorities articles on Godot's blog page are exemplary in my opinion, and it would be great for users to be able to refer to similar articles made with broad priorities in mind instead of specific features.

The goal with these articles was the middle ground we found to give that sort of visibility without making a complete roadmap of the project. Having the people in each area making a priorities post would give them more agency in how it got communicated to users. Unfortunately, not everyone was eager to write a blog post, and many areas didn't have anyone leading them full-time, so in the end, we only had Clay's posts. It is hard to get volunteers to commit a lot of time writing reports/articles and many of them grew reluctant to publicly promote what they were working on because they were getting harassed when priorities changed.

I'm not saying the following is the case, I'm sure internally there are broad goals kept in mind for releases ... but from an outside perspective this makes it look like there's no or little internal direction.

Yes. We do have many internal trackers, projects, and roadmaps that we use to follow the development of Godot, but they are only available to maintainers. As I wrote before, we are working on making a public facing roadmap that will help people to understand what we would like to work on.

This would allow average users to temper and guide their expectations, provide the opportunity for people both inside and outside the Godot community to easily keep track of where the engine is headed, and potentially be an opportunity to steer contributions. I would imagine more communication regarding engine direction, besides leading to more informed users, would also lead to more folks and studios interested in adapting and investing in the engine, simply because they can see where priorities lay.

You hit the nail on the head here. This is the biggest benefit of having such roadmap visible, and that's why we should make it. It is just a bit more complicated than it looks from the outside. At the Foundation we are still a very small team, and there are many moving pieces that are outside of our control. Thanks to the increased donations we were able to hire more people with better skills to handle this sort of tasks and leave maintainers working on what the enjoy the most.

A roadmap is something I always advocated for. With how we are structuring things now, and by having more people on board with the idea, I think we will be able to finally have one soon™.

[lander-vr]

I just want to say that this is already in the works.

I'm super excited to hear this, and I'm looking forwards to it!

they were getting harassed when priorities changed.

It is appalling that this is something that has happened, and completely understandable that this has put off maintainers from writing articles.

It seems like it might be a good idea to, regardless of which form or shape these updates will take, make sure the information shared is not directly linked to particular maintainers. Looking back to Blenders examples I linked in my proposal, they are authored by one person (Usually Ton), covering planned improvements in various domains, without specifying who will be working on what, keeping it to concise high-level whats and whys.

Thanks for the insights, Emi. I suppose I'll keep my proposal open for the time being in case anyone has any additional thoughts or ideas they'd like to share regarding this topic.