Finale SmartMusic
  Home | Log In | Register | Search | Help
   
MakeMusic Forum > Public Forums > Finale - Windows - FORUM HAS MOVED! > ?? MakeMusic: Bug Tracking & Problem Handing  Forum Quick Jump
 
Would a Bug Tracking System be helpful to you
2
I don't know, but want to learn more. - 6.9%
4
possibly - 13.8%
1
I don't know, but want to learn more. - 3.4%
4
no - 13.8%
18
yes - 62.1%

 
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
[ << Previous Thread | Next Thread >> | Show Newest Post First ]

john.poole
Registered Member

Click to send john.poole email.Click to visit john.poole's website.Send a Private Message to john.pooleClick to Add JohnLPoole to Your AIM Buddy List.ICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2002
Total Posts : 30
 
   Posted 8/28/2004 8:51 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
What are your experiences with MakeMusic when a problem has been identified with their software and brought to their attention? It's been so long since I've tried pursuing something with them, but I think I just get an email indicating that the problem is acknowledged and some wording that is noncommittal.

I do not recall being given a Case Number or Tracking Number or Bug Number.

I develop software at Oracle Corporation www.oracle.com, the world's largest enterprise software company, and we use a system called a Bug Database which is extremely helpful tracking problems and communicating with customers/vendors/developers about a particular problem.

Moreover, when patches (code created to specially fix an identified problem), updates or new software is released, the release can reference bug numbers that have been fixed and/or addressed by the particular software.

I also track several open source software projects and they all use some sort of BUG tracking system. I do not remember if MakeMusic does, nor have I seen any postings in this forum that suggest they do.

I've been interested in the EPS export problem with font misidentification in Finale 2004 for Windows and have seen countless postings on other forums that really relate to the same problem I identified. I was thinking how more efficient it would be if the problem were identified by MakeMusic by some reference number, that way everyone could refer to it by its reference number and know we're all talking about the same thing.

If you agree that some sort of tracking or reference number for problems submitted to MakeMusic would be helpful, please participate in the poll associated with this posting.

It would be interesting to see if Finale customers would find such a problem resolution system helpful both with MakeMusic and among themselves.


John Laurence Poole

Editions Poole
www.editionspoole.com
[email protected]

Back to Top

john.poole
Registered Member

Click to send john.poole email.Click to visit john.poole's website.Send a Private Message to john.pooleClick to Add JohnLPoole to Your AIM Buddy List.ICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2002
Total Posts : 30
 
   Posted 8/28/2004 8:55 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Sorry about the confused polling... I don't seem to be able to find a way to edit it to remove the duplicate entry


John Laurence Poole

Editions Poole
www.editionspoole.com
[email protected]

Back to Top

Aaron Sherber
Registered Member

Email Address Not AvailableClick to visit Aaron Sherber's website.Send a Private Message to Aaron SherberAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2000
Total Posts : 330
 
   Posted 8/28/2004 12:14 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
This is a fantastic idea, but I'll bet MakeMusic will never do it. For one thing, it would mean admitting publicly all of the known bugs in Finale and how long they've been there. It also would mean changing their current "system" for addressing bugs, which is based on how many people complain about something. If there were a bug database where we could check to see if a certain bug had already been reported, fewer people would send duplicate bug reports. (I'm fairly sure they do something like this in-house, but I don't see them ever making it public.)

Aaron.
Back to Top

john.poole
Registered Member

Click to send john.poole email.Click to visit john.poole's website.Send a Private Message to john.pooleClick to Add JohnLPoole to Your AIM Buddy List.ICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2002
Total Posts : 30
 
   Posted 8/28/2004 12:32 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Well, if they didn't do it, I suppose someone <grin> could create a simple tracking database which might try to make whatever people contributed publicly available so people can assess what's being attended to and what's not. Necessity is the mother of invention.


John Laurence Poole

Editions Poole
www.editionspoole.com
[email protected]

Back to Top

Tyler
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to TylerAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2001
Total Posts : 3586
 
   Posted 8/28/2004 1:51 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
"I also track several open source software projects and they all use some sort of BUG tracking system. I do not remember if MakeMusic does, nor have I seen any postings in this forum that suggest they do."
 
They have an internal bug tracking system using current software designed exactly for this sort of thing. And from the standpoint of feasibility, it only makes sense for it to remain internal. Here's why:
 
1. The database is updated every day with dozens if not hundreds of changes. There are notes about current, unreleased versions of the software and how they've fixed problems, notes about when problems will be fixed, details of a technical nature which relate specifically to program code - and all of this is confidential information. Many (I believe a majority) of the bugs reported in there only exist because of new features that are being developed and haven't been released. The database contains all of the bugs, regardless of whether they are in features that customers have seen or not.
 
2. The amount of work that would be required to create and maintain a second database that excluded all of the confidential information would require several full time employees dedicated to that task alone. Much of the information that would have to be stripped would render the reports useless and make it completely unclear that anything was being done to solve the issues. And with as many changes that would happen on an hourly basis, pretty much no one out here reading would be able to keep up with the changes anyway.
 
3. As far as creating our own database of issues, there are several large limitations. First of all, the bugs that customers report make up a tiny fraction of the number that the QA staff finds and the developers fix. If the hope was to get a measure of how well MakeMusic was doing at fixing bugs, this would be a very misleading result. It's also important to note that the bugs discussed here are not necessarily (and in my experience not usually) the ones that are most often reported by customers. So if the idea was to figure out whether the company was fixing the issues that affect the most customers, it again would be very misleading. Without information directly from the development staff, we'd make mistakes about which problems are which. For example, in the bug database, the EPS problem you mentioned is actually broken up into several different bug records, and fixing part of it would not fix all of it. The opposite is sometimes true as well. Some times very different steps and exhibitions of a bug that would appear to us as multiple bugs are in fact the same bug. Sometimes we report issues that turn out not to be bugs but are instead caused by oddities in our computer setups. Some issues are reported as Finale bugs but instead are limitations of other software or standards (such as the MIDI channel volume "bug" that people have talked about a number of times here). And other times behaviors we report as bugs are actually by design. My point is that even after having worked with the database and having become somewhat knowledgeable about Finale, I could not personally create a database from the information posted here that wouldn't be full of mistakes and hopelessly lacking in accurate meaning.
 


Windows XP, all updates
 

Back to Top

john.poole
Registered Member

Click to send john.poole email.Click to visit john.poole's website.Send a Private Message to john.pooleClick to Add JohnLPoole to Your AIM Buddy List.ICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2002
Total Posts : 30
 
   Posted 8/28/2004 3:01 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
1. Wouldn't tagging the bug and/or text with a "Hide" flag address the need for confidentiality? A complete bug could be tagged with "Hide" making the entire bug unavailable, or a bug could be "public", if you will, where some portions are made available to the customer service people, a smaller set available to the customer, and the sensitive portions of a bug could be tagged for developer access only and not available to the public of the staff that interfaces with the customers.

2. I agree that MakeMusic maintaining a 2nd database for public access would be unproductive. A single source of truth for data is best. Yet, having the tagging referenced in item 1 above could address the confidentiality concerns.

3. Although various scenarios might be "misleading" compared to full access to the internal bug tracking system (and I am not suggesting full access to their internal bug database be provided), it seems what customers have now is a complete void. I do not disagree with the shortcoming raised in your analysis, but something has got to be better than the current situation. Since my filing of the EPS vis-à-vis 2005 earlier today, one person reports that it is has not been fixed. It seems horribly inefficient if the only way I learn if the EPS font issue was fixed in 2005 or not is from someone else who already has the upgrade taking the time to post his results.

What are your suggestions which could improve the current situation of documenting and notifying interested customers of fixes of legitimate bugs?


John Laurence Poole

Editions Poole
www.editionspoole.com
[email protected]

Back to Top

Tyler
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to TylerAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2001
Total Posts : 3586
 
   Posted 8/28/2004 4:52 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
1. The nature of the bug reports and the setup of the software doesn't lend itself well to this at all. Really the only ones that would be fit to show anyone outside the company would be the ones from past versions of the software that were already closed (fixed). There aren't generally speaking for example some fields in a record which would normally be okay for people outside the company to see and other fields that aren't... and even if a field contains no private information initially, it could easily in the future. Many of the bugs don't make sense by their descriptions alone but require additional information which is in other areas of the record. I can honestly say that if I had to watch my wording and spend time making sure nothing accidentally got leaked out while I was working in QA, my job would have taken a lot longer, and in many cases I couldn't have done it in a suitable manner. Internally, the records aren't flagged for certain employees to have access to more information in each record than other employees. Basically, QA, the developers, and tech support have full access to the database. 
 
3. It's not supposed to be a complete void. When a new version or update is released, the readme file contains a list of the issues that were addressed. There might be a few fixes that get by here and there that Mark doesn't get informed of and thus doesn't include, but by in large it's pretty complete. Perhaps you'd like to create a database of fixes listed in these updates? And when it comes to the status of bugs that have not been fixed, really the only way to deal with it is to have tech support communicate what they are permitted to at the current time via direct contact with the customer. You can also request of MakeMusic that they continually update the FAQ's on their website. These occasionally contain information about bugs which people commonly run into and propose workarounds.


Windows XP, all updates
 

Back to Top
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
   
Forum Information
Currently it is Friday, December 13, 2019 5:46 AM (GMT -6)
There are a total of 403,820 posts in 58,165 threads.
In the last 3 days there were 0 new threads and 0 reply posts. View Active Threads