Dear Saros developers,

one issue has been running in my mind since I saw it for the first time. I'm 
talking of the multiple trackers we own in our Sourceforge space. Currently 
we're talking about no less than four trackers, each with a slightly different 
purpose: Bugs, Documentation Issues, Feature Requests and Refactoring Requests.

I didn't bring up this topic yet, because although I'm quite unhappy with this 
situation on a conceptual level, I did not see any huge practical drawbacks.

But: Yesterday Stefan "moved" a tracker artifact from "Bugs" to "Feature 
Requests" (from [1] to [2]). This clearly demonstrated several disadvantages 
(this is not against you, Stefan :):

 * The fields "Assigned to", "Category", and "Group" and the visibility of the 
"Resolution" field are maintained separately for each tracker. That means that 
e.g. every new project member needs to be added to all trackers manually, to be 
selectable as the artifact's assignee.
 * The field "Tracker" is mutable, which allows a migration from one tracker to 
another. But since the value ranges of the several fields are different for 
each tracker, data loss may result. Additionally I fear that this changes the 
URL of the item as well, because the Tracker id ("atid") is part of the URL. 
The alternative way of a copy-paste "migration" (as Stefan did) is not a real 
alternative: There is no way of backtracking, comments are lost in the 
artifact, etc.


General problems with more than one tracking system:

 * Developers don't have a simple, single access point to gain the information 
they need: e.g. "What are my open tasks?" -- One can use the "Advanced Search" 
and select multiple trackers, but since I see no possibility to save these 
queries (as it is possible in Trac) this is only a workaround and not efficient.


My proposal:

 * Only use one single tracker.
 * There is no need for Documentation Issues, Feature Requests and Refactoring 
Requests to be heavily sub-categorized. Therefor a single new Category for each 
former Tracker ("Documentation", "Feature Request", "Refactoring Request") 
should be sufficient.
 * I know: The migration of the open tasks is a stupid, but feasible work.

Any comments or objections?

Franz


Links:
[1] 
https://sourceforge.net/tracker/?func=detail&atid=843359&aid=3514927&group_id=167540
[2] 
https://sourceforge.net/tracker/?func=detail&atid=843362&aid=3539934&group_id=167540

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dpp-devel mailing list
Dpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel

Reply via email to