Howdy! My name is Anne McCarthy.
I am a WordPress contributor and triagerfor the Gutenberg GitHub Repository.
In this video, I’m going to cover how todo triage on GitHub for Gutenberg. This
is one of many ways to contribute back to theWordPress project and I hope you'll join me.
In case you’re not familiar, Gutenberg is theproject codename for the Core Editing experience.
Meanwhile, GitHub is the ticket tracking softwarethat the WordPress project uses to make changes
to Core Editor experience. This repositoryis where all open issues and pull requests
are managed. Finally, triaging is essentiallytaking on the role of helping label issues and
pull requests appropriately so theycan be better handled and organized.
Of note, this repository is separate from Tracwhich you might be familiar and is the ticket
tracking software that the WordPress project usesto make changes to the core WordPress experience.
After watching this video, you will have all ofthe information you need to help contribute to
the WordPress project through triaging Gutenbergissues and helping maintain a healthy repository.
Here’s a quick outline of what we’ll go over:
What accounts are needed for triage.
Documentation in case you need a refresher.
How to get access.
Ways to triage.
Common approaches to triage.
How to escalate issues when necessary.
When to close issues.
Tips/Tricks.
To help with triaging GitHub,
you’ll need three different accounts.I’m going to go over each one at a time.
To start, you will require a GitHub account. Youcan sign up for one at github.com/join. Once you
have one, you are then able to create new issuesand pull requests in the Gutenberg repository.
At this point though, you won’tbe able to start adding labels
or removing them which is a keypart of helping with triage.
The next account you need is aMaking WordPress Slack account.
You can sign up for this accountat make.wordpress.org/chat/.
This will give you access to the wider Slackcommunity that supports the WordPress project.
Once you have this account, you’ll want tonavigate to the #core-editor Slack channel
where you can ask for triage access. Please waitto do this until you’ve completed this course and
have reviewed the repository to make sure it’ssomething you really are ready to commit to.
The last account you need is a WordPress.orgaccount. You can register for an account
at login.wordpress.org/register.
Having this account helps complete the connectionto the wider community including reviewing Trac
issues. As a reminder, Trac is where changesto the core WordPress experience are handled.
If this feels like a lot of information, don’tworry. There’s great documentation that you can
always refer to as you get started with triage.Just go to the Gutenberg Repository and head to
the Docs folder followed by Contributors folderand you'll see a triage document. This will lead
you to this link below. There's a screenshotas well so you know you're in the right place.
Much of this course will cover thesame information that’s shared there
so please refer to it as it’s helpful for you.
Before going further, let’s talk abit about getting access to do triage.
While anyone with a GitHub account can open anissue or submit a pull request for review, there
are additional roles in the repository that givepeople additional permissions including everything
from managing labels to merging code. As a result,there’s an additional step that’s needed in order
to get proper permissions to help out here.Thankfully, doing so is pretty easy! Just head
to the #core-editor channel in the WordPress Slackinstallation and share there that you want to help
with triage along with your GitHub username. Ifpossible, when you send this initial message,
please also share what you plan to focus ontriaging as this helps with coordination.
If you aren’t sure just yet, noworries as this course will give
you a great overview of the most commonoptions. Let’s go over those ways now.
There are three main ways thattriage tends to happen and all
of them help keep the repositoryhealthy so pick what works for you.
The first way is to hold regular selftriage sessions on your own time.
This could range from 10 minutesevery day to 1 hour each week.
The second way is to join an organizedtriage session done as a group.
These sessions are held in the WordPress.orgSlack community. You can review the Meetings
page on WordPress.org to find these triagesessions and appropriate Slack channels.
The link for the meetings page can befound at make.wordpress.org/meetings.
The final way is to be a part of morefocused triage sessions on a specific board,
label, or feature. This oftenhappens as part of feature
projects and is typicallydone by Core contributors.
No matter how you decide to help with triage,there are a few general expectations to keep
in mind. You are expected to do some form oftriage in whatever form works for you at least
once a week. As you can, try to join organizedtriage sessions as it helps with consistency.
Finally, if you join the triage teamto focus on a specific label or board,
it’s expected you will focus thereand it’s important you announce it.
With this foundation in place, let’s diginto the most common approaches to triage.
While there are a ton more ways you couldhelp triage beyond what I’ll share here,
these are the common ways to get started that willhave a big impact on the health of the repository.
To start, let’s look at all issues without anassigned label by going to Label > Unlabeled.
Triaging by simply adding labelshelps people focused on certain
aspects of Gutenberg find relevant issuesfaster and start working on them sooner.
Next up, let’s look at the Sort section whereyou can sort the issues in the repository by
different variables. To start, here’s the theleast recently updated Gutenberg issues. Triaging
issues that are getting old and possibly out ofdate keeps important work from being overlooked.
Next, you could focus on all Gutenberg issueswith no comments by typing this: comments:0.
Triaging this list helps make sure allissues are acknowledged, and can help
identify issues that may need more informationor discussion before they are actionable.
Similarly, you can also look at the theleast commented on Gutenberg issues.
Once more, you'll return to the Sortsection. Triaging this list helps
the community figure out what things mightstill need traction for certain proposals.
Finally, you can check the most commentedon Gutenberg issues. If you feel comfortable
chiming in and the conversation has stagnated,the best way to triage these kinds of issues
is to summarize the discussion thus far and doyour best to identify action items, blockers,
etc. Triaging this list allows finding solutionsto important and complex issues to move forward.
For triaging issues, you’ll often find thefollowing labels are the most commonly used:
[Type] Bug: This is when anintended feature is broken.
[Type] Enhancement: When someone is suggestingan enhancement to a current feature.
[Type] Help Request: When someone is askingfor general help with setup/implementation.
Needs Technical Feedback: When you seenew features or API changes proposed.
Needs More Info: When it’s not clear what the
issue is or it would help toprovide additional details.
Needs Testing: When a newissue needs to be confirmed
or old bugs seem like they are no longer relevant.
There are a ton more labels though sodefinitely take some time to explore!
Here’s a quick recording to demonstrate howto add labels. So in this case if I go to
Label > Unlabeled, I'll be brought to thispage. From there, you'll select an issue.
Head to the label section and picksomething that makes the most sense.
So in this case, I'm going to chooseFull Site Editing and Enhancement.
I knew this because I'm very familiar withthis project and I actually opened this issue.
But in most cases, you'll probably have to readthe issue in order to know how best to label it.
Beyond just triaging issues, unlabeledpull requests also need to be reviewed.
To check these out, you’ll want to switch fromlooking at issues to looking at pull requests
by going here. From there, just like with theissues tab, you’ll select Label > Unlabeled to
view all unlabeled pull requests. It’s importantto note that labeling these requires a level of
comfort with code. If that’s not something you cando, no worries. You can also always check with the
person authoring the pull request to make surethe labels match what they are intending to do.
Finally, keep in mind that you can also alwayscreate your own custom set of filters on GitHub.
If you have a filter that you thinkmight be useful for the community,
feel free to submit a pullrequest to add it to this list.
Now let's talk about how to draw attention toissues when necessary. If you find an issue
that impacts a lot of users or that createsa serious problem like an inability to use
a screen or a block, there are actions youcan take to get more attention on that issue.
The most obvious action is to labelit with one of the priority labels.
Let’s go over what each priority means:
Priority OMGWTFBBQ: This is a somewhat sillylabel that's meant to represent major issues
that are causing failures and are reportedfrequently. Typically, these are issues
that are critical because they break importantbehavior or functionality. An example might be,
“Unable to remove a block afterit is added to the editor”.
Priority: High: This would be an issuethat fits one of the current focuses
and is causing a major broken experienceincluding flow, visual bugs, and blocks.
Priority: Low: This would basically coverenhancements that aren’t part of focuses,
niche bugs, problems with oldbrowsers. Things like that.
It’s important to note that it’s intentional thatthere’s a level of knowledge needed to determine
priority so if you aren’t comfortable doing thisto start, don’t worry. Finally, it’s also on
purpose that there’s no “normal” label as that’sthe baseline all issues are considered to be.
Outside of these priority labels, you canalways drop a message in the #core-editor
channel in Slack to alert others to checkout an issue you are concerned about.
If you are certain there’s a seriousissue going on, you can also always
use group alerts by commenting on anissue with the following group handles:
@WordPress/gutenberg: this willalert the entire Gutenberg team
@WordPress/gutenberg-core: this willalert the Gutenberg development leads.
@WordPress/gutenberg-triage-team: This willalert everyone else on the triage team.
These should very rarely be used soplease be very mindful and, if you can,
get a second opinion before using any ofthem as they will each ping a lot of people.
Now that we’ve covered handling labels anddetermining priority, let’s go over when to
close issues! Closing issues helps make sure thatthe issues that are open are the most relevant for
developers and designers to investigate further.This leads to lots of saved time and effort.
Currently issues are closedfor the following reasons.
A PR and/or latest releaseresolved the reported issue.
It's a duplicate of a current report.
It's a help request that is besthandled in the WordPress.org forums.
It's an issue that's not able tobe replicated either by yourself
or by someone else on the thread.
It's an issue that needs more information
that the author of the issue hasn'tresponded to for at least 2+ weeks.
It's an item that is determined as unableto be fixed or is working as intended.
When you close an issue, please clearlyand kindly state why in a comment so that
the person who originally opened the issuehas a shared understanding going forward.
The final part of this coursecovers tips and tricks.
These should help you superchargeyour triage abilities.
To start, always search for duplicatesfirst. With a project as big as Gutenberg,
it’s common for there to be duplicatesand it helps to consolidate those.
When doing so, it’s a best practice to keep theoldest issue open and close out the newer one.
Next, ask what WordPress andGutenberg version a reporter is using.
This often helps narrow down where theproblem might be and when it was introduced.
Rule out plugin and theme conflicts earlyon in triage. You can do this by asking
someone reporting a bug to confirm that they couldreplicate this without any other plugins installed
except Gutenberg or by asking them to temporarilyuse a default theme while trying to replicate the
issue. This helps make sure the problem beingdiscussed is indeed in the Gutenberg codebase.
Edit the title to bring clarity to theissue. Doing so allows everyone at a
glance to understand the issue discussedand helps people in the future find it.
If it’s a bug report, test it to confirm thereport or add the Needs Testing label so someone
else can get to it. It’s important that thisis done to confirm an issue is indeed relevant.
Add a GIF or screenshot if a bug reportwould benefit from more visual information.
This helps those that might be able tofix the issue get up to speed faster
on the problem at hand by beingable to visually see the problem.
Take time to set up your GitHub notifications.This might seem like an odd suggestion but trust
me. This will help you better keepon top of any follow up that might
be needed in your interactions with peoplewho open issues or work on pull requests.
Remember that you can searchthe repo across multiple labels.
For example, this means that you can look at allopen bugs for the paragraph block and dive into
triage from there. This is particularly useful asyou get more comfortable exploring the repository.
We’ve reached the end of this course! Thisshould help set you up for success for triaging
on GitHub. Thanks for being interestedand hope to see you in the repository.