Changes between Version 2 and Version 3 of ThisTicketWasOpenedTenYearsAgo
- Timestamp:
- Jan 4, 2015, 3:02:40 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ThisTicketWasOpenedTenYearsAgo
v2 v3 1 1 = Q: This ticket was opened 10 years ago... 2 2 3 - ... and you still haven't implemented this feature / fixed this bug!3 - ... and you still haven't implemented this feature or fixed this bug? 4 4 - ... are you ever going to do finish it one day? 5 5 6 6 == (short) A: PatchWelcome! 7 7 8 Trac is a collaborative software development effort, and like with any such project, ideas and contributors come and go, but the software lives on as long as it's used and maintained ; if some bug /feature doesn't appear to be worked on, anyone's free to take it up where others have left and finish the job, or propose an alternative: PatchWelcome!8 Trac is a collaborative software development effort, and like with any such project, ideas and contributors come and go, but the software lives on as long as it's used and maintained. If some bug or feature doesn't appear to be worked on, anyone's free to take it up where others have left and finish the job, or propose an alternative: PatchWelcome! 9 9 10 10 == (long) A: 11 11 12 Well, in practice a patch is not enough, even if it meets the appropriateness and quality criteria enumerated in the PatchWelcome page: you need to have a committer to approve it and integrate it in the code base. Depending on the ups and downs of the project life cycle and the time available in the hands of the maintainers, this can sometimes slow down the adopting of new features (consider that added code will most of the time only //add// to the maintenance burden). There's an easy solution to this: be not only a contributor, but become a maintainer as well!12 In practice a patch is not enough, even if it meets the appropriateness and quality criteria enumerated in the PatchWelcome page. You need to have a committer to approve it and integrate it in the code base. Depending on the ups and downs of the project life cycle and the time available of the maintainers, this can sometimes slow down the adoption of new features. Furthermore, consider that added code will most of the time also //add// to the maintenance effort. There's an easy solution to this: be not only a contributor, but become a maintainer as well! 13 13 14 This clarifications enables me to finish by discussing briefly some of the //properties// of these "long run" tickets, and explain why we still keep them opened:14 Some of the //properties// of "long run" tickets and an explanation of why they are still kept opened are: 15 15 - milestone ''next-minor-releases'': fix worthy of being integrated in a maintenance release; no promise made as to ''which'' release that will be 16 16 - milestone ''next-major-releases'': enhancement that fit in the long term vision we had for Trac; still no promise relative as to ''when'' this might happen 17 17 - milestone ''unscheduled'': neither really fits nor is completely at odds with the long term goals; it's more a matter of having a future ''maintainer'' willing to go in this direction 18 - closed as ''wontfix'': only when we deem the proposal is a bad idea and doesn't fit in what we're trying to propose (or if a [TracPlugins plugin] would be more appropriate)18 - closed as ''wontfix'': only when we deem the proposal is a bad idea and doesn't fit in what we're trying to propose or if a [TracPlugins plugin] would be more appropriate 19 19 20 See also TracTicketTriage#Milestone and 20 See also TracTicketTriage#Milestone and TracTicketTriage#StatusandResolution. 21 21 22 And as a parting word, such long standing tickets really //may// get done at some point, see {32} (!TODO) vs. {33} (!DONE) ;-)22 And as a parting word, such long standing tickets really //may// get done at some point, see {32} (!TODO) vs. {33} (!DONE).
