WordPress contributors are currently discussing adopting friendlier terms for some of the trac ticket resolutions to create a more welcoming environment for participants and newcomers. Since trac resolutions are not set in stone, organizations can customize these terms for different workflows.
During a recent core developers chat, Sergey Biryukov proposed that WordPress trac rename “invalid,” “worksforme,” and “wontfix” ticket resolutions to something more friendly and less confusing. The idea was positively received and is now an official proposal.
“More than a few times I’ve seen someone closing a ticket as worksforme after testing a patch 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,” Biryukov said. This particular scenario clearly illustrates how the resolutions can sometimes be confusing for contributors.
Biryukov proposed the following updates:
- invalid → not-applicable
- worksforme → not-reproducible or cannot-reproduce
- wontfix → not-implemented
Others suggested further refinements in the comments of the proposal. Juliette Reinders Folmer noted that ‘not-implemented’ doesn’t seem to capture the full weight of ‘wontfix’ as a decision, because it doesn’t convey anything about the intention.
“The thing which worries me about ‘not implemented’ is that it can be interpreted as an invitation to implement,” Reinders Folmer said. “It doesn’t convey that there is no intention (at this time) to accept an implementation.”
Mika Epstein said they may want to consider having multiple alternatives to ‘wontfix,’ such as not-in-scope, insufficient resources, or better-as-a-plugin.
Peter Wilson suggested the term ‘support-referral’ as an alternative to ‘invalid,’ since many of these tickets are closed due to support requests.
Goodbye, ‘Wontfix’
‘Wontfix’ is a somewhat polite way to say “forget about it” to someone voicing a concern or a suggestion that doesn’t fit with a project’s goals. It is broadly used and understood throughout the industry, and has sometimes been wielded as a gavel to shut down conversation in heated discussions.
The experience of submitting an issue that is closed with the resolution ‘wontfix’ is so visceral that it is often used in a humorous context outside of software development.
For project maintainers who are handing down ticket resolutions as edicts, terms like ‘wontfix’ and ‘worksforme’ have a certain irreplaceable, incisive charm to them. On the other hand, it’s easy to see how these terms might be particularly irksome, especially for new contributors.
Contributors are still brainstorming alternative ticket resolution terms. Anyone with suggestions can jump in on Biryukov’s proposal. As long as WordPress core is still using trac for development, terminology that is clearer and more welcoming may help make the requirement of using trac more friendly in general.
“I know we plan on moving away from Trac at some point, but we’re not there yet, and I think clarifying these resolutions would be helpful in the short term,” Biryukov said.
Some might argue that moving WordPress core development to a platform like GitHub or GitLab would do a great deal more to make it a friendlier contribution experience. Earlier this month, Matt Mullenweg was asked during a virtual Q&A if there has been any progress in moving WordPress development to GitHub.
“No progress there yet, since a lot of the active development has already moved to Github and the Gutenberg plugin, there’s been less pressure on migrating the Trac-based tickets and workflows,” Mullenweg said.
It happened to me as well to write and document on the track some pretty visible bugs and the answer has been that it was supposed to work like that, with hundreds of developers reporting that problem as a clear bug. WordPress core devs think they are God even when publishing pieces of clearly buggy code.
” This is broken” – ”
nah, it works as it’s supposed to” . Ticket closed.
If it wasn’t for commercial reasons of costs, I’d rather go 10 years back to use my own cms.