Bug Tracker Report -- The official and comprehensive list

Al_NN4ZZ

Some background first -- As the number of community postings approaches 2,000 and number of "problem" reports approaches 500,  it is getting harder to tell if a particular problem has already been identified. 

Before I submit a problem report I search here and also look at the short list of "known issues" in the release notes.   Sometimes I can find a previous post and sometimes it has been even been reported multiple times.  To get the latest status you have to read all of the posts.  Sometimes they are there but you can't find them.  And sometimes a problem that is "new" to the community forum has already been logged if it was discovered by someone on the FRS team.



Redundant postings could be reduced  if we had a comprehensive list of problems.   It sounds like the "Bug Tracker" is that list.   Generally defect tracking software used by development and QA teams has a lot of information that would not be suitable for general release (e.g. developer, build number, etc).  It also has the the basics like date entered, title, problem description and status.  The good news is all of the tracking programs I've used have a reporting capability that lets you pick the data you want to see in the report. 

IDEA - periodically (monthly?) provide a report from the bug tracker with the basic information that would be relevant for the community.  

USER BENEFIT - better, more complete, and more accurate information. Reduction of redundant problem posts to review.  Easier for the users to find if a problem if it has already been logged.   

FRS BENEFIT -  Reduction of FRS time spent to address the redundant postings.  The effort to run and post the report should be a net savings.  Better communication usually improves customer satisfaction and reduces frustration.  I'm not saying customers aren't happy with the current level of support, it's great, just that continuous improvement is a good thing. 

Regards, Al / NN4ZZ  
al (at) nn4zz (dot) com

Robert -- N5IKD

An additional benefit is that eliminating multiple reports on the same issue will reduce the number of apparent issues to people on the outside looking in or considering joining the group.

Steve-N5AC

I think this is a good idea and I apologize in advance for my long-winded response.  For a long time I wanted an official users group for our radios -- folks to review outstanding ideas and defects and rank them with community consensus.  There are a couple of reasons I wanted to have this in the user world instead of a FlexRadio job.  First, our customers use our products and know what would serve them better than we do.  We work hard to elicit that information, but they are the source of the information.  Second, it is a lot of work for one of us to manage a list like this.

But here's the rub.  We have a few issue tracking systems:  we have the help desk system where you can call with an issue and we will help you with your problem.  We pride ourselves in this capability and we think it is important since our radios are unique or different that other radios on the market and because we want to provide the best customer service in the industry.  We also have an internal problem tracking system.  Our customer support folks can escalate an issue from the customer facing system to the internal system.  

We have a standing weekly meeting to review all the issues in the internal problem tracking system and "dispose" of them -- this means that we either schedule it to be fixed, we report why it's really not an issue (perhaps someone didn't read the documentation or the issue has already been fixed and the customer is on old software), or we put it in the "backlog."  The backlog is a place where issues go that are real, but not something we are going to address right away.  Why wouldn't we fix something right away?  Well imagine that there is a complete spectrum of issues with "I don't like that color of green in that button" to "radio crashes when you tune."  We always schedule and fix the latter ones and often don't have time to do the prior ones right away.  

I think that what you (Al) are asking for is essentially a list of all the issues in the backlog.  There are some issues for us with this.  First, my group owns the issue system and my developers use it to communicate.  When they come in, they go to this system which lists everything they are working on.  If someone tests their fixed issue and there's an issue with it, they will get a report back with the description from the person that tested it.  If it's another developer, there might be conjecture about how a function works, code snippets, references to modules, build numbers, reports from static analysis tools, etc.  Often, there are issues that have no customer facing information at all -- we might say "need to re-architect module **** -- cyclomatic complexity is to high and it's hard to maintain."  In short, the information is simply not sanitized for external dissemination.  A lot of it is developer-speak.

So now we would have to assign someone to sanitize and disseminate the information.  This person would have to look at the details on every issue and decide what stays and what goes.  Then once we provided this information to customers, this snapshot would be old.  Next time we go to do it, we have to figure out which issues we've examined and which are new, etc.  Then there will be the questions -- "it says here that the LSB is using negative frequency, isn't that a problem because there's no such thing as negative frequency?"  If the person that compiled the list doesn't understand DSP we'll have to take time from an engineer to explain the problem, etc.  This is a slippery slope.  

If you ask me: would you rather have another engineer to address the issues or someone to compile and disseminate the list, I'm going to lean toward finding someone to fix issues rather than talk about them.  Isn't this would you would rather have too?

The other point that is missed here is that we don't just work on defects, we also work on new ideas.  There is a big backlog of ideas in our system too.  There are ideas from us and customers that have been entered over the life of the company.  We have to schedule the new ideas in with the defects also so periodically go look at these lists and prioritize items from them to be added to software.

If you'll allow me the moment to stand on my soap-box, I'll say this: I am very interested in business process automation and the value in collecting and using information.  For the FLEX-6000 we created a complete automated test system that logs tons of information about every radio.  With your serial number, I can tell you how your radio performed in it's receiver and transmitter tests, how long each test took, every calibration point taken, the day of the week and time the test was performed, if it took longer or shorter to cool down from a PA test than it's neighbor, etc.  There are probably 1000 data points taken on every radio.  Today we use this information as we are building radios to build them better and test them better.  Our first time quality numbers on the FLEX-6000 are better than anything we have ever achieved and I credit this testing process.  And while something inside me wants to spend all day pouring over the data and trying to optimize the test process and elicit knowledge from the data, I know that we have other things to do and that for today it's not a necessity.  

We're always open to talking about doing things another way and we have implemented a number of customer suggestions in the business process arena.  I'm interested and open to this idea, but for me it looks like a tremendous amount of work for us.  Tim and I already spend just under a million hours a week working and this is the type of project that would land on us.  Unlike some of the large companies I've worked for, we don't have a bunch of folks floating around looking for something to do that I can say "hey, would you mind being the person that works this list with our customers and is the new interface for them to our problem system?"  It would be great if that were the case, but a request like this brought to fruition would take folks directly off of solving the problems.  Again, let's talk if there's another way to do this. I appreciate the spirit in which the idea was presented and ultimately I would like for customers to be more involved in issue prioritization than in the current process.

Steve

Ken - NM9P

Thanks, Steve,

As always your responses are educational and informative.  I am always learning that "I don't even know what I don't know" about this stuff.  But on the other hand, I am learning a bunch about SDR & DSP, too!

Keep up the good work.

Ken - NM9P

Mike K5UX

Well said Steve.  I have worked for small companies in the past and agree that folks at your level have hard decisions to make regarding resource allocation.  I think it is important to keep as much resource as possible on those items that have been identified as "we need to get this one fixed" and also work on future features that will continue to put FRS in the front of the other manufactures. Keep up the good work and as Ken said in his post below, your responses are always educational and informative.

Mike
K5UX