Feature requests and their priority

Feature requests
#1

There has recently been an increase in the number of feature request posts. I think it’s great and it’s a sign that a lot Defold users are actively using Defold to create games and while doing so they come across things that are missing or could be improved. This is really one of the major reasons for releasing Defold to the public. We need and we want your feedback to make Defold an even greater product than it already is. The potentially negative thing about this increase in feature requests is one of quality and bandwidth:

For any area of the Defold engine you can probably come up with a hundred different improvements, small and big, critical and unimportant, and it is highly unlikely that all of them would ever be implemented. Not only would it bloat the engine and the APIs (which is something we take very seriously) but it would also require a huge team of developers. And to be honest, that is a team which we don’t have and which we don’t want either. We have a fairly small team of hugely skilled and motivated engine and editor developers and I am constantly amazed by the amount of things and the quality of what we deliver!

Additionally I think it is important to know a little bit about how the engine team is working. The team is working in two week iterations (or sprints as we call them) and plan their work in these two week chunks. Before the beginning of each sprint we have a planning and estimation meeting where new things in the backlog are given a priority and an estimate (and as you might already know, things are added to the backlog as a result of feature request made here on the forum, by teams within King and through meetings that @Oleg_The_Evangelist and others have with our users at game jams and conferences). Bugs and missing features without reasonable workarounds that block teams from delivering great games will be given a higher priority than issues and features with workarounds or things that are only “nice to have”. Based on the estimates and the given priorities of the things in the backlog a certain number of tasks are planned for the coming two weeks. We also keep a list of smaller tasks and “quick wins” that team members can pick up in-between the planned tasks if time permits. This ensures that smaller and perhaps minor things get done as well. Finally, at the end of each sprint we do a new release of the engine and the whole process begins again.

So why am I writing all of this? What I’m trying to convey is some kind of expectation management. I can promise you that we will consider each and every feature request that is posted here on the forum and we will assign those that make sense a ticket in our backlog. What I cannot promise you is that we will be able to deliver all of the requested features at once (or ever), for reasons described above. I hope this makes sense to you and that it gives you a little bit more information about the process involved when making a feature request here on the forum.

13 Likes
#2
#3

Will there ever be any form of public road-map or insight onto the aims and goals for each sprint so individuals and teams working with Defold on their projects have a better idea of when to expect certain things?

If something is missing from the engine, and people then spend a lot of their time designing and implementing a work-around, only to find that you guys were working on the solution behind the scenes, then that’s time that could be better spent somewhere else. On the reverse, if people are holding off on a part of a project because the tools and support they need don’t exist yet, but have been hinted at being somewhere on the list, it’d be nice to have some kind of time-frame on that, or any kind of input on if that specific thing is likely to be worked on soon or a workaround should be prioritized.

Thanks. Keep up the good work!

1 Like
#4

We have promised more transparency when it comes to coming engine releases but it has proved harder than we initially thought to find a solution that shares enough information with you guys and at the same time does not promise too much. There is always a risk when you make a backlog of items public that some people take that as a firm promise of something being implemented at a certain date only to get disappointed when the feature they’ve been waiting for gets delayed due to unforeseen delays in the implementation or changes in priority. I think @Oleg_The_Evangelist, @saracederberg and @Axel can tell you a bit more about the current state of the public roadmap.

#5

On the main hand, I agree with you and understand that problem. On the other, I feel the audience Defold attracts contains a stronger concentration of programmers and people with technical understanding, who would have at least a base idea of how these workflows tend to work out. Feel free to contest that if I’ve got the wrong idea!

Would the advantages of having the internal Jira tracker available publicly on some level not out-weight the negatives? Users would be able to provide more specific case-information for issues that might be unknowingly lacking, or provide input or easier/more elegant solutions on things that have been slid onto the backlog because of their difficulty.

If you just placed a disclaimer on the tracker that implies the volatile nature of the workflow, stating that all things are subject to change and people shouldn’t rely on it as a solid road-map, that would be enough for most people. There will always be people who blunder past and assume too much, regardless of what you do.

It works well for a lot of other projects like this. :slight_smile:

#6

I agree with that~
If not everything can be made public, it could at least be made easier to see which of the DEFs in forums are in development.
Also, I think pools could probably solve/help with the amount of user requests.
something like a monthly pool where ppl submit their ideas and people vote on the best ones, those would go to the “to be developed” list and the rest could be just forgotten, not logged or anything, I think you guy’s might be getting overloaded with requests because most of them are actually being filled;

#7

While an interesting idea, I’m not sure I entirely agree with the monthly-pool voting thing. I feel the Defold team have a good workflow already and mixing that up with just slow things down even more. That’s just my two cents on that part though.

#8

The internal Jira tracker contains information on current and upcoming King products. We cannot expose that. But we see the problem here. The current tagging of forum posts with the DEF ticket is barebones and we’re looking for better solutions - ones that work with our workflow.

#9

Is there no way to segregate the issues related to Defold, and just expose those? Or migrate the issues to a public tracker rather than the shared King one?

#10

The problem is that these are Defold issues. Like “In XXXXX when you YYYY the engine does ZZZZZ”.

1 Like
#11

Ah I see, that does complicate things.

#12

Yes. The Editor 2 team will try a public issue tracker for their stuff. Maybe we can get that to work with internal stuff as well.

1 Like
#13

Yeah, kind of! It’s been a highly requested feature for a while now – and while the difficulties of publishing a public roadmap have already been mentioned above, we’re working and hoping to release a satisfactory interim solution in the near future, with the hope that we in the future can figure out a way to separate King-specific issues from ‘normal’ issues. We want this as much as you guys, for reasons @britzl and others have already stated. Until then – thanks for the patience. And have a great Friday, all’y’all’s!

3 Likes