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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dpp-devel