Feedback Request: Living Known Issues Document

[chris.b]

Hey Ton!

On the top left of the Known Issues List page, there should be a "Publish Date," the last date the document was updated.  Thanks for your feedback!

Message Edited by chris.b on 02-03-2009 01:14 PM

[Marc Blumentritt]

Hello,

I just stumbled recently over this list while looking for a solution to a problem (Digital Display Legend Doesn't Adjust for Number of Plots in Executable). Great list, now I know, that this is a bug of LV.

It would be nice, if I could somehow vote for a fast solution. Of course every bug should be solved, but time is always short and some bugs are just pushed from version to version without a real solution (like the digital display bug). Giving the LabVIEW community a method of saying that "this bug should be solved very fast" would be cool. Perhaps something like "inverted" kudos?

Regards,

Marc

[Roy_F]

---

Marc Blumentritt wrote:

It would be nice, if I could somehow vote for a fast solution. Of course every bug should be solved, but time is always short and some bugs are just pushed from version to version without a real solution (like the digital display bug). Giving the LabVIEW community a method of saying that "this bug should be solved very fast" would be cool.

---

Excellent idea. We have to make a lot of decisions as to which bugs will get corrected and which deferred to a later release, so knowing which our customers would rather have fixed would certainly be a win-win situation. We already give all bugs that are documented in Known Issues a bump when compared to any that we have which were not reported by a user. My hope is that we are already evaluating bugs correctly and fixing the ones most important to our users, but constructing a way to either validate that guess or get specific corrections can only be a good thing.

Thinking, try to figure out how we could make this happen right now with existing tools - Perhaps a thread titled "Vote for bugs to be fixed in 2010" with one post for each bug in the known issues list. We could lock the thread so others can't post (to keep it from running off course or having battles over issues), but instruct users to kudo the bugs they most want fixed. Those that garner the most votes could be given "extra attention". We would be able to fix a fairly high number of these, but not all and perhaps not even the one with the most votes. Bugs that require a refactor or rearchitecture can require multiple releases to fix (implement an enabling piece in one release, then another or the final piece in the next release).

A slight deviation to the above is to allow users to create this thread now and post the bugs they want fixed - something similar to the monthly bug threads that are done now. The thread will almost certainly run amuk a bit, but as long as it is not done so much as to inhibit others from participating and voting, perhaps that's OK. The bug thread lists have no literal restrictions and they work fine. The only difference I see here is that specific bugs getting fixed would almost certainly evoke more passion and emotion amongst some people - not necessarily with a good result. For example, "bug xxxx means a lot to me and it's not getting enough votes; you people don't understand".

Long term, I would obviously just prefer that we tie this to the Known Issues List itself, but I don't see that happening anytime soon (maybe though, I haven't spent much time thinking on this yet, or solicited help - I'm surrounded by a lot of bright people). 

Thoughts?

Roy

[Travis_M.]

One other quick thing to point out is that if a certain issue has a particularly high impact on your project it would help us in R&D to understand that impact so that we can better prioritize the bugs to fix.  If you think you are such a situation feel free to call up an AE here and describe the impact of an issue on your project and ask the AE to add that information to the bug report and notify R&D with the updated information to evaluate for upping the priority.  Many times we see an issue in R&D that is reported by someone else (such as an AE), and from the bug report alone it is hard to get  a clear understanding of the impact of that issue.  Having a real-world example of the impact can help remove some of the guess work we go through when prioritizing those bugs to be fixed each release.

Thanks a bunch for taking the time to make suggestions for improving this process!

[Marc Blumentritt]

---

Travis M. wrote:

One other quick thing to point out is that if a certain issue has a particularly high impact on your project it would help us in R&D to understand that impact so that we can better prioritize the bugs to fix.  If you think you are such a situation feel free to call up an AE here and describe the impact of an issue on your project and ask the AE to add that information to the bug report and notify R&D with the updated information to evaluate for upping the priority.  Many times we see an issue in R&D that is reported by someone else (such as an AE), and from the bug report alone it is hard to get  a clear understanding of the impact of that issue.  Having a real-world example of the impact can help remove some of the guess work we go through when prioritizing those bugs to be fixed each release.

---

Could you please point out what is the best method to contact AE (and by the way, what does AE mean?)? I would like to get the mentioned bug fixed.

Back to the thread: I like Roy's idea of a locked thread as a work-around as long as there is no way to vote for bugs directly in the "living Known Issues Document".

Thanks

Marc

[tst]

I like the bug voting idea, although without restricting the users, there's nothing preventing people from voting for every single bug.

I think the best way to implement this would be to create another board where each thread is for a specific bug. This way you could have a discussion for each bug if necessary. Only NI personnel would be allowed to start threads (similar to the feature feedback board) so that someone from NI would have to be responsible for adding threads to the board. You could lock threads when you don't want people to touch them anymore (e.g. if the bug was fixed or rejected).

Another option is to create an idea exchange for this, but I'm against this because the only real advantage it has is the status of the ideas (which could be implemented using tags) and it has a number of significant disadvantages.

[Roy_F]

---

tst wrote:

I think the best way to implement this would be to create another board where each thread is for a specific bug. This way you could have a discussion for each bug if necessary. Only NI personnel would be allowed to start threads (similar to the feature feedback board) so that someone from NI would have to be responsible for adding threads to the board.

---

We already have this (mostly) with the monthly bug threads. There is a thread for each month. There is one post for each bug with a link to the thread that discusses that bug. No discussion of the bug is permitted in the monthly bug thread itself. This is all user created, no formal restrictions, just documented ones and nudges are posted when someone strays off course (e.g. starts discussing the bug).

As for people voting for all bugs - no problem - that just washes their vote out entirely. There are numerous problems possible, but none really worry me too much. I think the worst that could happen here is that we waste a little time on this process and don't get the value out of it that we wanted; i.e. we fixed some CARs that have significant benefit to users which would not have been fixed otherwise.

Roy

[tst]

I prefer a separate board for this to minimize the amount of noise and to have order. This will allow us to discuss bugs and see when things are updated. I'm assuming it shouldn't take much work for Laura to set one up.

In any case, this entire thing is useless if NI doesn't commit to it. If you're comfortable with saying "This is an experiment. We'll try it out for a few months and see how it works out and if it doesn't then we'll shut it down", then YOU will need to get the ball rolling. Are you willing to do that?

[Roy_F]

I'm willing to committ to "something", I just don't know what yet. Let me think on how best to get this. I really want to tie this to the known issues list somehow. I want low overhead to participate. I want something visible. I want, I want, I want...

Perhaps I can get there by tweaking things around a bit, tools or process. I'll propose something by the end of next week.

[Roy_F]

---

Marc Blumentritt wrote:

Could you please point out what is the best method to contact AE (and by the way, what does AE mean?)? I would like to get the mentioned bug fixed.

---

Just realized we hadn't answered your questions.  

AE - an acronym for Applications Engineer. When you call or email support, you will be connected to an AE. 

Support - Go to ni.com and click on Support or just enter ni.com/support. When you request support, a Service Request (SR) is created to track handling of the support.

CAR - Corrective Action Request, the name we use for our bug tracking software and for bugs filed in that application. We'll say things like "I'll CAR it" - means to file a bug. "I CARed it" - a bug was filed. CAR ID - the number we use to identify a bug.

Roy