Talk:Handling trackers

Using "pending" status for issues solved in CVS

Dimitry suggested we could use "pending" status of an item to mark issues solved in CVS. Currently all pending issues are automatically closed after 60 days, but this setting can be changed.

1. Con: It violates the definition of "pending" used by SourceForge[1], according to which "pending" is a synonym to "author action needed", meaning that the author of the item should provide further information so that the team can solve the problem.
2. Pro: It enables developers to quickly filter issues solved in CVS from those not solved at all. SourceForge does not provide any other suitable state, the other ones being "open", "closed", "deleted".
3. Con: New users coming to see the trackers see only open items, not those pending, as I have just verified. Those using the stable version will thus post duplicate entries; presumably many of them will use the stable version.

--Danielpolansky 03:16, 14 Jul 2007 (PDT)

Tracker system should first help the developers to manage issues so that the product quality can be insured. Easy filtering of solved and to-be-solved issues on the status is very important. That's why already solved issues should not remain "open". --DimitriPolivaev 03:31, 14 Jul 2007 (PDT)

I have modified my original post above to emphasize your point of view. I understand your answer as saying that you value the pro of 2 more than the con 1 and con 3. I am not sure I share this preference. Finding a solution that has fewer cons would be better. Developers are not the only users of the tracker system, so their requirements should not be per default put above the requirements of those who post the issues, IMO. --Danielpolansky 03:49, 14 Jul 2007 (PDT)

We could also use status "closed" with resolution "fixed" which should be changed to "accepted" after when the release is published. --DimitriPolivaev 04:06, 14 Jul 2007 (PDT)

That solves the con 1. What about the con 3? Anyway, setting to closed issues that are in some beta version, not with the last stable version, seems fine to me. Whoever downloaded one beta is probably willing to download another beta or RC. But these issues would be set to solved only after another beta or RC is published. All right?

So the only items now in discussion are bugs and requests in the last stable version that have been solved in CVS. What about them? Setting them to closed would still cause that people would not see them in the tracker. --Danielpolansky 04:20, 14 Jul 2007 (PDT)

Why not? Everyone can select an option to see the slosed items too. I think that the expected version with the bug fix should be mentioned in the detail field. If last published version is say 0.9.0 beta 9, but the issue is closed with relution "fixed" and the details informs that the bug fix is done in 0.9.0 beta 10 (11, 12...), there is no way to misunderstanding. The tracker should always reflect the real situation, so letting the issue "open" althaugh it has been fixed is less nice for me. --DimitriPolivaev 04:46, 14 Jul 2007 (PDT)

Tagging of issues

Issues - bug reports and feature requests - can be tagged in their title, by adding the tag surrounded by brackets to their title. For instance, bugs solved in CVS can be tagged with (SCVS), and highly requested features can be tagged with (HRF). The tags used by the FreeMind team can be documented here, resulting in having well-defined set of tags instead of confusion.

• Pro: Tagging is flexible, unlike the use of categories and other attributes.
• Pro: SF bug tracker provides only two generic attributes: group and category. Tagging makes more logical attributes possible.
• Con: There is no way to restrict the tags used. (Eric, edited by Dan)
• Con: Tagging is vulnerable to typos, like "SVCS" instead of "SCVS", and 'false friends', like "FreeMind'sCVS" containing "SCVS". (Eric, edited by Dan)
• Con: Tagging uses up the title length, necessitating the shortening of the title in some cases.

--Dan Polansky 02:13, 24 Oct 2007 (PDT)

Tagging of issues (counter-proposal based on groups)

Trying to verify certain bugs, I had to fight with the fact that some were already fixed by Dimitry in CVS, and I had no mean to filter them out, effectively or at least visually.

I think, would we use "groups", we could greatly improve things:

1. items without group or with group "FreeMind 0.8.0" can be checked by me (or other helpers with sufficient rights), and closed if issue doesn't appear anymore in the latest beta, else group be changed to "FreeMind 0.9.0".

Ray, are you able with your current rights to change the group of an item? If yes, you could help :-)

2. items with group "FreeMind 0.9.0" can be fixed by a developer, then moved into group "Fixed_In_CVS" (yet to be created).

3. testers check items with group "Fixed in CVS", and close if OK (after next release), else setup back to group "FreeMind 0.9.0".

Pros and cons:

• Con: Users entering the bug tracking system see per default the items in the group "FreeMind 0.9.0", filtering away the issues solved in CVS. That may easily lead to the creation of duplicate bug reports. --Dan Polansky 11:15, 25 Oct 2007 (PDT) That is false. --Dan Polansky 16:59, 25 Oct 2007 (PDT)

Ewl 04:43, 25 Oct 2007 (PDT)

Response: at least consistent naming

Okay, so I accept that you do not like the flexibility of tagging. Then please, create at least a set of groups that is named consistently. For instance:

1. V0.8.0
2. V0.9.0
3. V0.9.0 - Fixed in CVS

or

1. FreeMind 0.8.0
2. FreeMind 0.9.0
3. FreeMind 0.9.0 - Fixed in CVS

--Dan Polansky 10:53, 25 Oct 2007 (PDT)

OK with me, only "con" I see is that we would have 2 groups per release. Ewl 11:44, 25 Oct 2007 (PDT)

Proposal by Eric on policy

For each release being developed, we create two groups: one "FreeMind X.Y.Z" and one "FreeMind X.Y.Z - Fixed in CVS". We then use the groups in the following manner:

Note

for sake of simplicity, we assume X.Y.Z is the version being currently developed, and A.B.C an older version of FreeMind.

1. items with no or with older group like "FreeMind A.B.C" can be checked by helpers with sufficient rights, and closed if issue doesn't appear anymore in the latest beta/RC of X.Y.Z, else group is changed to the current version "FreeMind X.Y.Z".
2. items with current version group "FreeMind X.Y.Z" can be fixed by a developer, then moved into group "FreeMind X.Y.Z - Fixed in CVS".
3. testers check items with group "FreeMind X.Y.Z - Fixed in CVS", and close if OK (after next release), else setup back to group "FreeMind X.Y.Z".

-- Eric L. 12:19, 26 Oct 2007 (PDT)

Ray's Comments

I think that the groups are a good way to do this. It's certainly worth trying out and seeing how well it works for us. We can always try something different if this doesn't work.

I prefer the groups over the title tagging for all the reasons others have given, but especially because of the problems with spelling errors and consistency.

If it turns out that we find this is insufficient, it is possible to look at other tracking systems, such as bugzilla, but I think our time is better spent getting the release done. Really big process changes, like using a new bug trackign system, are best started at the beginning of a new release cycle.

Ray