Skip to content

Github-workflow.md

Latest commit

 

History

History
65 lines (44 loc) · 6.25 KB

Github-workflow.md

File metadata and controls

65 lines (44 loc) · 6.25 KB

Back to overview

GitHub workflow for the Performance Lab plugin

The Performance team uses GitHub to manage all code and related discussions for the Performance Lab plugin. Please follow the workflow below to ensure that all issues are properly tracked.

Issues

When opening a new issue, use the appropriate template: Bug report, Feature request, New module proposal, or Report a security vulnerability. All new issues should include the following labels:

  • A [Focus] label, or Infrastructure if the issue relates to the plugin infrastructure. The [Focus] labels are aligned with the Performance team's focus areas and GitHub Projects.
  • A [Type] label
  • A [Module] label if the issue relates to an existing module
  • OPTIONAL: A [Milestone]. Use your best judgment here – if it’s a smaller issue and we’re early in the release cycle, it can be assigned to the next release milestone. If it’s a large issue and we’re only a week out from the release, it should not be assigned to the next milestone, but the one after.

In addition, the new issue should be assigned to an appropriate Project. By default, new issues will automatically be added to the Backlog column within its project. This is intended for tracking any future work that is not currently a high priority as defined by the project’s point(s) of contact (POCs). Contributors are welcome to work on issues in the Backlog, but response rates may be slower than they are on prioritized issues.

Working on an issue

If you’re interested in working on an issue, it's helpful to notify the POC for the issue’s focus area by tagging them on the issue and/or notifying them in the weekly performance chat so that everyone is aware that someone is working on it and effort is not duplicated. For an updated list of POCs, please see the CODEOWNERS file.

When you’re ready to begin work on an issue:

  • Assign it to yourself – Depending on your permissions levels, you may not be able to self-assign an issue. Please tag @WordPress/performance-admins on an issue if you need assistance with permissions. Please only assign an issue if you plan to work on it within a reasonable time frame, i.e. within the next 2 weeks.
  • Change the Project column to In Progress
  • Remove the Needs Dev label, if applicable

In addition, there are several Needs labels that can be used to clarify next steps on an issue.

Needs Discussion

Many issues require discussion and definition before development begins. For example, multiple approaches may be considered and the community should discuss them before a contributor proceeds with development. For those issues, add the Needs Discussion label and raise the issue in the weekly performance chat.

Needs Decision

After discussion, a formal vote may be needed to determine how to proceed. If that’s the case, please tag @WordPress/performance-admins in the issue for assistance with setting up a vote via GitHub comment. An example vote can be found here.

Needs Dev

If an issue requires (more) development and you are unable to complete it yourself, remove yourself as the assignee and add a Needs Dev label.

Needs Triage

If you believe you may have discovered a possible bug or have an engineering-related question about the plugin, add the Needs Triage label.

Needs Testing

If you have completed initial engineering and want community members to test prior to merge, add the Needs Testing label.

Pull requests

All pull requests must:

  • Be associated with an issue
  • Have [Type] and [Focus] label matching the related issue’s [Type] and [Focus] labels
  • Have either an assigned milestone or the no milestone label. Milestones should be assigned based upon the complexity of the PR as well as how close we are to the due date of the next milestone. Use your best judgment here – if it’s a smaller PR and we’re early in the release cycle, it can be assigned to the next release milestone. If it’s a large PR and we’re only a week out from the release, it should not be assigned to the next milestone, but the one after. NOTE: PRs that have zero effect on the plugin end-user (e.g. documentation changes, engineering tooling, anything that doesn't require a changelog) do not need a milestone, and should instead receive the no milestone label.

When a PR for an issue is ready for review:

  • Change the Project column on the issue to Review
  • Add the Needs Review label to the issue

Reviewers will be auto-assigned based upon the issue’s assigned Project. Note that all PRs require at least two reviewers.

Trac tickets

Trac is the system used to track issues related to WordPress core. There is a ‘performance’ label in Trac that has been added to over 300 issues dating back nearly 15 years.

While the Performance team’s focus is on the work in the GitHub repo, the community is welcome to consult with the team on performance-related Trac tickets. There may also be tickets in Trac that are duplicates of planned work in the GitHub repo, or warrant further discussion for inclusion in the plugin.

POC responsibilities

Each focus area has a set one or more assigned points of contact (POCs), as defined in the CODEOWNERS file. POCs are expected to:

  • Monitor new issues to ensure that new issues are appropriately designated to their focus area
  • Make sure issues in their focus area are also added to the focus area’s GitHub Project
  • Monitor and update issues labeled with their focus area