21 | | ''Once the triaging milestone is emptied (i.e. all tickets from the former 1.0 and 2.0 milestone are dispatched to either next-major or unscheduled), we could use ''triaging'' as the default milestone for newly created tickets, which should be more useful than the "empty" milestone currently used for this role.'' |
| 24 | |
| 25 | == High-level Workflow |
| 26 | Detailed guidelines can be found on each milestone, but here's how things generally work: |
| 27 | - **minor** releases contain generally bug fixes, no (or only minor) new features; the greater the minor version number, the closer we stick to this rule |
| 28 | - **major** releases contain the great new features, the major refactorings to address design flaws, and so on |
| 29 | |
| 30 | The fate of an individual ticket generally goes along one of the following paths: |
| 31 | - new tickets have **no milestone** set, the Trac developers use that as indicator that the ticket has not been triaged yet //(among other reasons, this is why you shouldn't set the milestone yourself, otherwise you take the risk that the ticket will not be noticed for a while)// |
| 32 | - if we're in the early period of the stabilization of a major release (0.1X.1, 0.1X.2) and the ticket reports a valid //defect//, the ticket will likely go in **next-minor-**0.1X pool of tickets |
| 33 | - from there, a developer eventually picks it and moves it to the actual **0.1X.Y** minor release; factors that influence this selection are the impact of the issue (severity), but also how well the defect is explained and documented, if there's a patch provided or not, ... |
| 34 | - if it's a proposed feature and we like it, or a minor defect we'll take care to fix, the ticket goes in the **next-major-**0.1X pool |
| 35 | - from there, a developer eventually picks it and moves it to the actual **0.1X** major release |
| 36 | - if we don't really like the proposed feature, or think the reported defect is not worth fixing, but we're not strongly opposed to it either, the ticket becomes **unscheduled**; it may eventually move from there to a more concrete milestone depending on the involvement of contributors |
| 37 | - otherwise the ticket is rejected |
| 38 | |
| 39 | You can usually influence how a ticket moves from one category to the other by providing the requested feedback, clarifications about the issue or the code you contributed (about code contributions, see PatchWelcome for details). |
| 40 | |