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.

Eric

I see this also as a con: you don't have a mean to restrict the tags used, i.e. typos are always possible (e.g. SVCS instead of SCVS), as well as 'false friends' (e.g. FreeMind'sCVS contains SCVS).

• 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".

TBD

list pros and cons...

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)