Triage Gutenberg Issues

Triaging keeps the 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. https://wordpress.org/gutenberg/ repository healthy. You review issues, check whether bugs still happen, add labels, and organize reports so the right people can act on them. You do not need to be a developer or designer.

• Reference: Triage handbook — full reference for labels, closing policies, and escalation
• Connect: Join #core-editor, introduce yourself, share your GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ username, and ask to be added to the triage team

Steps

1. Set up your testing environment. Open WordPress Playground in your browser. You’ll use it to test and reproduce issues.

2. Pick a starter queue. Open one of these filtered lists and work through issues one by one:

   • Issues without a label — easiest place to start, you just need to categorize them
   • Least recently updated issues — prevents important work from being overlooked
   • Issues sorted by comments (none, fewest, most) — surfaces overlooked or stalled discussions
   • Issues by specific block or feature label — for focused triage once you’re comfortable
3. Read the issue. Identify what is broken or missing, what the reporter expected, and what actually happened. Determine whether it’s a bug report, an enhancement request, a help request, or unclear.

4. Search for duplicates. Search open and closed issues for similar reports. If the issue is a duplicate, close the newer one with a comment like “Duplicate of #12345” and add any useful new details to the original.

5. Add labels. Start with a [Type] label ([Type] Bug, [Type] Enhancement, or [Type] Help Request), then add more specific labels like [Block] or [Feature] if applicable. See the full label list for options.

6. Confirm bugs or request more information. If you can reproduce the bug, comment with the steps you used, the environment you tested in, and what you observed. If you cannot reproduce it or the report lacks detail, add the [Status] Needs More Info label and ask the reporter for steps to reproduce.

Contribution checklist

• Triaged at least one issue from a starter queue
• Added a label, confirmed a bug, or requested missing information
• Left a clear comment explaining what you found or what is needed

What happens next

Your triage work takes effect immediately. There is no review step — once you add labels or comments, other contributors can see and act on them.

If no one responds to a question you asked on an issue, wait two weeks, then follow up or close the issue with a note explaining why.

When you’re comfortable with the basics, try focusing on a specific blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. or feature label to build deeper familiarity with one area. You can also join the organized triage sessions listed on the WordPress meetings page.

Help

Stuck? Check the getting help guide, then ask in #core-editor. Include a link to the issue you’re working on.

Further reading:
– How to do triage on GitHub — video tutorial
– Set up a local WordPress instance — alternative to Playground for testing