I undersand that with the tracker curfew, there’s pressure to close as many bug reports as possible. However, the ‘feature request’ proviso has been turned into an excuse to close perfectly valid bug reports.
“As intended” is not a useful benchmark because intention is predicated on devs having thought of everything ahead of time. Please change the policy so that features should always work “as reasonably expected” instead.
If it’s not possible to immediately fix the bug for whatever reason, that’s fine. Consider just leaving it open with a low priority, or marking it as a known issue/todo. Perhaps, if suitable, add it to the quick hacks list for beginners to pick up.
If you truly have no intention of ever fixing the issue, at least mark it as a ‘won’t fix’ and state clearly that it’s too hard, too complicated, too burdensome, the original author is not available or that the expectation is just unrealistic. At least that’s fair and honest.
But closing the bug report outright as a “feature request” (when everyone knows it isn’t one) is highly demoralizing for reporters, sours your relationship with users, and also just means someone else will report the same thing down the line.
This raises an interesting point- perhaps the tracker needs a new category for “missing functionality”? Something that isn’t exactly a bug, but also isn’t a feature request. Having something small like this sent to RCS is basically a death sentence… it’s not tracked work, and the crowd over there is looking for the next whiz-bang-omg-feature to upvote. That said, I can see how opening the bug tracker up to this type of thing could become a source of abuse and a huge time sink that distracts from actual development. For example- how long would it be until the first report of “mesh preselection is missing functionality, every other software has it, so it can’t be by design” or something along those lines.
I agree: there should be a category in the tracker like: “impossible to use” - without thinking of a bug report
There are many so many great new features in development right know. But most of them I won’t ever use in my daily work. For this I need consistent working software.
Like the text tool, where every skilled blender user is unable to make a bold text, until he knows how crappy it works. See closed bugreport.
Or you backface culling / selection in 2.8 works much worse than in 2.7 (closed bugreport)
(If you disagree with those examples is fine, I hope the underlying idea is clear)
Although I understand the immense work of triaging and bug-fixing these notes should be considered and the proposal of @MadMinstrel seems useful to me.
These last examples seem to illustrate the central problem, that we have thousands of users for each developer. There is not a single user nor a single developer who does not already know that having support for bold text would be great. So what does such a bug report accomplish? Similarly, our “reset to defaults” has been largely nonfunctional for more than a decade and everyone already knows it.
Maybe we need to close such bug reports with a message like “yes, thanks but we already know that this doesn’t work as well you’d expect it to. This is one of a myriad of things we’d like to improve, and we are a little embarrassed that this wasn’t done earlier, but all things take time and we have more to do than time to do them. Hopefully someone will fix this one day.”
This is why I don’t think the bug tracker is the place for these per se, but neither is RCS. In enterprise software development, stuff like that would show up in the ‘backlog’- but as we all know open source development isn’t like enterprise development. But, If we had a place to collect low priority ‘backlog items’ it could be a great opportunity for aspiring contributors to dip their toes into adding patches.
Removing “reset to default” has also been debated for almost as long as it has existed. All these properties can have an optional Default value set quite easily. So it is fairly easily to make most work by just adding a few thousand simple lines. But those values aren’t used when you start blender. Instead the initial values are taken from the “default.blend” file that is embedded. Okay, so when adding those defaults just make sure to use the initial values, no problem. But you must now keep both in sync when you change one. Oh, and creating many types of new things have their defaults set somewhere else. Damn, now someone added thousands of lines, things mostly work, and we now have to be mindful of keeping what does work in sync so it stays working.
But then you face the problem of what defaults really are. If you make a bunch of changes and then “save as default blend” don’t you expect those values if you “reset to default”? In themes when you do so do you expect what was there before you changed it or the initial value from the theme? Crap, we don’t know what theme you started with before you made your own changes. So if select Light theme, then made changes, the best we can do is reset to the value from Dark theme. LOL.
