Feedback Request: Living Known Issues Document

[Wayne.C]

Started out with LVRT 7.1 and found it to be pretty good.  Made the jump to LVRT 8.0 for my first real project and felt some pain.  LV8.0 had a really bad habit of locking up if you tried to do anything before the development system was fulled loaded on the pc.  Verified this behaviour at a couple of LV classes as well.

Currently using LVRT 8.2 and have found it to be very stable.  Stable is a very good thing as I continue to maintain/enhance a half dozen cFP based systems in my lab.  I continue to monitor the forums to decide when to make the next jump. 

Ben:  I really like the idea of links to examples of problems/workarounds.

[Ray.R]

Excellent idea Ben about having simple examples of workaround solutions.

[muks]

---

Open/Create/Replace Datalog.vi does not show confirmation message when "replace or create with confirmation" is selected
Open/Create/Replace Datalog.vi does not show confirmation message when "replace or create with confirmation" is selected

Workaround—Write custom code to first detect whether or not the file exists and give a custom dialog.

---

Wow there are lot more like this but let me accept that i have started beleiving  that thats the way it should be  i have started living with the bug

[Travis_M.]

Hello everyone,

I have been hesitant to reply until we got more of the feedback because I didn't want my replies to influence any of the feedback, but I think now might be a good time for me to address a handful of the feedback themes I see:

Clear fields for which versions a bug exists in and which version it was fixed in.
Great feedback, we are working on improving this aspect of bug reporting.  I can't say when, but look for improvements in this area in the future.

List issues by category
I think Roy took care of explaining that we were already trying to do this.  If what we are doing needs improvement please let me know how you think it could be improved.

Some LabVIEW Versions are better/more stable/cheaper than others
Some of the points here might be worth discussing, however, this is the topic of another discussion since it not related to the bug fixed list.  Discussing in this thread makes it more difficult for me to turn this discussion thread into real improvements into the way we document our known issues.  If possible, please help keep this thread on topic by discussing the known issues list feedback.  Thanks!

Automatic notification when document is updated
I agree that this would be nice.  We added the "by date" sort to make it easier for you to learn which issues had been added to the list since the last time you checked.  We are trying to make sure the list gets updated a few times a month while the version is active, and we also plan to update the document even after new versions ship.  This way if you haven't upgraded you can still learn about new issues reported in the version of LabVIEW you are working in (how cool is that?).  Also, you can subscribe to this document's feed by clicking the "subscribe" link on the left. There are tools that will allow you to get notification when the document changes.

Simple examples and workarounds
Unfortunately, there is no good way for us to include attachments for issues in this document.  What we are trying to do is to put links to NI Discussion Forums which discuss an issue.  This way if you need more information on the issue or you'd like to discuss you can find the link.  For an example, see issue 42538 on the list.  By publishing the bug ID, it makes it easy to call up NI (or post to the NI Forums) with the ID to ask an AE for more information on the issue.  If you know of an NI forum that discusses an issue and want it linked to the Known Issues Document, let an AE know and we'll add that information to the list (as in 42538).  Feel free to disagree or add further suggestions/input on this.

Generally need more description of problems
The issues that have one sentence titles with the same problem details are the exception not the rule.  In general I believe that there is enough information in most of the entries for you to determine whether or not you think a problem you are encountering is the one you found in the known issues document.  There may not be enough information for you to recreate a problem from the description alone, and if you think there are specific entries that need more description you can let an AE know and we'd be happy to look into the issue more.

More products/modules/toolkits should be included
Agreed, and more will be included.  We believe that documenting these issues is a big help for our users and we'd like to expand this LabVIEW project to multiple products.  Keep a look out for more of these to come.

Hope this helps clarify a bit, please feel free to disagree and/or continue offering feedback on the Known Issues Document in this thread.

Thanks for all the contribution!

[dan_u]

The list is really useful. It gave us good reasons to upgrade to 8.5.1 because 2 bugs crashing a built application were fixed.

What I would like (I think it was also mentioned before) is some filtering of the issues. For instance if I experience a bug in a graph, I'd like to filter by this keyword to quickly see if it's already in the list. Also, filtering by OS would be nice. As a Windows user I'm not too interested in bugs that only appear on OS X.
And of course, filter by issue status (fixed in Vx.y or earlier, open)
The list is already quite long, thus the question also arises when fixed issues will be deleted. If they never are, filtering becomes even more important.

Keep up the good work,
Daniel

[rpr]

So to sum up "upgrade to unleash" the power of labVIEW. But frankly thanx to ben.I think i would not have gone through the list if ben hadnt initiated such a thing.

[pallen]

Having a document like this can be very helpful when you run up against a problem that doesn't make sense. 

It's never nice to hit a bug.  But it is nice to know why something isn't working the way it's supposed to.

Admittedly I haven't had to use this document so far.  But it seems easy to navigate and suggested workarounds have probably been a great help to people. 

[muks]

---

Also, you can subscribe to this document's feed by clicking the "subscribe" link on the left. There are tools that will allow you to get notification when the document changes.

---

Ben i suppose i didnt  notice that.

[Ben]

Thanks to all who have helped out with your thoughts. As argued by Socrates in "Plato's Republic", "It is the user of a thing that is the expert" (paraphrased).

Another aspect of bug tracking fieexes work-arounds not addressed directly....

Frequently behaviour that is un-expected turns out to be an issue with the documentation so documentation CARs get filed. This results in changes to the docs (eventually). This line of thought lead to the following request/suggestion.

We need abetter way to keep up with the doc changes. Here is how I view it.

I read the LV manual back to bak for LV 5.1. I re-read it when LV 6.1 came out and gave us control references. Since then I have read every release note and upgrade note for all of the releases. Even after doing this I have gone to the manual to find things I had not read previously.

I would very much like to be able to keep up on the changes to the manual without having to read it cover to cover for every major release looking for what has changed.

"Back in the day...." when maunuals were printed and distributed in three ring binders, I would recieve updates to the manual that consisted of a set of new/additonal pages plus instructions that read

---

1) Discard page 3 and replace with new page three.

2) Discard pages 5-7 and insert pages 5-9

...

---

While updating the mauals I would look at the new additions. For edits to a page there would be a mark/bar in the margin to highlight were the changes are.

Suggestion:

I would like to be able to do the same thing with the LV manual so I could keep up on the changes without having to re-read the manual (again!).

Ben

[Travis_M.]

Hello again,

Just to address another couple of the points that have been brought up, and ask another question:


The document should filter by OS:
It turns out that the vast majority of LabVIEW issues face all platforms and are not platform specific (I use platform as OS in this context).  There, however, are exceptions.  We tried to call those out in their separate category in the document called "Operating System Specific".  If you check out that category you'll see the issues that only affect a specific OS or configuration.

Also regarding the categories, we've created a "Miscellaneous" category for those issues that don't fit nicely in one of our categories.  This field has the lowest precedence so hopefully there's nothing in there that fits in another bucket.  If anyone wants to offer suggestions for categories for those issues we'll be happy to take them.

We should do better with calling out our changes in documentation
Ben, you are right; frequently we identify situations where LabVIEW has undefined behavior and we then decide whether the issue is a bug or expected.  Many times we decide the behavior is expected and we add it to the documentation.  We have a "documentation" category that is intended for this.  Up until a week or so ago, we didn't have anything in that category.  Look for an entry next time this document is updated; I think we now have one.  Of course, this won't catch all those things you might care about so I'll notify the documentation team here of your feedback.


Finally, I'd like to get your opinion on whether or not you think it would make this document more useful to split it out into 2 or more separate pages; one for the view by category, and another for the view by date (assuming we couldn't use tabs within the same document).  This would make it easier to print and read as the list wouldn't be as lengthy.  If we come up with any other organizational methods it will also help things scale better.  Any thoughts on that?