Changes between Version 57 and Version 58 of TracTicketTriage
- Timestamp:
- May 3, 2010, 1:53:38 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracTicketTriage
v57 v58 24 24 * Don't modify a milestone as ''anonymous'' and without a reason. 25 25 * If adding an enhancement request ticket, don't set the milestone to a bugfix only release (e.g. 0.10.5). 26 * If the feature is more or less a blue sky idea, then use [milestone:2.0]27 * If the bug or feature seems doable in a reasonable time frame, but doesn't seem to fit in the current schedule, use [milestone:1.0]28 26 * If there's no milestone corresponding to a past or future Trac release which seems to be adequate, but the ticket is nevertheless valid and has to be processed further, then the milestone can be set to [milestone:"not applicable"]. This rule is needed as long as we don't have a better way to distinguish among triaged and non-triaged tickets. 27 28 * //If the feature is more or less a blue sky idea, then use ![milestone:2.0]// 29 * //If the bug or feature seems doable in a reasonable time frame, but doesn't seem to fit in the current schedule, use ![milestone:1.0]// 30 31 // Note: the above two points are no longer true, as we're redefining the triaging rules between milestones; see RoadMap and googlegroups:trac-dev:fcf1de28cc8a9c49 // 32 29 33 30 34 See also report:35 and report:36 for the tickets that ''don't'' fulfill the first two requirements and that should be corrected one day.
