View Single Post
Old 09-22-2016, 01:38 AM   #24
noise_construct
Human being with feelings
 
Join Date: Nov 2015
Posts: 1,566
Default

Quote:
Originally Posted by ELP View Post
believe me, noise_construct
latest when bugs are really confirmed, they notice this.

And a bug report donŽt need always and every time an comment from the
"We are great programmers, folks. We make the best software" REAPER Devs!!

If they find it important and or fits into the momentary Developer circle or whatever it would be fixed.

At least with REAPER..
like Ali always said "IŽam the greatest!!" ^^

--
Other have an nice looking issue queue, make standard comments and at the end do nothing...
Or have only an selected testers circle and the masses never really know real bugs except they find one them self. Mostly it needs sometimes years before real bugs
are fixed... or never fixed
Believe me within cubase 8xx there is a "some say little others big" MIDI engine spider which was already there in cubase 2.0 Atari time
Well, the others have significantly less bugs, so guess they are onto something.

Anyway, my main gripe is just unorganized approach. It doesn't value user time, and users do the testing for free for Cockos. Bug reporting becomes frustrating, when the reports are read only randomly, and we have no way of knowing if they are ever read or considered at all.

A real life example: I assembled a similar list like this from the surviving MIDI bugs I had reported during my time on these forums. I posted the list here, bumped it a few times, e-mailed it to support, and finally to a pre-release thread. This post in the pre-release thread was the first time to incite a dev response, which was "thanks for reporting, all valid, but not part of this release cycle, we'll get to them in next cycle".

Well, time passed by and next release cycle came, but these bugs weren't fixed, so I posted the list again- and got the exact same response. I informed them about this, they apologized and fixed all the bugs bar one, which I have reported again as I have no way of knowing if it's still on their lists.

Now I understand the amount of bug reports you get from a substantial userbase power/ab/using a complex, untested application. Extremely difficult to manage the amount of info, but this is exactly why software-assisted issue tracking exists. There is obviously administrative overhead involved in maintaining it, but sometimes work is boring, hard and lousy. I'd personally prefer not wasting the time of my customers, who in the end pay for it all.

A simple issue tracker with user verification threshold (need x users to verify a bug before devs need to take action) and vote-based priorisation recommendations for example, and a link to associated release so the reporters can (and should) test the fix.

Multiplying work just because the system/process is weak just doesn't really float in 2016, that's all I'm saying. It's an efficiency issue, and I question their choice to offload this on their customers instead improving their internal processes.
noise_construct is offline   Reply With Quote