Our Awaiting Contributions milestone contains 480 tickets, of which 141 are classified as bugs, with the rest (339) as enhancements. I propose that we close ~260 of enhancement tickets to help make our project more sustainable.

In a recent post, I announced some Trac workflow changes, and alluded to a problem with the “Awaiting Contributions” milestone.
Any bug report that the project hasn’t fixed in a release, or feature suggestions we haven’t implemented, or those that we hadn’t made a decision on whether to implement or not, have eventually ended up in the “Awaiting Contributions” milestone. This milestone tends to be one-way; relatively few tickets have ever made it out into an actual release.

260 of the 339 “Awaiting Contribution” enhancement tickets have not been modified since December 2016 (see list here); this means no edits, no patches, and no comments.
I believe this is because the enhancement tickets have a variety of relevance: some are good ideas that fit the project, some are good ideas but perhaps don’t fit the project any more, and some are ideas that might fit the project better in the future. Very few people know which new features might be accepted today. Historically, we have not had the discipline and the right processes in place to make hard decisions.

Are good ideas still valuable even if no-one has wanted to work on them, years after they were shared? Of course they are, but more importantly — more realistically — we will never be able to implement even a small percentage of these enhancements. We would not be saying “no” to the ideas, just being honest with ourselves and recognising that is unlikely that we will ever have enough people to implement them.
There is a psychological backlog to this number of tickets; it’s a weight on our shoulders, and for the average WordPresser, it might suggest that the project is not actively maintained.

I suggest we close these inactive enhancement tickets so we can start over, and repeat this process every year. Yes, it’s a cull. The enhancement tickets from 2017 onwards are recent enough that they might be more relevant than the older tickets, and few enough that we can thoroughly re-review these over the year ahead.

I am not proposing to close the bug reports in the “Awaiting Contribution” milestone, as they merit re-review. If I felt inclined to fix a bug, it’d be great to have an audited backlog of bug reports to pick from, with the confidence that they are still relevant, and that they contain enough direction on how they should be fixed, to be sure that my contribution would be accepted by the project.

Regular contributors, I’m looking forward to your feedback.