LabVIEW Idea Exchange

HABF?

An acronym for one of my favorite Spolskyisms. Great article, read it.

Background

When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.

Problems with Current Issue Tracking Platform

"Platform" is a generous term for the current reporting and tracking process:

1. The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
2. Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
3. Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
4. Relies on unreliable methods including email, FTP uploads, phone conversations, forums...

Comparing LabVIEW Issue Tracking and Feature Tracking Platforms

Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into.  The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.

I want to see an analogue for Issue Tracking.

Proposed Solution

A web-based platform with the following capabilities:

1. Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
2. Allow embedded video screen captures (such as Jing)
3. Allow uploaded files that demonstrate reproduceable issues
4. Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
5. Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
6. Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
7. The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
8. A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
9. Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
10. An email-based alert system, letting you know when the status or content changes in bug reports of interest ()
11. Same username and logon as the Forums
12. Bonus: Visible download links to patches and other bug-related minutiae

Additional Thoughts

• I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
• I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
• Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.

(Picture first spotted on Breakpoint)

Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.

My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!

The title says it all - I'd like to have the option to inherit my configuration settings from the previous LabVIEW installation (or from a specified path).  Currently I have to do this manually by copying the ini file from the previous version, but I'm never sure whether there will be compatibility issues with the new version of LabVIEW or if there are obsolete settings.  The installer should check for compatibility/obsolescence issues as it creates the new ini file.

Alternatively / additionally, I'd like to be able to specify where LabVIEW loads the LabVIEW.ini file from (which could be located on a network or USB disk).

Within LabVIEW Build Specs you can specify a version for an executable that is built.  You can presently see this from within the Windows add/remove program and there are some funky ways of getting this version with .net or WinAPI calls but you should be able to do this from LabVIEW similar to the app version as shown below.

This should also be within LabVIEW so that it can work from LabVIEW Real-Time as well.

For all of the work the knights of the forum do, I propose that upon retirement they receive a lifetime license to LabVIEW.

1. They deserve it.
2. Their help on the forums for other users cannot be quantified. 

Not sure where I read it on the forums, but I think it stinks that @Ben needs to wait until the community edition is released to have a working copy of LabVIEW.

mcduff