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