Proposal: Rename “invalid”, “worksforme”, and “wontfix” ticket resolutions

Last year, during the core dev chat of May 29th, 2019, I proposed renaming the invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. and worksformeworksforme A resolution on the bug tracker (and generally common in software development) that indicates the bug reported cannot be reproduced. Trac ticket resolutions to something more friendly and less confusing. The reaction in the chat was unanimously positive, so this is now an official proposal for discussion.

The current interpretation of ticketticket Created for both bug reports and feature development on the bug tracker. resolutions, as per the Core Contributor Handbook:

Resolution: Upon one or more commits to the codebase, a ticket may be closed as fixed. Not all tickets result in a commit, however, and may be closed for other reasons:

  • duplicate: The ticket is a duplicate of an existing ticket, which will be referenced by the contributor closing the ticket.
  • invalid: The ticket is not a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., or is a support request.
  • worksforme: The bug reported in the ticket cannot be reproduced. Sometimes, an existing pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party, hook, or feature may render the ticket moot, so the ticket can be closed without further action.
  • wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion.: The ticket will not be addressed. Occasionally, bugs are considered to be acceptable edge cases, and will not be addressed further. This is sometimes used when a request for an enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. or feature has been rejected for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. inclusion.
  • maybelater: Similar to wontfixmaybelater is used for a ticket that, while perhaps not outright rejected, has no current traction.
  • reported-upstream: The ticket is for an external library or component, has been reported in an upstream repository (e.g. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc., and will be addressed there.

More than a few times I’ve seen someone closing a ticket as worksforme after testing a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. because, well, it works for them. When that happens, the ticket has to be reopened with a comment that the patch still needs to be reviewed and committed.

Based on the above, I’d like to propose the following updates:

  • invalidnot-applicable
  • worksformenot-reproducible or cannot-reproduce
  • wontfixnot-implemented

On the technical side, any tickets that are currently closed should keep their existing resolutions, while tickets closed after the change is implemented should get the new resolutions. Some links and TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. reports might need an update to account for the changes.

Even if we move away from Trac at some point in the future, we’re not there yet, and I think clarifying these resolutions would be helpful for the time being. Any feedback appeciated!

Props @desrosj and @jeffpaul for pre-publication review.

#meta-tracdev, #trac, #triage, #triage-team