# content
At Automattic, we are requested to do a yearly support rotation. Regardless of our primary role, we periodically rotate into support-facing responsibilities to stay close to users, understand real-world pain points, and make sure our product decisions are grounded in actual usage.

For teams working on WordPress and its ecosystem, this often means spending time in WordPress.org spaces: forums, GitHub repositories, issues, and pull requests. The goal isn’t just to answer questions, but to observe patterns, identify friction, and spot opportunities to improve both the product and the contributor experience.

My support rotation

A couple weeks ago, aligned with the WordPress 6.9 release, I completed my support rotation for the WordPress.org repositories and projects. After replying to some forum discussions and issues. I decided to dive deep into the Gutenberg repository’s issues and PRs.

If you’ve worked in WordPress, Gutenberg or similar large open source repositories before, you’ll now that it’s very easy to get lost. Thus, I started thinking about the best way to extract meaningful information from it. I wanted to understand:

What important bugs we should be fixing.

What feature requests we should prioritize or at least consider more carefully.

What stale issues should be closed or clarified.

What issues we, as maintainers, have unintentionally neglected and should probably respond to—especially to make sure new contributors feel welcome.

To answer these questions, I ended up vibe-coding a new tool called GitAudit. Here’s a very short video showcasing it.

Please give it a try, use it during your triage sessions, and let me know if it’s helpful. I’d also love to hear about any other types of analysis you think would be useful for large open-source projects.

The repository is available here and is open for contributions.

# contentMap.en
At Automattic, we are requested to do a yearly support rotation. Regardless of our primary role, we periodically rotate into support-facing responsibilities to stay close to users, understand real-world pain points, and make sure our product decisions are grounded in actual usage.

For teams working on WordPress and its ecosystem, this often means spending time in WordPress.org spaces: forums, GitHub repositories, issues, and pull requests. The goal isn’t just to answer questions, but to observe patterns, identify friction, and spot opportunities to improve both the product and the contributor experience.

My support rotation

A couple weeks ago, aligned with the WordPress 6.9 release, I completed my support rotation for the WordPress.org repositories and projects. After replying to some forum discussions and issues. I decided to dive deep into the Gutenberg repository’s issues and PRs.

If you’ve worked in WordPress, Gutenberg or similar large open source repositories before, you’ll now that it’s very easy to get lost. Thus, I started thinking about the best way to extract meaningful information from it. I wanted to understand:

What important bugs we should be fixing.

What feature requests we should prioritize or at least consider more carefully.

What stale issues should be closed or clarified.

What issues we, as maintainers, have unintentionally neglected and should probably respond to—especially to make sure new contributors feel welcome.

To answer these questions, I ended up vibe-coding a new tool called GitAudit. Here’s a very short video showcasing it.

Please give it a try, use it during your triage sessions, and let me know if it’s helpful. I’d also love to hear about any other types of analysis you think would be useful for large open-source projects.

The repository is available here and is open for contributions.

# name
GitAudit, a tool to audit large open source Github repositories

# nameMap.en
GitAudit, a tool to audit large open source Github repositories

# preview.content
At Automattic, we are requested to do a yearly support rotation. Regardless of our primary role, we periodically rotate into support-facing responsibilities to stay close to users, understand real-world pain points, and make sure our product decisions are grounded in actual usage.

For teams working on WordPress and its ecosystem, this often means spending time in WordPress.org spaces: forums, GitHub repositories, issues, and pull requests. The goal isn’t just to answer questions, but to […]

# summary
At Automattic, we are requested to do a yearly support rotation. Regardless of our primary role, we periodically rotate into support-facing responsibilities to stay close to users, understand real-world pain points, and make sure our product decisions are grounded in actual usage.

For teams working on WordPress and its ecosystem, this often means spending time in WordPress.org spaces: forums, GitHub repositories, issues, and pull requests. The goal isn’t just to answer questions, but to […]

# summaryMap.en
At Automattic, we are requested to do a yearly support rotation. Regardless of our primary role, we periodically rotate into support-facing responsibilities to stay close to users, understand real-world pain points, and make sure our product decisions are grounded in actual usage.

For teams working on WordPress and its ecosystem, this often means spending time in WordPress.org spaces: forums, GitHub repositories, issues, and pull requests. The goal isn’t just to answer questions, but to […]