Close your issues in Project Management

Questions about MultiCharts and user contributed studies.
User avatar
geizer
Posts: 375
Joined: 16 Jun 2008
Has thanked: 40 times
Been thanked: 38 times

Close your issues in Project Management

Postby geizer » 17 Sep 2011

The number of issues in Project Management has grown. Many of the issues have been resolved, but still get in the way, and as a result:
    • - navigation becomes more difficult
      - Important issues are missed
      - Tech Support & Developer's time is wasted
      - Duplicate issues created by people (I found 4 duplicates today).
      - Issues that are valid for all versions are not given enough attention
Hence I encourage ALL users who post in Project Management:

1. Log-in to Project Management and look at YOUR issues:
    • Image
2. If issues opened by you are resolved and released, then CLOSE them after testing. Image
Attachments
Issued Reported by You.PNG
(4.9 KiB) Downloaded 709 times
Close The Issue.PNG
(11.12 KiB) Downloaded 717 times

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: Close your issues in Project Management

Postby bowlesj3 » 18 Sep 2011

It is a good idea for now.

However, ultimately to me (and as a future feature for the bug tracker) it makes more sense to change the bug tracker to automatically send an email to the creator indicating the issue is resolved and thus closed and if the user wishes to reopen it because their personal testing indicates the problem still exists then they have the option to make a simple button click and if they wish add a comment. I do not feel you can clear the database of these items because the database should be able to tell a user of an older release (which still has the bug) that they can get this corrected by upgrading to whatever release the bug was fixed on (in other words they may not want to come right up to the latest release for whatever reason). I have done that actually. I would store every release that came out and only consider jumping to the one I figure was stable. At the same time if the database knows what release the user is on it could automatically filter out bugs that no longer exist in that release (saving them time reading about corrected bugs). So what I am saying is the bug should have a release number at which it was corrected on and the user should make sure the release they are running on is in the bug tracker associated with their ID. This way they do not see the old bugs. In order to make this work when the bug is in fact not fixed, the user should be able to see old bugs that are out of view in their new release (supposedly fixed) but which are still occurring. So the email that is sent to them should indicate this to them. It is all a matter of enhancing the bug tracker to have more filters for voting etc and at the same time making it simple to operate and understand. Yes, there is no way they should purge this database. Expecting the user to do it by closing after the fact is probably not going to work. However if the MC staff say a bug is fixed and the user does not agree you can bet your bottom dollar that this will get attention from the user.

snoop
Posts: 23
Joined: 22 Oct 2010
Has thanked: 4 times

Re: Close your issues in Project Management

Postby snoop » 18 Sep 2011

I have previously closed issues that had been resolved through a new release but someone in MC support reopened them shortly after. You may want to check with them to see what their motives are.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: Close your issues in Project Management

Postby bowlesj3 » 18 Sep 2011

Question? Where is the term "Released" defined in the bug tracker. I as a user do not feel I can close an issue just because I see a word "Released". That two line paragraph is very vague. To me this problem is a communication problem and to be honest with a new product like the bug tracker it makes a lot of sense that this is occurring (it has to occur is what I am saying). It is not possible for the MC staff to 100% anticipate this situation. It is a great topic to bring up and as I have mentioned in my post, it is all about providing filters and education to the user and at the same time back to the MC staff for adjustments to the system followed by education as to what they want to do in the end (an ongoing process until it becomes so routine that it need not be revisited). Now if release was defined as "you thought there was a bug and you figured it out on your own and you now feel there is no bug" then that is real simple and every one can work with that (it will save the MC staff work in trying to reproduce the bug). Like I said. It is all about making the communication clear. If you want it simple, make it "I changed my mind. Sorry, no bug after all.". That way the 12 year old trading genius who can out trade all of us can understand it. I am not sure if the user can delete the record in this case. I think they can. I also feel that the MC staff should be the only ones to close an issue if in fact there is a bug because they do not want this bug kicking around just because a user incorrectly thinks that it is resolved when in fact it is not (maybe this is why they reopen a bug that a user closed). So this is a different situation. If they can reproduce the bug then it is confirmed as a bug and only they should be able to release or close it (whatever the difference is in those two terms). Sounds like it is time for a bug tracker dictionary. My post below explains in detail how they can create filters that will strip out the clutter of old bugs which are fixed yet allow them to get back to them to see them and allow users that want to no be on the latest release to figure out where to upgrade to.
Last edited by bowlesj3 on 19 Sep 2011, edited 1 time in total.

User avatar
geizer
Posts: 375
Joined: 16 Jun 2008
Has thanked: 40 times
Been thanked: 38 times

Re: Close your issues in Project Management

Postby geizer » 18 Sep 2011

well I wasn't quite sure what the reaction would be after creating the topic. But who knows, maybe this discussion will help to improve the system?
I also remeber that tag "Released" was not used initially in the bug tracker, but introduced later (I may be wrong though). "Released" could be just an alternative tag to "Closed", with the exception that it is initiated by Multicharts rather than the user who reported issue.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: Close your issues in Project Management

Postby bowlesj3 » 19 Sep 2011

Hi geizer,

It is good that you brought up the topic. I had submitted a couple of filter ideas to MC staff before but your bringing this to mind caused me to refine some of those suggestions.

I am guessing that each bug tracker entry (bug or feature) probably already has a beginning version number and an ending version number. I am guessing we just do not see it. They would be much like the examples below.

Code: Select all

Start Version End Version
New feature request 9999.9999 9999.9999
Old bug 2.1999 6.0000
Recent bug (not fixed) 6.0000 9999.9999
New Feature just in 7.0000 9999.9999
I created a few filter ideas that would use these bug tracker version start/end fields.

View all new features implemented and existing bugs too

Code: Select all

If Start-Version <= Filter-Version and End-Version >= Filter-Version then
include it in the list
You can see from this that everything stays in the file but your filters determine what you will see (removing the clutter you complained about). When a bug is closed it gets an end version number change to match the last version it occurred in. I think it should be the MC staff who set this end-version number because they will know the exact number at which it last occurred in. If they have it programmed properly, it will be easy for them since they will be clicking a line in a list of versions of MC and the program will pop the number in to the bug tracker record (no need to key in this long number). If the Version-End is used at the time a user clicks the close button it will not be accurate and future filters that may be implemented will not be accurate.


This would be the filter to see only current bugs to vote on.

Code: Select all

If Start-Version <= Filter-Version and End-Version >= Filter-Version then
If Type is a bug then
include it in the list
Searching for feature requests to vote on

Code: Select all

If Start-version = 9999.9999 and End-version = 9999.9999 then
Include this new feature request item in the list.
Seeing "Start version" / "End version" in our personal submission list (including follow-up).
As far as the user looking at their features and bugs they have reported I feel personally that they should see the "Start version", and "End version" in their list. Three uses:
1/ If they have a huge list maybe they could filter their own list to eliminate what they see from an "End version" perspective. So as an example, if the bug tracker had have been around during version 2.1.9999 I may want to filter out all that old stuff.
2/ Also the person who likes to hold back on upgrading can view their list and see when their bug was fixed using the End-version number and decide where to upgrade too.
3/ A variation on the person who holds back is a situation where the person jumps up to the latest version and finds a problem. They can find the bug in the bug tracker, figure out the starting version for that bug and go back to the version before that bug. In this case they reduce the amount of jump forward and wait for that specific bug to be fixed. I have had this happen 2 times where I had to hold back. Only if the version-End is accurate can this be done.

I have linked this thread post to that other thread I created earlier where I requested a few other more extensive filters.
viewtopic.php?f=1&t=8806

John
Last edited by bowlesj3 on 20 Sep 2011, edited 31 times in total.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: Close your issues in Project Management

Postby bowlesj3 » 19 Sep 2011

So anyways, I was curious, and found I had 2 issues released so I closed them.

Questions remain,

1/ What is going on under the hood here and can we see the version start/end span of a but tracker item? I am thinking that when the MC Staff set the status to released then the End-version (which I mention above for filtering) is set. That is when the filtering should take place rather than when we close it. It we disagree we could open the item from our list and send a comment. If we are correct they would extend the End-Version so it appears in the above filters again.

1b/ Does a status of released currently put the accurate version number on the file so advanced filtering can be used? Maybe they are assigning an accurate version-end number at that time and just waiting for a confirm from the user. As I said before I think it is better for the MC-Staff just to close it themselves and see if the user kicks up a fuss. All-in-all this will provide a much more accurate set of filtering and lead to more people using the bug-tracker since they do not need to go through so much out of date stuff or stuff that does not pertain to them.

2/ Can some of these more advanced filters be provided that I am suggesting? I will not even go in to search for potential votes yet without the filters. I think they did a great job on the project management system and I am sure they will put these filters in so I am waiting. I look at my entries on occasion and no more. When I created my entries I did a few string searches to try and avoid duplicates but I did not sequentially scan the lists.

3/ I figure most users will not remember to close issues and we do not want to be always reminding them. Does it actually create filtering? Is the End-Version it picks up already set by the MC staff and thus is it accurate?

As far as duplicates go I think the advanced filters will help eliminate these if users are made aware they exist and start going into the bug tracker more often to vote. If a duplicate is noticed they can create a comment in the entry to bring it to the attention of MC staff.

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Close your issues in Project Management

Postby Henry MultiСharts » 23 Sep 2011

The project management is a third party system. It is provided "as is".
In this system it is possible to receive email updates on the issues filled and followed by you.
When the issue is posted it gets to the "Backlog" section.
Then it is reviewed, confirmed or rejected, and processed by the PM specialist inside MultiCharts.
When the implementation is scheduled - the issue is moved to the corresponding MultiCharts version.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Re: Close your issues in Project Management

Postby bowlesj3 » 23 Sep 2011

Thanks Henry for the info. I guess if users ask for something and MC staff like the idea an RFC is passed on to the 3rd party and in time it may appear.


Return to “MultiCharts”