= Q: This ticket was opened 10 years ago...

 - ... and you still haven't implemented this feature or fixed this bug?
 - ... and are you ever going to finish it one day?

== (short) A: PatchWelcome!

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!

== (long) A: 

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!

Some of the //properties// of "long run" tickets and an explanation of why they are still kept open are:
 - milestone ''next-minor-releases'': fix worthy of being integrated in a maintenance release; no promise made as to ''which'' release that will be
 - 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
 - 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
 - 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

See also TracTicketTriage#Milestone and TracTicketTriage#StatusandResolution.

And as a parting word, such long standing tickets really //may// get done at some point, see {32} (!TODO) vs. {33} (!DONE).