If you only work on big name features and long term bugs you’ll end up with a featureful but bug riddled product where the core flows work well but people don’t want to touch anything off the beaten path with a 10 foot pole.
If you only work on fixing all the small easy bugfixes as they come in, you’ll have a generally solid product but with some big blind spots / deficiencies.
The best approach is to do a mix of both. Our current threshold is that we aim to fix at least 80% of the new bug reports that come in from the community.
Most of the bugs reported in bug reports are not fixed.
People complain about pathfinding service and humanoid a lot. The path parameters dont work and this is something that have been like that since its release
It can look like that, but that’s because most bug reports get fixed fairly quickly and fall off the front page of the bug reports section once they’re marked as resolved.
Some bugs are harder and can’t be fixed right away because they need to wait for architectural changes, or are long term bugs that may be hard to fix period because people have started relying on the broken behavior as the new expected behavior. Those are the ones that stick around and come up repeatedly on the front page of bug reports.
Letting people get used to broken behaviour is not a good card for engineers. People are hoping to get the big heavy bugs fixed because that is what prevent us from making games. I had times when i almost quit roblox developing just because of some bugs. and the way engineers just find some bugs too hard to fix is a big issue. How cant a multibillion dollar company Get major noticable bugs fixed?
Say that we’re rewriting the internals of the Humanoid and plan to have the changes released within 6 months. Now someone reports a bug with the humanoid.
We know that this bug will be resolved with the new version of the code. We could fix the bug in the old version of the code too but we could also just wait 6 months and have it fixed for free.
Fixing the bug in the old code would effectively be taking away time from other potential bugfixes that wouldn’t otherwise be resolved. The cost of waiting of course being that the bug will remain broken for longer. It’s a tradeoff.
That’s currently the case for the Explorer pane for example. We’re in the process of rewriting it as a Lua plugin, so some of the less severe bugs with it that otherwise might get fixed are being left unfixed for the time being since they’ll be resolved anyways by the rewrite. Though if severe problems show up with it we still have to fix those right away regardless.
When Engineers have a plan to do a massive change, then someone reports a bug, then the best thing to do is to notify the reporter about that big update plan and that their bug is going to be fixed in that big change.
The issue is when engineers dont give any information about upcoming humanoid/any service changes. there are no info about anything so people keep giving the same bugs thinking engineers dont know it/ignore it.
Simple way to say something like “We are doing a massive change and rewriting the internals of the humanoid. The rewritting will be released within 6 months, your bug might be solved there.”
Otherwise people will give the same report.
Also some major bugs exist for years and are not being talked about in updates.
Unfortunately it’s not always that simple. For example, there may be speculative work on a rewrite of something but where we’re not 100% sure that the rewrite will pan out, or work may not have started yet and priorities might shift, or maybe it will end up taking much more than 6 months for some reason.
Especially for hot-button topics it’s problematic to promise timelines / action unless we’re very confident that we can stick to the promise. If you see a long term high profile bug report with no response it’s likely the case that the situation around the bug is complicated in such a way where there’s no clear response to give.
I mean how could engineers not priorotize main bugs since it affects more developers. Not everything is quick fix i understand, but still something being hard is not a reason to give up on solving it. I mean engineers should have full control and knowledge on the ROBLOX internal code and be able to 100% know what they are doing and how to solve it.
Do roblox engineers priorotize easy fixes over hard fixes?
There are enough hard bugs existing in the engine and Studio that we could never solve every single thing that could be considered a bug even if we spent literally all the time working on bugs and no time on new features. So prioritization is a necessity.
It’s not so much about prioritizing one over the other, rather they get fixed in different ways. “Hard” fixes are usually hard because as described above, they require re-architecture. They do get solved, but normally not as one-off bug fixes, rather as part of larger code restructuring efforts which fix many known problems with that part of the codebase at once.
I’m experiencing a lot of problems and it’s quite difficult to edit my games in studio, like I can’t properly select things in explorer the way I usually do (ctrl + click), other random objects I’ve selected before get selected
Also issues with pasting sounds, packages not refreshing and etc.
If you guys are working on new explorer then at least have it roll out within a beta feature
See if that’s fixed now, we literally just rolled out something that may fix what you’re seeing there.
There’s a fix for that which should be out early next week.
It certainly will be, there’s no way we could transition something as important as the Explorer without some initial bugs we will need a beta to work through
I’m not sure how frequently this may occur, but I do feel like if it’s this early in to larger changes, it shouldn’t block fixing issues occurring in production.
I understand timelines adjusting and avoiding promising, these things are always difficult.
If a “priorities may change” situation occurs, I just hope the bug report isn’t still being dismissed because of prior speculative plans that were put aside.
It often doesn’t. It’s a sliding scale, depending on impact, difficulty, how far out a fix is, etc. If it’s an actual regression (an interaction which did work before broke) it’s likely to be fixed regardless, almost certainly if it impacts live experiences.
Most of what we’re talking about here is the grey area of stuff that never worked correctly in the first place or is still working like it did but doesn’t interact correctly with a new feature which has since been added.
There is an example and it’s not being noticed for 3 months even though it’s constantly on top of the page, it impacts everyone greatly and is definitely easy to fix
I reported this issue half a year ago with scrollbar cutting off text in text chat service new chat, this is the simplest fix imaginable and it’s not even noticed:
Another example with extra space in chat message:
And another example I reported myself with very simple fix - adding debounce:
I sort of agree with @Dekkonot, that was kind of my thought too. I think putting the APIs like this into a landfill is probably better than littering in front of the store you got them from (best analogy I could come up with, maybe a little harsh sounding lmao), because then you kinda know where to go to find these things and they won’t end up populating other services.
E.g. if everything related to prompting built in plugins and features and editors and stuff is all on StudioService then you won’t have to go looking at services that might or might not be related to what you want, and you won’t encounter these APIs as much when most of the code you end up writing is game code.
At the very least as long as it’s consistent and predictable I think I am still happy.
