I originally suggested this idea be implemented with a proper database system, which could be published to the web. However what I describe below would be easier to set up and use and still IMHO be very useful to the cause.
If TSS assigned a Bug######.1 to every bug that was reported on the forum (and confirmed to actually exist) then later responded to the posts stating that this bug which had been reported had been assigned the code Bug######.1 then users could;
If they reported the bug or read about it in the forum they could take note of the number and later look on the new release description to see if this bug had been fixed. Some bugs, which bring down MC are of serious concern and users want to know if it is effected before risking an upgrade. Other features they want (once shown to be properly working as found by the bug number) will entice them to upgrade.
If they read the description of a bug on the new release list of bugs they could search the forum for the Bug######.1 to get more info on it from the various people who reported the same bug. It would have to have the prefix “Bug” on the front since searching a number only would bring up all sorts of unrelated posts. It should also be very long such as Bug000001 since a Bug1 search would get Bug1 and Bug10 and Bug 11, etc. The user would simply cut and paste to do the search.
2b/ The user can search the web page with Ctrl+F too.
If a user reported a similar bug then maybe TSS could assign Bug000001.1 for all first reported bugs then Bug000001.2 for any similar bugs and users could search to find both or only one of them. Again a simple cut and paste.
Once the Bug######.1 was first assigned, new users could say simply “I am getting Bug######.1 too”. Or maybe “I am getting Bug000001.1 but not Bug000001.2”. It provides better communication.
TSS would benefit since users can find out serious bugs are fixed for sure and will upgrade which helps to debug the higher releases. It really does not look that good when a user tells their friend “There was this bug in MC that caused it to abort 20 times a day and I have no definite word on whether it was fixed or not so I will not upgrade until the last release when the odds are higher that it has been fixed.” Odds! That sounds like trading the markets. I personally doubt that TSS wants a decision to upgrade to be based upon traders making bets on the Odds.
5/ So that last paragraph leads to another benefit to the users. It will put TSS under pressure to fix the really critical bugs that cause crashes and trader interruptions (or calculation errors across versions) before the less critical bugs such as windows shifting a bit or MC aborting on exit. Ultimately users talk better of MC and influence more users to buy it.
6/ If users forgot to record the bug number or lost it and read about a bug fix in the new release notes they could use the bug number found there to go back and help figure out if this was the bug that they had reported.
7/ It just occured to me the biggest benefit of all. It would give the users more confidence that bugs are not forgotten and would eventually be fixed (if not quickly).
This is very easy to implement since I think excel is good enough for TTS to manage a system like this (see excel columns below) and very easy for the users to learn.
Description (wrap around format)
Version it was fixed on.
Maybe User reporting list (user/version, user/version, user/version)
IMHO, why I think assigning Bug numbers would be very useful
Questions about MultiCharts and user contributed studies.
3 posts • Page 1 of 1
Another advantage to this idea is that if a bug (which is causing serious trading distraction and interruption problems for one or more traders) is not yet fixed, TSS does not want them wasting their time upgrading when they should not. It is the flip side of encouraging them to upgrade by letting them know for sure that certain specific bugs are fixed. Some traders who are making money but not rich can't afford the down time.