Yes, exactly… They really only considered bugs to be literal typos in the code, regardless of how devastating behaviors the bugs which did not meet this criteria had.
If you report something like inability to set confirm changing brush size by any mouse button other than the left one, they will tell you it’s a feature request.
Then you can either…
A. Go F yourself
B. Proceed to create [sarcasm] surely to become popular [/sarcasm] feature request of ability for keymap to allow you to confirm brush size change using right mouse button. Oh imagine the likes pouring in.
…with B being equal option to A.
Blender’s usability will continue to be an issue if usability issues are not treated with the same respect as bugs. The most popular pieces of software out there, which people like, are popular because usability issues are treated with the same respect and bugs, and are developed by people who understand difference between solving usability issue and introducing whole new feature.
Typical example of that would be the necessity to rotate if you instances 90° in the viewport if you want to scatter them with particle system. It’s not really a bug in terms of there being a typo in a code, but changing coordinate axis for the mesh instances in particle system would hardly cut it as a “new feature”.
There’s a middle area between code-level bugs and new feature request, and they’ve now pretty much completely removed channels to report those.
Yeah, I can see that being an issue. I know at least some of my reports have fallen into the grey area of them being a “bug” or not. I left a ton of feedback on the remeshers during 2.81, some of the issues being serious usability issues that were unknown at the time since the features were brand new and needed the testing to find those workflow problems.
Luckily we managed to address the vast majority of them, but if they are going to be this strict with what is considered a bug or not, it is going to be hard leaving that feedback through the developer website. Which is a shame, since I think it has been the most effective place so far for doing this sort of work by getting more direct ways of contacting the devs.
Yeah, for example the other day I reported one where exporting formats doesn’t have file overwrite prompt. It’s easy to accidentally go into export instead of import rollout in the menu, and then if you doubleclick the file your wanted to import, you will without warning overwrite it, destroying its contents without any way to reverse/undo that.
Especially funny if you have both import and export in the quick favorites, tooltip being the only hint:
…and import/export window being nearly identical.
Of course, it was rejected for being a “feature request”. I wonder how many people already accidentally destroyed their import files. I did at least couple
Do you have any evidence of this, the .diff output from many of the bugfix commits involve far more than just fixing typos?
I know we would all like as many usability issues fixed as possible, but with thousands of reports, even the BF dream team of 20 full-time devs. would need months to resolve them all by way of putting down code, and that assumes waves of new reports do not come in.
Maybe typo wasn’t the best way to put it. I meant code that doesn’t work as intended.
24 posts were split to a new topic: File save dialogs and prompts
Anyway, here is the Youtube video.
The people commenting on that video seem to be a bit less interested in trying to construe this piece of Blender news as a bad thing (like we’ve seen many times on BA with many other articles). The amount of benefit it will bring will really depend on where they draw the line between ‘feature request’ and ‘bug’, though 2.8x development shows they are taking usability more seriously.
Woah. A professional crowd simulation tool in Blender? Nice.
Open Source too? Perfect.
Tangent Animation is bringing the good stuff to Blender.
Does a bug categorized as a “known issue” become labeled as such and remain open so development can be followed? Or does it become closed as “invalid”?
If it’s the former, I think it’s fair, but I feel like I’ve seen reports of unexpected and even dangerous behavior being closed as “invalid”, which is frustrating for the user reporting the issue who wants to see it being recognized and be (hopefully) eventually be worked on.
The idea is to be fair with users.
If your report is labeled as a bug, you may expect it to be solved quickly.
If it is labeled as a known issue, it will be a task that may last as is during an undetermined amount of time.
Before mentioning that an issue was known was literally meaning that issue was already known (seen as an acceptable limitation, trade-off by developer or already reported by another user).
Closing the report was not a way to neglect the issue ; but just a way to keep bugtracker clean by eliminating duplicates most of time.
It may be a good idea to count how many people report same issue. It gives an idea of how annoying it is. But there is no reason to keep open hundreds of reports about exact same issue.
There are always reports written by people who don’t follow guidelines, don’t know blender very well and expect it to work as another software.
Since 2.8 alphas, their policy is to consider design issues as something that should be discussed on devtalk forum to avoid that point of view of one user on how should work a feature damage workflow of other users.
So, things have never been as clear as now.
If you detect something that does not work like manual says it is supposed to work : blender is potentially broken. That may be a serious bug that may break many people’s workflow.
Developer will take a look and say if he can fix it now(bug) or not (known issue).
If you think that current design of a tool is not optimal, that may just annoy only one part of community and the rest don’t care. Level of importance is lower. If you succeed on devtalk forum to make a demonstration that improvement could benefit many people or that problem is annoying a lot of people, that will become a known issue, too.
But developers have to deal with a fog of 2 thousands bugreports collected since beginning of 2.8 transition, they need to clean the track in order to know where are priorities.
They should use a tagging and auto tagging system so that bugs and other categories are sorted more easily and at the same time everything is kept better monitored …
I currently believe that the method adopted at the freedesktop bugtracker is an effective example
Blog post on the Tracker Curfew (seems like an odd name to me; sounds like it’s closing the tracker at night or something—I suppose it doesn’t matter, though).
Notes for meeting of Monday, 23 December 2019. 18:00 CET / UTC 17:00 on #blender-coders on blender.chat.
- Nathan Letwory will be around for anything on development coordination / onboarding. Please remember to tag him directly (@jesterKing) on blender.chat if you need to talk to him.
- Ton Roosendaal and Sergey Sharybin will still be around as well, for anything else.
Changes / New Features
- A new system for smoke and fluid simulations - Mantaflow ( Sebastián Barschkis )
- Initial support for UDIM images ( Lukas Stockner )
- Added option to playblast only keyframes of selected objects ( Sybren A. Stüvel )
- Clarified tooltip for Viewport Render Animation ( Sybren A. Stüvel )
- De-duplicate mask context menu ( Campbell Barton )
- Tweaks to the brush Stroke panel ( William Reynish )
- Brush Settings overhaul ( William Reynish )
- Remove orphan datablocks directly from File->Clean Up menu ( Antonio Vazquez )
- Use DPI scale for transform cursors ( Campbell Barton )
- Prevent crash when opening file browser with mouse not in window ( Sybren A. Stüvel )
- Hide dopesheet slider options for Annotations ( Antonio Vazquez )
- Object: ‘Affect Only Origins’ support for ‘Clear Transform’ ( Campbell Barton )
- ID Management: Improve speed of code used when creating/renaming an ID. ( Bastien Montagne )
- Workbench: Force Vertex Colors in Paint Mode ( Jeroen Bakker )
- Sculpt: Use more saturated colors in the cursor ( Pablo Dobarro )
- Industry Compat keymap: Add support for the context menu PC keyboard key ( William Reynish )
Weekly Progress Reports
I haven’t seen Brecht report for awhile , is he now dealing with bugs and reviews only?
Well I know he’s still active but he’s no longer making any commits like he used to, It would be a shame if he stops development and contribution.
True, but I’m sure he’ll get the chance to develop himself again, or maybe he’d like to fully switch to managing the other developers.
I think he’s still on leave. Dalai mentioned it in one of the Blender Today streams.
I suspect he’s probably coding stuff for Cycles since he didn’t really get to during the 2.80-2.81 releases.
If that’s true then it’s all good, taking a time off is much deserved.
He’s in leave from 12 to 27. Don’t worry
You can check his comments on UDIM patch