Feedback Request: Living Known Issues Document

[muks]

---

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

---

Yes  i am for it.

[beuvink]

Great list! I was waiting a long time for it. Now I have a place to look for strange effects I cannot explain. (is it me or labview?)

Problems such as http://forums.ni.com/ni/board/message?board.id=170&message.id=315211&requireLogin=False take a long time experimenting until finally it becomes clear that this is a fact-of-life (for now).

Is it possible to make the 'reporting of issues' more clear?

[Travis_M.]

It is good to note that if you are reporting a bug to the NI forums, we strive to have someone from NI acknowledge the bug, and provide a bug ID number for the issue.  With the volume of posts to the forums some things fall through the cracks...  There are a couple of things you can do about that.  One thing you can do is to link your bug report to the Monthly Bug Forum which will increase the likelihood that the issue will be turned into a bug report (this is what I recommend doing with the forum you linked).  Another option is to report the problem directly to support in your region by contacting AE (phone, email, etc...).  If you do that, be sure to get a bug ID and post it back to the forum.  If all else fails and your forum is 'stalled', you may want to post a gentle 'reminder' asking if anyone else has found the bug, if an AE could take a look at the issue, etc...  We can't post every reported problem to the known issues list; we try to pick the ones we thing people are most likely to encounter or ones that are particularly nasty, so it's possible to report a bug and not see it in the list.  If you have that ID number, you can always call your local support office and ask about it and they should be able to help you get information.  Adding this sort of information to the list documentation section might be helpful, thanks for the feedback!

[Ben]

Thanks for the reply Travis,

You wrote;

" We can't post every reported problem to the known issues list; we try to pick the ones we thing people are most likely to encounter or ones that are particularly nasty, so it's possible to report a bug and not see it in the list.  "

Judging by the CAR increments I have seen in asingle day, I have to guess that there are many more bugs that are ID'd internally by NI that we never experience. So I really don't wnat to see ALL of the bugs,

BUT

Could you ensure that all publicly posted bugs be included in the LKID ?

Again thanks to everyone involved involved with keeping us informed!

Ben

[Roy_F]

---

Ben wrote:

...Could you ensure that all publicly posted bugs be included in the LKID ?

---

The primary reason we don't post all publicly reported bugs is mostly trying to reduce noise. If we think including a bug is more harm (in the way of noise) than help, we leave it off. There are numerous considerations that go into arriving at that conclusion. If the odds of someone encountering the problem are rare or extreme (e.g. enter a name for a VI that is more than 32,000 characters long will crash LabVIEW), we might not include it. If there is no value in forewarning a user of an issue, we will not include it (e.g. a dialog box field label is misspelled, but still recognizable).

As for CAR numbers being spaced out a lot - You are on the right track. We use CAR for all NI products, filing bugs that exist in released product and those that just exist in a development branch, and for tasks that must be completed, such as an action item from a code review. So yes, the number we create in a single day can be quite large.

Roy

[Travis_M.]

Hello everyone, we have updated the format of the Known Issues document for LabVIEW to include a couple more fields and we've split the two tables into two separate documents to make it a bit easier to find the information you are looking for.  I hope you like it!

LabVIEW 8.5.x Known Issues

LabVIEW 8.5.x Known Issues by Date

LabVIEW 8.6 Known Issues

LabVIEW 8.6 Known Issues by Date

Edit: I also added a document which describes what each category means.  You'll notice that Upgrade Issues is now split into two types of upgrade issues.  Read about it here.

Message Edited by Travis M. on 12-02-2008 04:29 PM

[TCPlomp]

Travis, I am missing at least one issue:

Can't change decimal sign in timestamp

CAR 4I0EE2BQ

See here http://forums.ni.com/ni/board/message?board.id=170&message.id=299004&query.id=433609#M299004

Ton

[Travis_M.]

Hello Ton,  Thanks for bringing this issue to our attention.  Unfortunately, we can't document every issue that is reported; but we do try to focus on the most commonly or more severe problems.  I found this CAR in our database, and I'd like to discuss it further and discuss its inclusion in the Known Issues Document.  I'll reply to the thread it was reported in sometime today.

thanks-

Message Edited by Travis M. on 12-09-2008 09:15 AM

[TCPlomp]

The list is a little bit out of date (or incomplete).

Travis mentioned:"The issue should appear the next time the known issues document is updated"

However there is nowhere to see when the list is updated.

And I think that when a car is generated there should be feedback to the contributor, the list is a great tool for that.

You could even set up a page with 'rejected bugs'.

Ton

[Travis_M.]

Hello Ton,

Thanks for the great feedback. The best way to approximate the last update date is to take a look at the known issues by date document and look at the date of the last entry.  That is typically the last update date +- 5 days.  That being said, you are right -- it has been a while since it's been updated.  Part of the reason for that is that I have just recently moved into another role in R&D and am no longer working with LabVIEW-support related duties so the project hand-off has added to the delay (I do know for a fact that they are working hard to get another update of the document soon).

I agree with your suggestion that having a "last update date" is a really good idea for the known issues list.  I'll make sure the new person who works with the document gets that suggestion.

Thanks for contributing, and keep the feedback coming!