The Problem

The Core Trac "New Ticket" page is the first point of entry for reporting WordPress Core issues. Currently, creating tickets in Trac doesn't provide strong structural guardrails to help reporters write high-quality tickets. While the user is presented with guidance, nothing really nudges them to follow it. The current text is easy to skip and reads more like suggestions rather than expectations while creating a ticket.
This results in:

• Low-quality tickets
• Slow bug resolution

Idea

We could follow Gutenberg's footsteps and provide a template in the description. The text area could come prefilled with the template.

Even if this template is not added as prefilled text, it could live either in the Test Handbook or the Core Handbook. This would mean redirecting to the relevant page with a template, but users tend to avoid/ignore redirects.

That was generally for bug reports. For enhancements/new features, it would be something similar.

Since these two templates would be separate, this would probably need checkboxes to select before being presented with the relevant form with the prefilled template.

Another Painpoint

As I mentioned earlier in a different issue's comments. #114 (comment)
This is related to the needs-testing keyword for bug reproduction. One approach would be to still allow the reporters to continue using it. Then the Test Team should reproduce the bug, remove the tag according to their findings, and tag with another keyword to move the ticket forward.

While this may not be the Test Team's direct responsibility, this ambiguity affects triage and testing workflows. It may be worth discussing if there alignment, later presenting to the Trac Maintainers.

Also worth mentioning, as suggested by @juanmaguitar in an earlier discussion. It would be helpful to have some kind of guide for reporters explaining the meaning and the intended usage of each keyword. This should ideally live in the Core Trac "New Ticket" page, rather than a redirect to the Core handbook, since reporters skip external links during ticket creation.

My intent is not to enforce workflow, but to help reporters frame their tickets correctly.