Old 02-22-2013, 03:12 AM   #41
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Oblivion
Posts: 10,255
Default

Quote:
Originally Posted by schwa View Post
We need to figure out what to do about the tracker.
put the issue tracker at the bottom of the list and the bug reports forum at the top. that way discussion will filter out more of the "user error."

many people are too lazy to read far enough into the list to find the correct place, let alone read a sticky.

navigating forums is not a typical user skill, according to my observations.
__________________
foxyyymusic
foxAsteria is offline   Reply With Quote
Old 02-22-2013, 04:29 AM   #42
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,359
Default

Quote:
Originally Posted by EvilDragon View Post
Sounds like you accidentally exploded the takes on the same track. You have an action to implode items from the same track back into takes...
It's likely that Options -> "New recording that overlaps existing media" is set to "Creates new media items in separate lanes (layers)".



The tracker is a real mess. I don't know how to reasonably search it either, I don't think users can be blamed for not finding duplicates. I tried my very best to help keeping that thing clean for a while, created discussion threads, fixed misdirected issues, changed states, explained why I do what to not upset posters etc but it's a real pain to do all that - knowing that the next hour I can do it all over with the next issue. I only occasionally look into it nowadays and clean up a bit where I am entirely sure, hoping the devs keep their own database anyway. Otherwise I am ignoring it. Too much hazzle with too little benefit.


EDIT: oops, I quoted the wrong post, should have quoted Jens
gofer is offline   Reply With Quote
Old 02-22-2013, 04:30 AM   #43
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Quote:
Originally Posted by EvilDragon View Post
The problem with the tracker right now is: anyone can post in it. And people ARE NOT READING THIS NOTE


So it gets filled with misdirected posts, duplicates (because nobody knows how to fucking search the tracker properly!), etc.

Devs - lock the tracker, get it sorted out. I'll gladly help if you want.
There's no big problem with letting users log issues as I see it ED. Here's why. You need a scrub team to determine category and validity of issues they will enter on users behalf which is what you advocate. yes?

That same scrub team can categorise and validate logged issues in the tracker just as easily. If policy is to 'delete' 'not an issue' then fine or maybe you decide to archive them.

The bigger problem is that issues are not being validated and categorised. Not so much that they are being entered. A tracker full of issues categorised 'not an issue' is 'not an issue' so much as a tracker full of issues that are out of date, uncategorised and unvalidated without ownership. This is really my last post in this. The tracker is the wrong thing for this job. What are the devs using internally I wonder?

Last edited by Amazed; 02-22-2013 at 04:31 AM. Reason: typo
Amazed is offline   Reply With Quote
Old 02-22-2013, 04:36 AM   #44
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Point there, Amazed.
EvilDragon is offline   Reply With Quote
Old 02-22-2013, 05:10 AM   #45
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by EvilDragon View Post
Sounds like you accidentally exploded the takes on the same track. You have an action to implode items from the same track back into takes...
I have a shortcut for imploding takes and that's what I did - but before I had also to manualy delete the little snippet of the final take and then to manually resize the other item I kept... not top big a deal even if a bit cumbersome.

But the thing is that Rreaper does it with every new recording in this project-file so it's should be a certain setting I accidentally changed - without having any idea where I could find it, how it is named and what exactly it actually does.

It is a fact that there a numerous places which are scattered all over Reaper where it could hide.
jens is offline   Reply With Quote
Old 02-22-2013, 05:14 AM   #46
Billoon
Human being with feelings
 
Join Date: Sep 2006
Location: Arse end of the earth.
Posts: 2,988
Default

Quote:
Originally Posted by Amazed View Post
A tracker full of issues categorised 'not an issue' is 'not an issue'...
I think it is cause it makes it more difficult for the devs to get to the info they need which is how to reproduce a bug. Thats why i think nothing should be allowed in there until it is both confirmed as a bug and a method for reproducing it is given.

Concise, usefull and no need to wade through a bunch of non issues.
__________________
Fortune favours the prepared...
Billoon is offline   Reply With Quote
Old 02-22-2013, 05:19 AM   #47
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by gofer View Post
It's likely that Options -> "New recording that overlaps existing media" is set to "Creates new media items in separate lanes (layers)".

no, that wasn't it either... there were no seperate lanes. It is all back to normal now b.t.w. .
jens is offline   Reply With Quote
Old 02-22-2013, 06:17 AM   #48
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Quote:
Originally Posted by Billoon View Post
I think it is cause it makes it more difficult for the devs to get to the info they need which is how to reproduce a bug. Thats why i think nothing should be allowed in there until it is both confirmed as a bug and a method for reproducing it is given.

Concise, usefull and no need to wade through a bunch of non issues.
When you're working with a tool that's made for this job, nobody wades through non relevant issues. You filter and search for what you want. Seen one before?
Amazed is offline   Reply With Quote
Old 02-22-2013, 06:38 AM   #49
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

How to search the Issue Tracker:

Click me!

First off, to answer the OP, most nasty but fixable bugs are being fixed before they end up in the tracker (that's why we have a pre-release cycle) so it's not exactly like every new version produces a mass of new tracker submissions. What ends up there unfixed as "substantial" bugs is mostly stuff that's hard to fix or hard to reproduce while still looking like a potential bug (hence they stay there as "unconfirmed"). The rest is things that range from nitpicks and "buglettes" to submissions that contain a mix of things of that were partially fixed and sometimes contain a FR in the other half and hence couldn't be easily marked as "fixed", stuff that was fixed but not marked as such because it's hard to keep track of them all, especially with all the noise/micro-bugs.

To put that in a relation, bug counts e.g. for popular OSses apparently ranged from estimated 4 to 6-digit numbers even at the end of their lifecycles and still most of us rarely got really stopped by any of those. Same goes for REAPER and it's not a "lost war", you are just able to see the fully disclosed battlefield, including the little scuffles and what shouldn't be visible anymore.

Regarding the tracker meta-discussion (from tracker mod's POV):

Managing the noise coming up from keeping the tracker open is costing a lot (if not all) resources from the issue tracker mods and it has turned out to be a very unrewarding thing to do. If we actually get so far as to deal with the actual bugs (which is the only fun thing to do in there, at least for me), most times you have to defend your decisions, users get pissed off and so on. So I can understand very well why most tracker mods gave up trying to deal with the quite overwhelming mass of things in there.

This is not only due to all the things that shouldn't have gone there in first place, it's also because many things are much, much harder to assess than you may think. It starts with determining whether or not something is actually a bug per definition (even in its expanded version "generally unexpected behavior") or not, which is in many cases very unclear and needs at least more investigation, and that should happen before it gets into the tracker. As already mentioned, there's potential for conflict in this area since the actual definition of "bug" is not widely known and people tend to insist on their own definition/assessment.

Giving that a useful priority taking "the big image" into account (meaning "how many users may be affected by this", "what workarounds are available", how showstopping it acts for the affected users and whatnot) turns out to be hard as well once you're actually confronted with that "big image" thing - especially when you find yourself not an expert in that specific corner of REAPER the submission is about. Again, there will be submitters very unsatisfied with the result, often after the mods spent a lot (!) of time trying to reproduce and refine the reports.

Therefore it wouldn't matter that much whether the noise is being filtered in or outside of the tracker indeed, there is going to be unnecessary fighting about what should go in there and what should not, giving the people confronted with that a hard time. But I think there should be at least an instance for keeping accidental/unclear submissions out there simply because the 'Projects' software makes dealing with those hard. The following process needs some thorough rethinking/reorganization indeed.

Last edited by Ollie; 02-22-2013 at 06:53 AM.
Ollie is offline   Reply With Quote
Old 02-22-2013, 06:50 AM   #50
Billoon
Human being with feelings
 
Join Date: Sep 2006
Location: Arse end of the earth.
Posts: 2,988
Default

Quote:
Originally Posted by Amazed View Post
When you're working with a tool that's made for this job, nobody wades through non relevant issues. You filter and search for what you want. Seen one before?
Yeah but in this tracker anyone can submit anything and call it a bug, so in this situation how do you filter just the 'actual' bugs.

They need to be separated by someone that can do so appropriately.

I think bug reports in the forum and confirmed, reproduceable bugs in the tracker is the best solution.

Anything 'grey area' can just stay in the forum IMO. Doesnt mean they wouldnt get fixed though.
__________________
Fortune favours the prepared...
Billoon is offline   Reply With Quote
Old 02-22-2013, 08:29 AM   #51
semiquaver
Human being with feelings
 
Join Date: Jun 2008
Posts: 4,923
Default

@Ollie would it not be worth moving bug tracking into a real tool meant for the purpose etraxis bugzilla or whatever?
semiquaver is offline   Reply With Quote
Old 02-22-2013, 08:36 AM   #52
DBMusic
Human being with feelings
 
DBMusic's Avatar
 
Join Date: Sep 2009
Location: Illinois
Posts: 1,203
Default

Quote:
Originally Posted by Amazed View Post
Unless something changes, this war is lost I believe.
What war? Oh, the drama of it all.

For a ridiculously low cost we get to leverage the work of 3 very talented developers. I don't give a crusty old turd how many "bugs" are listed in a forum. REAPER works for me, so I use it. If it didn't, I'd find something else.

But to spend time doing a Chicken Little impersonation is just silly.
__________________
My Stuff
DBMusic is offline   Reply With Quote
Old 02-22-2013, 08:39 AM   #53
semiquaver
Human being with feelings
 
Join Date: Jun 2008
Posts: 4,923
Default

agreed REAPER is remarkable stable and "low bug" over here...

this discussion just a matter of how best to leverage the community I think ...
semiquaver is offline   Reply With Quote
Old 02-22-2013, 09:13 AM   #54
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Quote:
Originally Posted by Billoon View Post
Yeah but in this tracker anyone can submit anything and call it a bug, so in this situation how do you filter just the 'actual' bugs.

They need to be separated by someone that can do so appropriately.

I think bug reports in the forum and confirmed, reproduceable bugs in the tracker is the best solution.

Anything 'grey area' can just stay in the forum IMO. Doesnt mean they wouldnt get fixed though.
Read the whole thread please.
Amazed is offline   Reply With Quote
Old 02-22-2013, 09:18 AM   #55
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Quote:
Originally Posted by DBMusic View Post
What war? Oh, the drama of it all.

For a ridiculously low cost we get to leverage the work of 3 very talented developers. I don't give a crusty old turd how many "bugs" are listed in a forum. REAPER works for me, so I use it. If it didn't, I'd find something else.

But to spend time doing a Chicken Little impersonation is just silly.
Astute.
Amazed is offline   Reply With Quote
Old 02-22-2013, 09:24 AM   #56
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Quote:
Originally Posted by semiquaver View Post
agreed REAPER is remarkable stable and "low bug" over here...

this discussion just a matter of how best to leverage the community I think ...
What are our requirements of the tracker?
Does the tracker in it's current shape, form and content meet those requirements?
Amazed is offline   Reply With Quote
Old 02-22-2013, 09:54 AM   #57
Amazed
Human being with feelings
 
Amazed's Avatar
 
Join Date: Nov 2009
Location: Perth, W.A.
Posts: 1,708
Default

Quote:
Originally Posted by Ollie View Post
How to search the Issue Tracker:

Click me!

First off, to answer the OP, most nasty but fixable bugs are being fixed before they end up in the tracker (that's why we have a pre-release cycle) so it's not exactly like every new version produces a mass of new tracker submissions. What ends up there unfixed as "substantial" bugs is mostly stuff that's hard to fix or hard to reproduce while still looking like a potential bug (hence they stay there as "unconfirmed"). The rest is things that range from nitpicks and "buglettes" to submissions that contain a mix of things of that were partially fixed and sometimes contain a FR in the other half and hence couldn't be easily marked as "fixed", stuff that was fixed but not marked as such because it's hard to keep track of them all, especially with all the noise/micro-bugs.

To put that in a relation, bug counts e.g. for popular OSses apparently ranged from estimated 4 to 6-digit numbers even at the end of their lifecycles and still most of us rarely got really stopped by any of those. Same goes for REAPER and it's not a "lost war", you are just able to see the fully disclosed battlefield, including the little scuffles and what shouldn't be visible anymore.

Regarding the tracker meta-discussion (from tracker mod's POV):

Managing the noise coming up from keeping the tracker open is costing a lot (if not all) resources from the issue tracker mods and it has turned out to be a very unrewarding thing to do. If we actually get so far as to deal with the actual bugs (which is the only fun thing to do in there, at least for me), most times you have to defend your decisions, users get pissed off and so on. So I can understand very well why most tracker mods gave up trying to deal with the quite overwhelming mass of things in there.

This is not only due to all the things that shouldn't have gone there in first place, it's also because many things are much, much harder to assess than you may think. It starts with determining whether or not something is actually a bug per definition (even in its expanded version "generally unexpected behavior") or not, which is in many cases very unclear and needs at least more investigation, and that should happen before it gets into the tracker. As already mentioned, there's potential for conflict in this area since the actual definition of "bug" is not widely known and people tend to insist on their own definition/assessment.

Giving that a useful priority taking "the big image" into account (meaning "how many users may be affected by this", "what workarounds are available", how showstopping it acts for the affected users and whatnot) turns out to be hard as well once you're actually confronted with that "big image" thing - especially when you find yourself not an expert in that specific corner of REAPER the submission is about. Again, there will be submitters very unsatisfied with the result, often after the mods spent a lot (!) of time trying to reproduce and refine the reports.

Therefore it wouldn't matter that much whether the noise is being filtered in or outside of the tracker indeed, there is going to be unnecessary fighting about what should go in there and what should not, giving the people confronted with that a hard time. But I think there should be at least an instance for keeping accidental/unclear submissions out there simply because the 'Projects' software makes dealing with those hard. The following process needs some thorough rethinking/reorganization indeed.
Understood Ollie. It's thankless and that's just one reason it's where it is. Nobody likes it. Least off all devs. I know that the 'health' of the tracker is not representative of Reaper. It was the tracker I was talking about. The limitations of the tool being used doesn't help matters. I've made suggestions in that regard. Not without some experience. As for my opinion that the tracker doesn't stand a chance now of ever getting cleaned up unless something changes, I'll stand by that. Let me know when the number of unconfirmed issues in the tracker is halved. I'd call that promise.
Amazed is offline   Reply With Quote
Old 02-22-2013, 02:37 PM   #58
semiquaver
Human being with feelings
 
Join Date: Jun 2008
Posts: 4,923
Default

yep its unwieldy alright.

If the goal is to get bugs to the devs and let users know if bugs have already been reported so as not to clog the forum with noise then...

it is not working too well, no. So change not a bad idea....
semiquaver is offline   Reply With Quote
Old 02-22-2013, 02:57 PM   #59
Billoon
Human being with feelings
 
Join Date: Sep 2006
Location: Arse end of the earth.
Posts: 2,988
Default

Quote:
Originally Posted by Amazed View Post
Read the whole thread please.
Oh, i have. What is it you think i missed?
__________________
Fortune favours the prepared...
Billoon is offline   Reply With Quote
Old 02-22-2013, 03:36 PM   #60
Win Conway
Human being with feelings
 
Join Date: Dec 2010
Posts: 3,826
Default

Quote:
Originally Posted by schwa View Post
Unfortunately, it is correct that the bug tracker is not kept clean and up-to-date. Many of the bugs in the tracker are either fixed, or not bugs in the first place (which is worse because many such reports require a long time to explain to the user making the report). As you say, the noise makes the tracker not so useful for logging actual bugs. We need to figure out what to do about the tracker.
Get rid of it, and read the bug forum, simple as that

the bug tracker as is shown is a complete waste of time and if it gets cleaned up will it stay clean (It didn't last time did it)
The FR tracker, lets not even go there, there is features asked for in there that have so many votes and are blatantly just ignored by the devs (you) while they (you) just add features that nobody (Xfade editor thing) could actually find an FR for.
This is your perogative obviously, but the FR tracker makes people think otherwise and also gives a faux idea to people that their feature will get implemented if voted for "Vote for my FR here" in signatures WTF

Scrap it and move on, it didn't work and done is done.
__________________
Stop posting huge images, smaller images or thumbnail, it's not rocket science!
Win Conway is offline   Reply With Quote
Old 02-22-2013, 04:35 PM   #61
matey
Human being with feelings
 
matey's Avatar
 
Join Date: Apr 2008
Location: Civitavecchia (Italy)
Posts: 574
Default

errors make analog gear sounding great, as bugs do on digital... maybe
__________________
"You know what a miracle is. Not what Bakunin said. But another world's intrusion into this one".
Thomas Pynchon, The Crying of Lot 49
matey is offline   Reply With Quote
Old 02-22-2013, 06:10 PM   #62
lxm
Human being with feelings
 
lxm's Avatar
 
Join Date: Mar 2010
Posts: 2,638
Default

KIRPLUNK DUBLE SPUNK
lxm is offline   Reply With Quote
Old 02-22-2013, 06:10 PM   #63
lxm
Human being with feelings
 
lxm's Avatar
 
Join Date: Mar 2010
Posts: 2,638
Default

Quote:
Originally Posted by Ollie View Post
How to search the Issue Tracker:

Click me!

First off, to answer the OP, most nasty but fixable bugs are being fixed before they end up in the tracker (that's why we have a pre-release cycle) so it's not exactly like every new version produces a mass of new tracker submissions. What ends up there unfixed as "substantial" bugs is mostly stuff that's hard to fix or hard to reproduce while still looking like a potential bug (hence they stay there as "unconfirmed"). The rest is things that range from nitpicks and "buglettes" to submissions that contain a mix of things of that were partially fixed and sometimes contain a FR in the other half and hence couldn't be easily marked as "fixed", stuff that was fixed but not marked as such because it's hard to keep track of them all, especially with all the noise/micro-bugs.

To put that in a relation, bug counts e.g. for popular OSses apparently ranged from estimated 4 to 6-digit numbers even at the end of their lifecycles and still most of us rarely got really stopped by any of those. Same goes for REAPER and it's not a "lost war", you are just able to see the fully disclosed battlefield, including the little scuffles and what shouldn't be visible anymore.

Regarding the tracker meta-discussion (from tracker mod's POV):

Managing the noise coming up from keeping the tracker open is costing a lot (if not all) resources from the issue tracker mods and it has turned out to be a very unrewarding thing to do. If we actually get so far as to deal with the actual bugs (which is the only fun thing to do in there, at least for me), most times you have to defend your decisions, users get pissed off and so on. So I can understand very well why most tracker mods gave up trying to deal with the quite overwhelming mass of things in there.

This is not only due to all the things that shouldn't have gone there in first place, it's also because many things are much, much harder to assess than you may think. It starts with determining whether or not something is actually a bug per definition (even in its expanded version "generally unexpected behavior") or not, which is in many cases very unclear and needs at least more investigation, and that should happen before it gets into the tracker. As already mentioned, there's potential for conflict in this area since the actual definition of "bug" is not widely known and people tend to insist on their own definition/assessment.

Giving that a useful priority taking "the big image" into account (meaning "how many users may be affected by this", "what workarounds are available", how showstopping it acts for the affected users and whatnot) turns out to be hard as well once you're actually confronted with that "big image" thing - especially when you find yourself not an expert in that specific corner of REAPER the submission is about. Again, there will be submitters very unsatisfied with the result, often after the mods spent a lot (!) of time trying to reproduce and refine the reports.

Therefore it wouldn't matter that much whether the noise is being filtered in or outside of the tracker indeed, there is going to be unnecessary fighting about what should go in there and what should not, giving the people confronted with that a hard time. But I think there should be at least an instance for keeping accidental/unclear submissions out there simply because the 'Projects' software makes dealing with those hard. The following process needs some thorough rethinking/reorganization indeed.
I posted a bug and FR that says implemented but its not. Bug remains(Non 4/4 Grid lines). I have been trying to get an explanation why this is.
lxm is offline   Reply With Quote
Old 02-22-2013, 06:32 PM   #64
The Telenator
Banned
 
Join Date: Dec 2011
Location: Oud West, NL
Posts: 2,335
Default

Oh, spendid all this. I had to skip to the end to post because I got laughing so hard I couldn't read on. I was only trying to catch up on all things REAPER -- been away from the forum for a few days. I really needed a good laugh today, though, so thanks. A lovely thread.
The Telenator is offline   Reply With Quote
Old 02-22-2013, 07:26 PM   #65
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Oblivion
Posts: 10,255
Default

Quote:
Originally Posted by matey View Post
errors make analog gear sounding great, as bugs do on digital... maybe
I tend to agree. Occasionally Reaper fucks up in the the best way. If DAW's worked flawlessly, we wouldn't have happy mistakes.
__________________
foxyyymusic
foxAsteria is offline   Reply With Quote
Old 02-28-2013, 02:05 PM   #66
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,859
Default

Assuming that the bug tracker gets cleaned up (some how), how about requiring a specified period of time for discussion (a week, for example) before a bug can be officially added to the tracker? And how about requiring user verification before officially submitting bug reports into the tracker? That would give users plenty of time to elliminate many false bug reports.

And if something were worked out for the devs to pop into discussions where necessary, if only to say that the issue being discussed is by design, that could take care of more bug report confusion.

As it is right now, everything is very loose, and completely up to users in how bugs get reported. Some users will discuss potential bugs in the bug section of the forum first, and some will report potential bugs in the tracker right away, before receiving any verification. And with very little dev involvement in the process, the whole thing is kind of a mess. The way that I'm describing should still require little dev involvment, but it would count more.

And for bugs which get inadvertently fixed during development, or for those bugs which get fixed but do not get updated in the tracker, maybe allowing for user retitling of bug reports and finer control over categorization could be helpful.

Another idea is to make searching for duplicate bugs easier through finer categorization, and allowing users to combine duplicate bug reports. The bug discussion area of the forum isn't exactly easy to search through, for example, and I wonder how many duplicate threads exist there.
__________________
It's time to take a stand against the synthesizer.

Last edited by brainwreck; 02-28-2013 at 02:10 PM.
brainwreck is offline   Reply With Quote
Old 02-28-2013, 04:02 PM   #67
airon
Human being with feelings
 
airon's Avatar
 
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
Default

The category list can be a limitation as well.

Predetermined tags might do a little better, or add detail to it that makes it easier to identify and group problems together.

GUI issues in the MCP for example, or Crash in the midi editor. You can't do that in categories but it's quite easy with predetermined tags, as it allows to combine things.
__________________
Using Latch Preview (Video) - Faderport 16 setup for CSI 1.1 , CSI 3.10
Website
"My ego comes pre-shrunk" - Randy Thom

Last edited by airon; 02-28-2013 at 04:54 PM.
airon is offline   Reply With Quote
Old 02-28-2013, 04:20 PM   #68
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,859
Default

Quote:
Originally Posted by airon View Post
The category list can be a limitation as well.

Predetermined tags might do a little better, or add detail to it that makes it easier to identify and group problems together.

GUI issues in the MCP for example, or Crash in the midi editor. You can't do that in categories but it's quite easy with predetermined tags.
Or, how about enabling users to mark bugs under multiple categories, gui/midi editor, for example, so that users don't have to pick between categories? And if these bug reports were mirrored, or linked, closing one would close the other. Also, any discussion in one could be mirrored to the other.

Also, the bug report discussion section of the forum could use categorization. Currently, it's the wild west, everything in one bag. Applying the same ideas about tags, or mulitiple categorization, as for the bug tracker, could be immensely helpful in cleaning up discussion (duplicate threads, false bug discusssions, etc.)

Another idea is to enable linking the bug discussion threads directly to the bug reports. As it is now, some users will link back to discussions, where some will not.
__________________
It's time to take a stand against the synthesizer.
brainwreck is offline   Reply With Quote
Old 03-01-2013, 07:58 AM   #69
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

Thank you for your suggestions and thinking about all that. Unfortunately this is all limited by the capabilites of the software.

Quote:
Originally Posted by brainwreck View Post
Assuming that the bug tracker gets cleaned up (some how)
I'm currently revisiting all bugs marked "confirmed" (when I have time for that), meaning I had to reproduce them all again to check if they got fixed. That alone took ~14-16 hrs of work and it's not finished yet, just to give you an idea of what "cleaning up" means. Even if some of that stuff could be pushed around/purged/whatnot in bulks (it can't), the remaining issues still need quite tedious processing/reproduction attempts/clicking around. Any bug not super-obvious and/or well described can cost a tracker mod hours of investigation/setting up, often without result and not helping making an assessment. That's how it could end up in that mess in first place, the mass of stuff getting in there couldn't be processed in reasonable time, not to mention that none of us is an expert in all corners of REAPER, making a meaningful assessment of issues and determining "bug or not" impossible in these cases.

Quote:
Originally Posted by brainwreck View Post
, how about requiring a specified period of time for discussion (a week, for example) before a bug can be officially added to the tracker? And how about requiring user verification before officially submitting bug reports into the tracker? That would give users plenty of time to elliminate many false bug reports.
Neither the forum software nor the Projects plug-in have functions to support anything like this.

Quote:
Originally Posted by brainwreck View Post
And for bugs which get inadvertently fixed during development, or for those bugs which get fixed but do not get updated in the tracker, maybe allowing for user retitling of bug reports and finer control over categorization could be helpful.
Besides Dstruct who soon made a habit of that, I think I have seen only 2 other user (maybe there were 3) replying to a BR and saying it was fixed.

Quote:
Originally Posted by brainwreck View Post
Another idea is to make searching for duplicate bugs easier through finer categorization
"Finer categorization" is great for people who know how to categorize that stuff and bother finding the proper category and putting it there. Those people are a very small group though, meaning finer categories means more work for the people who have to do that for the users not capable of finding the right categories.

Quote:
Originally Posted by airon View Post
The category list can be a limitation as well.

Predetermined tags might do a little better, or add detail to it that makes it easier to identify and group problems together.
There is a tag system, alas it's almost completely unused since it wasn't mandatory to use it and I only used it a few times to e.g. connect "unicode" related issues.

Quote:
Originally Posted by brainwreck View Post
Or, how about enabling users to mark bugs under multiple categories, gui/midi editor, for example, so that users don't have to pick between categories? And if these bug reports were mirrored, or linked, closing one would close the other. Also, any discussion in one could be mirrored to the other.
Again, the software doesn't have functions for that.

Quote:
Originally Posted by brainwreck View Post
Also, the bug report discussion section of the forum could use categorization. Currently, it's the wild west, everything in one bag. Applying the same ideas about tags, or mulitiple categorization, as for the bug tracker, could be immensely helpful in cleaning up discussion (duplicate threads, false bug discusssions, etc.)
Sounds nice but the same thing mentioned above applies - it just increases the workload for those charged with maintaining the tracker+forums, while having little benefits to warrant that efforts.

Quote:
Originally Posted by brainwreck View Post
Another idea is to enable linking the bug discussion threads directly to the bug reports. As it is now, some users will link back to discussions, where some will not.
There are also no functions to link stuff, no functions to move, it all has to be done manually by the tracker mods.

We tried to do that with FRs for a while but everyone got (understandably) tired of it since it causes a lot of work, and that's only necessary because people do not read/ignore stickies or stuff highlighted in red.
Ollie is offline   Reply With Quote
Old 03-01-2013, 08:15 AM   #70
Ollie
Super Moderator (no feelings)
 
Ollie's Avatar
 
Join Date: Dec 2007
Location: On or near a dike
Posts: 9,834
Default

Quote:
Originally Posted by lxm View Post
that says implemented but its not. I have been trying to get an explanation why this is.
That's because...

Quote:
Originally Posted by lxm View Post
I posted a bug and FR
You shouldn't put a FR and a bug into the same issue in the tracker, for example because you can't set the status on that accordingly. It makes sense to set it to "implemented" when the FR part was implemented.

Quote:
Originally Posted by lxm View Post
Bug remains(Non 4/4 Grid lines).
What you call a bug is not a bug per definition, it's a FR as well - it's simply not implemented and not broken code = not a bug.

Quote:
Originally Posted by Ollie
If we actually get so far as to deal with the actual bugs (which is the only fun thing to do in there, at least for me), most times you have to defend your decisions, users get pissed off and so on. So I can understand very well why most tracker mods gave up
Ollie is offline   Reply With Quote
Old 03-01-2013, 08:23 AM   #71
achild
Human being with feelings
 
Join Date: Feb 2011
Posts: 24
Default

Quote:
Originally Posted by karbomusic View Post
Additionally there is no such thing as an empty bug list eva.
There most definitely is such a thing. I have a friend who writes code for NASA ships. An empty bug list (among other things such as correctly designed tests) is a must for things like this. Obviously there are a million differences between software like Reaper and software like that, though...
achild is offline   Reply With Quote
Old 03-01-2013, 08:27 AM   #72
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

If the Projects plugin is so limited that you can't link or move stuff or do batches, fuck, remove that fucker and leave it as it is now for internal use only. It's just a nuisance otherwise.


Why not use some PROPER bug tracking tools, then (SVN, Bugzilla, JIRA...)? Bug tracker shouldn't be linked to this forum, IMHO. I think that discussions mentioned in FR and BR sections of the forum should be regularly checked by devs and users alike, and only some users should be able to access this bug tracker and input properly articulated FRs/BRs there. Better for devs, better for users (less clutter on the forum).
EvilDragon is offline   Reply With Quote
Old 03-01-2013, 08:29 AM   #73
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by achild View Post
There most definitely is such a thing. I have a friend who writes code for NASA ships. An empty bug list (among other things such as correctly designed tests) is a must for things like this. Obviously there are a million differences between software like Reaper and software like that, though...
Allow me to rephrase slightly, there is no such thing as software without bugs. As far as NASA, been there, done that. IIRC much of the code that runs things like the shuttle for example still run 16 bit code for that very reason. I'll agree that the bug count would be ridiculously low but no such thing as the impossibility of a bug as long as humans are invovled. Unit tests cover a lot of ground but they can only test what the human wrote the test to exploit and test.

Last edited by karbomusic; 03-01-2013 at 08:43 AM.
karbomusic is offline   Reply With Quote
Old 03-01-2013, 08:53 AM   #74
tls11823
Human being with feelings
 
tls11823's Avatar
 
Join Date: Aug 2010
Location: Harrisburg, PA USA
Posts: 1,481
Default

Quote:
Originally Posted by EvilDragon View Post
Why not use some PROPER bug tracking tools, then (SVN, Bugzilla, JIRA...)? Bug tracker shouldn't be linked to this forum, IMHO.
I think this is the best suggestion so far.
__________________
We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about.
--Charles Kingsley... or maybe Albert Einstein... definitely somebody wiser than myself--
tls11823 is offline   Reply With Quote
Old 03-01-2013, 09:50 AM   #75
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,111
Default

Quote:
Originally Posted by Ollie View Post
What you call a bug is not a bug per definition, it's a FR as well - it's simply not implemented and not broken code = not a bug.
How about calling it a "design flaw" or "usability issue"?

The general attitude that users should create FRs (not bug reports) to report design flaws and usability issues is quite telling. This kind of attitude tries to give a false impression of Reaper's quality and maturity.
You can say something like "Bugs in Reaper are fixed very quickly" but there are still lots of long-standing usability problems, design flaws and inconsistencies. And those issues are deteriorating the quality of Reaper even when all bugs (by your defintion) are fixed.

jnif
jnif is offline   Reply With Quote
Old 03-01-2013, 09:58 AM   #76
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by jnif View Post
How about calling it a "design flaw" or "usability issue"?

The general attitude that users should create FRs (not bug reports) to report design flaws and usability issues is quite telling. This kind of attitude tries to give a false impression of Reaper's quality and maturity.
You can say something like "Bugs in Reaper are fixed very quickly" but there are still lots of long-standing usability problems, design flaws and inconsistencies. And those issues are deteriorating the quality of Reaper even when all bugs (by your defintion) are fixed.

jnif
What it tells more than anything is end-users lack of understanding of bugs, code and their proper definitions in a development environment and tend to mistakenly confuse such with dev attitude etc. In most cases that misunderstanding will never be bridged because end-user experience and code bugs are completely blurred together by the user (understandably of course since all they have is the end-user experience). However, the devs, any group of devs cannot successfully manage the product without those seemingly misalinged definitions. Its the reason most Bug DBs aren't public. It creates way too much confusion for users because users only see their interpretation from the outside, never the underlying code which is abstracted too far away from them.

Of course explaining the above to any end-user in a way that will make sense also becomes futile such as-is this thread. IMHO it all should be removed except for bug reports which the devs track and fix internally in an internal database. Actually, I'm sure there is already an internal bug DB none of us see anyway.

Last edited by karbomusic; 03-01-2013 at 10:18 AM.
karbomusic is offline   Reply With Quote
Old 03-01-2013, 10:19 AM   #77
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,111
Default

Quote:
Originally Posted by karbomusic View Post
What it tells more than anything is end-users lack of understanding of bugs, code and their proper definitions in a development environment and tend to mistakenly confuse such with dev attitude etc. In most cases that misunderstanding will never be bridged because end-user experience and code bugs are completely blurred together by the user. However, the devs, any group of devs cannot successfully manage the product without those seemingly misalinged definitions. Its the reason most Bug DBs aren't public. It creates way too much confusion for users because users only see their interpretation from the outside, never the underlying code which is abstracted too far away from them.

Of course explaining the above to any end-user in a way that will make sense also becomes futile such as-is this thread. IMHO it all should be removed except for bug reports which the devs track and fix internally in an internal database. Actually, I'm sure there is already an internal bug DB none of us see anyway.
Why should devs fix only bugs (by your definition) and ignore all other problems that users report?
Do you think that would improve Reaper's quality?

Actually, your comment clearly reflects the current situation. I.e. only bugs in the most strict sense are taken seriously. And this attitude shows (in a bad way) in Reaper's usability and UI design.

End-users don't need to understand anything about the code and implementation of Reaper. Still their reports should be seen as valuable feedback and not ignored/deleted.

By the way, I think there are quite many Reaper users that are professional SW developers. They know how SW development works, how to report issues and how issue trackers are used.

jnif
jnif is offline   Reply With Quote
Old 03-01-2013, 10:31 AM   #78
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Many? That would be thousands. A decent number? Quite more likely.
EvilDragon is offline   Reply With Quote
Old 03-01-2013, 10:33 AM   #79
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by jnif View Post
Why should devs fix only bugs (by your definition) and ignore all other problems that users report?
Do you think that would improve Reaper's quality?
That's not what I said. I said there is a specific set of criteria for what is a bug and what is not that won't make total sense to 99% of the end-users. Fitting that definition has nothing to do with whether something gets "fixed" or not other than a bug may get priority over a feature request depending on its risk, cost, opportunity, days to code, days to test criteria. Traditionally, most bugs/features get scored on a set of criteria just like this.

Quote:
Actually, your comment clearly reflects the current situation.
It should, it's code/app management 101. The only situation is there are thousands of users who all have opinions on what is most important. That is unmanageble, hence strict definitions which as I said, when followed may appear to some end users like they are being ignored.

That doesn't make Reapers bug fixing as you describe it perfect, it isn't nor is any other dev teams process (even though most are similar behind the scenes). Its still relatively very young if you formulate the number of devs * the number of years its been around. Good, bad, indifferent... Up to the individual opinion.

Quote:
End-users don't need to understand anything about the code and implementation of Reaper. Still their reports should be seen as valuable feedback and not ignored/deleted.
Surely, but at some point, being so public results in someone assuming they were ignored. It is completely impossible to avoid that result. That the reason I said there should be a place to report what appears to be a bug for visibility but beyond that the devs attack them based on what makes the most sense to them which won't always appear clear to us on the outside. Its not an ignoring of the user, that's just a perception that is unavoidable when attempting to track publicly like this.

Quote:
By the way, I think there are quite many Reaper users that are professional SW developers. They know how SW development works, how to report issues and how issue trackers are used.

jnif
Well, if they have worked at that level of development on teams with large complex projects and the large bug DBs and other managment resources that go with them, they already know all of this. They may not agree with my every word but the general process/problem exists globally.

Last edited by karbomusic; 03-01-2013 at 10:48 AM.
karbomusic is offline   Reply With Quote
Old 03-01-2013, 10:58 AM   #80
jnif
Human being with feelings
 
jnif's Avatar
 
Join Date: Dec 2008
Posts: 2,111
Default

Quote:
Originally Posted by karbomusic View Post
Well, if they have worked at that level of development on teams with large complex projects and the large bug DBs and other managment resources that go with them, they already know all of this. They may not agree with my every word but the general process/problem exists globally.
And they also know that tracking/fixing design flaws and usability problems is very important part of SW development.
In my opinion, forcing all those issues to FR category is not a good solution. It gives a false sense of quality and maturity. It should be important for devs to see clearly how many "problems" and what kind of "problems" there are in the product.

Regarding the current issue tracker and Bug report forum sections, I think the defensive attitude of moderators and other Reaper enthusiasts can be a problem. Valid problems might be played down, ignored, closed even before devs notice those reports. New users might not be so eager to report new issues if their reports have been played down by other forum members. I'm not saying this is a big problem but I have noticed it once in a while.

Quote:
Originally Posted by EvilDragon View Post
Many? That would be thousands. A decent number? Quite more likely.
I just learned that "quite many" is not proper English.
A decent number is what I meant.

jnif

Last edited by jnif; 03-01-2013 at 11:36 AM.
jnif is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:15 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.