Tag Archives: triage-team

Sergey Biryukov 3:35 pm on June 24, 2020
Tags: , , , triage-team   

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 WordPress.org Plugin Directory https://wordpress.org/plugins/ 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 wontfix, maybelater 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. https://wordpress.org/gutenberg/), 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:

  • invalid → not-applicable
  • worksforme → not-reproducible or cannot-reproduce
  • wontfix → not-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

marybaum 4:59 pm on July 19, 2019
Tags: , , , , , strings, , triage-team   

Dev chat summary: July 17

@earnjam led the meeting. @marybaum took notes and is writing this summary.

Announcements

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/ 6.1

@earnjam announced the release of Gutenberg 6.1 last week. New features include animations/motion to 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. reordering, improved messaging for REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. errors and more.

Check out the release post for more details: https://make.wordpress.org/core/2019/07/10/whats-new-in-gutenberg-10-july/

Look for version 6.2 RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). to land next week.

PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher Coding Standards

@pento posted a followup to some proposed coding standards changes from a few months back.
See the decisions on these changes here (they might surprise you!): https://make.wordpress.org/core/2019/07/12/php-coding-standards-changes/

And keep in mind these affect only the code for WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. In your own Themes and Plugins, use the coding conventions that make sense for you.

Releases

5.2.3

With four tickets in the queue and none of them affecting functionality, it’s still not clear that they warrant a separate 5.2.3 release. Scheduling for that is still pending further info on a roadmap for 5.3, which should land in early fall.

5.3

As yet the Core team is progressing on current open tickets — there are 57 in the queue — while @chanthaboune continues gathering data from component maintainers on feature priorities for 5.3.

Component maintainer updates

Core-media

@azaozz asked for more eyes on #40439.

If you can help test, please check out the ticketticket Created for both bug reports and feature development on the bug tracker. or head to #core-media.

Site-health

@clorith pointed to the call for input for bumping the PHP recommendation and said that soon a Make blogpost will outline next steps—and next versions.

For now, the site-health team isn’t looking to raise the hard minimum. This will be a soft bump up to nudge users toward the minimums that will follow.

Open Floor

Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team

@joyously asked about progress from the Triage Team, and the responses came from several quarters.

@desrosj posted a link to his three-month summary: https://jonathandesrosiers.com/2019/06/wordpress-triage-team-3-month-reflection/ and plans to post more often on https://make.wordpress.org/updates.

@karmatosed mentioned that Design holds two triages a week, and that from where she sits, triage seems to be going gangbusters and spreading across the WordPress Project.

@azaozz pointed the group to his efforts on TinyMCE: https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&component=TinyMCE&order=priority

@marybaum mentioned having been in an accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) triage last Friday.

Gutenberg Phase 2

Newcomer @Lu asked about the timing of Gutenberg Phase 2, with a particular interest in widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. blocks. @earnjam answered with a summary of the release discussion earlier in the chat.

Strings

@marybaum asked the group for their thoughts on a more systematic, global approach to the copy in strings.

For now, the group agreed to have #meta add two keywords to tickets—needs-copy-review and has-copy-review.

Props to @garrett-eclipse, who opened meta#4609 and its counterpart meta#4610 on the spot.

Right at the close of the official chat, @audrasjb linked to https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance

#dev-chat, #gutenberg, #releases, #strings, #triage-team

#summary

Jonathan Desrosiers 9:06 pm on March 13, 2019
Tags: triage-team   

Triage Team Meeting Summary – March 11, 2019

The following is a summary of the Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team meeting for Monday, March 11, 2019 that took place in the #core room of the Making WordPress Core Slack instance. A full transcript of the meeting can be found here. For more information about the Triage Team, check out the initial blog post.

Primary Goals

The primary goal of the team is to go through all open tickets in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. to review, triage, and prioritize each one, bringing the number of open tickets down as a result.

While this process is ongoing, recommendations for improvements to the documentation and/or ticketticket Created for both bug reports and feature development on the bug tracker. workflow (such as a new keyword) can be made to make the process go more smoothly, but this should be secondary.

Team Members

Anyone can be a part of the team! But, a few people have stepped up to help lead this effort: @desrosj, @chriscct7, @SergeyBiryukov, @karmatosed, and @designsimply. All are available for any questions related to this effort. These team members are in place to make sure that all disciplines are represented in this effort.

Component maintainers are also great resources for help and guidance. A full list of component maintainers can be found here.

Who Can Triage Tickets?

The term Bug Gardener has been used in the past. Triaging and Bug Gardening are really the same things. The team was created to coordinate the effort of going through all open tickets. But, anyone can triage tickets.

Here are tasks that need to be performed on every open ticket:

  • For bugs, test to verify that they are still happening in the latest version of WordPress.
  • Check that the purpose of the ticket is still relevant/valid (changes introduced elsewhere after the ticket was opened may – have rendered some tickets unnecessary).
  • Make sure the ticket has enough information to be properly evaluated.
  • Make sure the keywords on the ticket are accurate.
  • Test patches to make sure they still apply to trunk.
  • Test patches to make sure they still fix the issue.

You can also create patches if that is in your skillset. Any effort to resolve or move a ticket along.

If you are a component maintainer and want some help going through your tickets with component contributors, reach out to one of the team members mentioned above and a date and time can be set for a ticket scrub.

Where to Start?

Getting started will depend on your own personal level of comfort. Here are some areas to jump in.

Newer Contributors

More Seasoned Contributors

  • If you are a committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component., tickets marked commit.
  • Tickets requiring developer feedback.
  • The Ancient Ticket Report.

If you are a component maintainer or frequent contributor to a specific component, working through a component’s ticket backlog is also a great place to start. Being highly familiar with parts of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will help when going through those lists.

Some Tips

  • If you have follow up questions for the person that opened the ticket, make sure to use the reporter-feedback keyword.
  • If you are unable to reproduce an issue or think a ticket should be closed but want to give others a chance to weigh in, use the close keyword.
  • If you think all aspects of the proposed changes have been considered and a ticket is ready, add the commit keyword.
  • Make sure has-patch, has-unit-tests and needs-patch, needs-unit-tests keywords are correctly assigned for each ticket.
  • If the ticket needs UIUI User interface/UXUX User experience feedback, use the needs-design-feedback keyword.
  • If a ticket needs a specific design, use the needs-design keyword.

Tracking Efforts

If you are planning to contribute time to this effort, please comment below or inform one of the team members noted at the beginning that you are taking part. This allows the team’s progress to be accurately tracked.

Next Meeting

There are no further team meetings planned at this time. When the need for one arises, a date and time will be posted accompanied by an agenda.

Happy triaging!

#triage-team

Jonathan Desrosiers 12:50 am on March 1, 2019
Tags: , triage-team   

Introducing the WordPress Triage Team

In Matt Mullenweg’s 2018 State of the Word, he detailed 9 projects that he envisioned being tackled by individual teams in 2019. These projects were then posted to this blog for further discussion.

The last item on the list (which was in no particular order) was: “Forming a Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. team to tackle our 6,500+ open issues on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..”

“We need to do a lot of triaging work. There are over 6,500 open issues in our CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Trac right now. There have been some requests about moving to a different 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. tracker and things like that. I would feel bad about doing that without cleaning up our home first.”

Matt Mullenweg – 2018 State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/..

As WordPress has grown, the volume of tickets in Trac has naturally increased. While the number of open tickets on its own should never be the sole metric of software health, a large number of open tickets can have many undesirable and frustrating consequences, such as tickets being lost or accidentally glossed over, and contributors not knowing where to focus their (often very limited) time and effort to have the largest impact.

This team will coordinate with component maintainers, release leads, project leadership, contributors, and other WordPress related projects with issue trackers outside of Trac (such as 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/, new default themes, etc.) to ensure that everyone is empowered to focus on what they are best at: contributing!

With that in mind, let’s meet the new Triage Team!

Initial Team Structure

The following initial team structure was self-organized and was formed based on nominations and interest expressed in the comments of Make WordPress Core posts related to this topic. The following people have a strong track record of contributing to WordPress, exhibiting good triaging practices, and being overall good community members. They also represent a range of disciplines to ensure every type of contribution is considered by the team when making recommendations for process changes.

This team structure can be altered at any time as needed and was created with the goal of getting the team to a point where it can be functioning and effective starting today. In addition, more team members are needed in order to accomplish these goals.


Jonathan Desrosiers (@desrosj) – Team Lead

Jonathan has been a consistent contributor to the WordPress project since 2013, lending his time to various components and initiatives (such as Media, REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/., and Privacy), and has been a significant contributor to organizational tasks. He also helps run new contributor meetings where all questions about contributing are welcome. Having worked in such various capacities, he’s thrilled to be able to focus on the organization of the issue tracking tools and processes.

Chris Christoff (@chriscct7) – Process Advocate

Chris has a long history of contributing to WordPress Core, particularly as part of ticketticket Created for both bug reports and feature development on the bug tracker. triage (including over 1,000 tickets triaged in the WordPress 4.4 and 4.5 release cycles). As a part of the team, Chris will be working to ensure that the triage team is meeting its milestone goals, performing ticket triages in an effective way, and working to improve and optimize processes.

Tammie Lister (@karmatosed) – Design Advocate

Tammie has a background in ticket triage, especially as it pertains to designers and design UXUX User experience/UIUI User interface concerns. As Design Advocate, Tammie will be working to ensure the workflow needs and requirements of designers receive proper consideration and are represented in all decisions made by the team.

Sergey Biryukov (@sergey) – Developer Advocate

Sergey is a prolific WordPress contributor with a deep-rooted knowledge of Trac and the needs of developers contributing to the project. As Developer Advocate, Sergey will be working to ensure the workflow needs and requirements of developers receive proper consideration and are represented in all decisions made by the team.

Sheri Bigelow (@designsimply) – Triage Advocate

Sheri has over 12 years experience supporting WordPress developers and users with an extensive background in triage and testing, most recently assisting with Gutenberg triage prior to its release in WordPress 5.0. She has a strong track record as a user and developer advocate and will ensure the team is communicating clearly (without jargon) to everyone to help build a strong, sustainable community of contributors.

Recent Challenges

Here is a list of some recent challenges that the team would like to explore solutions for:

  • Large time burdens on release leads to triage tickets in their release milestone.
  • Punting many issues each release, leading to frustration over poorly-set expectations.
  • Contributors don’t know where to spend time effectively especially when not contributing on a daily basis.
  • Tickets get buried, lost or glossed over.

Here are some metrics related to those problems:

  • The number of issues punted each release.
  • The number of interactions per contributor over time.
  • The number of stale and unactionable tickets left open.

Short Term Goals (First Half of 2019)

After reviewing current day to day Trac practices and considering both public and private feedback about the team, the immediate short-term goal of the team is to start a regular triage process to help maintain properly categorized and actionable tickets. Here are some of the ways that this can be done:

  • Create and execute a plan to work together with component maintainers and other contributors to triage open tickets with an emphasis on the Awaiting Review milestone and tickets that have become “stale”.
  • Provide any needed support to component maintainers in the form of (but not limited to): ticket scrubs, testing, ticket triaging.
  • Help release leads and deputies manage the flow of tickets into and out of release milestones.
  • Define and document WordPress ticket triage processes and best practices, including when to close an issue, requirements for moving an issue into a release milestone, etc.
  • Research and make some small process change recommendations (examples: new ticket resolutions, keywords, or workflows).
  • Sketch ticket flows for visual representations of processes.
  • What are the correct processes for supporting codebases in multiple locations (ie, Trac/SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase., 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 be the repository owner. https://github.com/, etc.).
  • Changes to Trac reports:
    • Which ones are no longer useful or manageable?
    • How do we better direct contributors to reports that require focus?
    • Where are there needs for new reports?

These are areas that require the focus and immediate attention of the team to ensure contributors are not overloaded and fully enabled to do their best work.

It’s important to note that none of the items above will replace the current responsibilities of component maintainers or ticket gardeners. Component maintainers and contributors are still encouraged to scrub tickets for their components in Trac. The Triage Team is not replacing that responsibility, but instead, are here to assist with that responsibility.

Component maintainers have a deep-rooted understanding of the component’s history, past decisions, and feature progression. They are the ones best suited to make decisions that will point the component in the direction they feel best aligns with the overall project goals and priorities. The Triage Team will work closely with component maintainers to expand the efforts around triage, help to improve those processes and ensure that tickets are actionable.

Long Term Goals (2019 and Beyond)

The ultimate goal of the team will be to make triage a scaleable, sustainable part of the WordPress project. Longer term, a roadmap will be established to detail the team’s vision. Here are a few potential long-term goals that have come up in discussions so far.

  • Automated workflow keywords. such as stale  or needs-verification (to make sure the reported bug is still reproducible) for older tickets.
  • Documentation for onboarding new team members.
  • Creating a rotation where interested contributors can donate time to the team as part of fulfilling the 5 for the Future challenge.
  • Ensuring that triage practices and ticket lifespans are agnostic to the ticket tracking software used (keeping in mind the ongoing WordPress + Git conversation).
  • Ensuring new tools and technologies in processes are properly supported (for example, NPM or Composer packages).
  • Creating a deprecation handbook with recommendations for how deprecated or removed parts of WordPress should be supported through tickets (What types of tickets are accepted or considered for how long under what circumstances?).
  • Global ticket triage days.

Staying Updated

Moving forward, the team will post an update every other week to the WordPress Contributor Team Updates blog with a summary of the following:

  • Summaries of the ticket scrubs held the previous week.
  • Priorities and ticket scrubs for the following week.
  • The ticket scrub schedule for the following week.
  • An overall summary of Trac ticket activity.

As changes to workflows are researched and evaluated, change recommendations will be published to the Make WordPress Core blog (and cross-posted where appropriate) for feedback.

Getting Involved

If you have an interest in being a part of this team and helping with its initiatives, please express your interest by commenting below. Feel free to be as specific as you’d like about how you would like to contribute to the team.

You can also attend the first team meeting! The first meeting will be held on Monday March 11, 2019 at 19:00 UTC in the #core room in the Making WordPress Slack.

In the interest of full transparency, the following additional people have also reviewed this post and provided feedback about the structure and priorities detailed in this post: @chanthaboune, @helen, @joemcgill.

#trac, #triage-team