Triage Squad GitHubGitHubGitHub 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/ triage: Biweekly on Thursdays 07:00 UTC
This was the second session in the new Office Hours format. Since not all participants were available on time and the Learn Zoom account was not accessible at the start, the meeting continued on a private Zoom account.
In terms of content, the meeting picked up the open topics from April 18. Sumit prepared a first version of the 2026 goals, which the team discussed both in substance and in process. The group also discussed how onboarding for new contributors can be made simpler and clearer. Several ideas came up, including improving the handbook and reviving the Guide Program. These topics will be explored in more depth and made concrete in one of the next sessions.
Participants
Name
WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Profile
The introductions were shorter than at the kick-off. Huzaifa Al Mesbah from Bangladesh introduced himself as a returning contributor to the Training Team. He has been active in the WordPress community since 2023, mainly in the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and Test teams, and was recognized as a Noteworthy Contributor with WordPress 7.0. Huzaifa now wants to engage more in the Training Team, which is great news for us, as we welcome an experienced WordPress developer on board. From his perspective as a newcomer to the Training Team, he noted that many people attend the weekly SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ meetings, but the path into active contribution remains unclear.
Topics Discussed
1. 2026 Goals
Discussion:
Sumit prepared a first draft of the 2026 goals and gathered feedback from the team several times. Rico then wrote a revised version on top of that. Both documents will now be read together and consolidated into an official 2026 goals list.
Sumit emphasized that the goals also matter for external communication, for example when contributors at a WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. ask about the team’s focus areas.
We discussed that we are late with defining the 2026 goals. The problem, however, is not that we have no goals, but rather that we have too many, which creates the risk that none of them get achieved. In that context, we also discussed whether it makes sense to define goals on a yearly cycle at all. Experience shows that toward the end of the year we have other priorities than setting goals for the next year. What matters most is that we have goals everyone understands, with a clear purpose, a timeline, and concrete work for implementation. As an alternative approach, the group considered a longer-term goals list from which, for example, the three most important items are picked each quarter and worked on concretely.
For the wording, the goals will be formulated according to SMART criteria (specific, measurable, attractive, realistic, time-bound). The goals will also be aligned with our vision and with the goals of the broader WordPress community, so that they remain connected in content. After the internal evaluation, the consolidated goals list will be published on Make WordPress Training, so that the discussion and decision can happen across the whole team.
Outcome:
Two working documents exist: a first draft by Sumit (with many comments) and a version by Rico.
Both will be read, commented on, and merged at the next meeting by June 27.
The consolidated goals will be formulated according to SMART criteria and aligned with the vision and the community goals.
A model with a longer-term goals list, from which three quarterly priorities are selected for concrete implementation, will be evaluated.
After the evaluation, the goals will be published so that the discussion and decision can happen across the whole team.
Open questions:
Which content from both documents will be taken over?
Which three goals get the highest priority?
Which vision points and community goals should we use for the alignment?
Do we keep the yearly cycle or move to a rolling, quarterly model?
2. Training Handbook Revision
Discussion:
The main problems identified in April still exist: outdated content, a lesson order that is hard to follow, and duplicated titles with different content. Muhibul is working on critical sections. Rico proposed consolidating the handbook first and then translating in a targeted way. A good first step would be to revise the entry sections “About” and “Getting Started” so that they can be translated into different languages when needed. From a newcomer’s perspective, Huzaifa pointed out that the landing page should make the next sensible step clearer.
The group also discussed whether it makes sense to translate the entire handbook at all. A full translation would significantly increase the maintenance and update effort, because every change would have to be carried over to all language versions.
The group also discussed introducing a “Last Reviewed” entry per handbook page. Unlike the original publication date (“first published”), “Last Reviewed” shows at a glance when a page was last checked. This makes the maintenance need visible and manageable, instead of relying on the original date. Vasant added the example of WPForms, where documentation pages show not only the update date but also when the page was last reviewed and who is responsible. A similar display could increase the motivation of contributors to work on individual pages.
Everyone agreed that the handbook must again become a central rulebook that we follow. When content becomes outdated or no longer current, the handbook is updated first. The handbook is the most important rulebook for our teamwork.
Outcome:
Continue the inventory of outdated and duplicated content in the TT-Admins pool.
Prioritize the revision of the “About” and “Getting Started” entry sections so that they can be translated into other languages when needed.
Critically evaluate a full translation of the handbook, since it would significantly increase the maintenance effort.
Prioritize the revision of the handbook landing page.
Introduce a new “Last Reviewed” field instead of “first published”. Use the WPForms example as a reference for the display.
Anchor the handbook as the central rulebook: changes in how we work are reflected in the handbook first.
Open questions:
Who (role or group) takes over which inventory areas?
Who implements the “Last Reviewed” field technically?
Which additional displays (responsible person, review date) do we adopt from the WPForms example?
Which languages do we translate the entry sections into, and who maintains them?
3. Sensei and Learn WordPress Issues
Discussion:
Since the update to WordPress 7.0, Rade can no longer see or edit the templates on Learn WordPress in the Site Editor. Requests to the MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team have so far gone unanswered. Rico wants to understand why it keeps happening that the lesson order inside a learning path gets mixed up. Specifically, he wants to know what triggers it, how to prevent it, and how a repair looks if it happens anyway. Without that knowledge, no one wants to work with Sensei, which cannot be in the team’s interest. A direct contact with Sensei developers may be useful. The participants agreed that Sensei has been repeatedly problematic, but a migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. is not realistic in the short term.
For the long-term maintenance of the extensive content on Learn WordPress, it is also essential to define the classification of lessons cleanly, for example through a field for the applicable WordPress version. Otherwise, the team will one day face a content base that is fully outdated and could only be deleted. This topic therefore has high priority.
Outcome:
Bug reports are collected and escalated to the Meta team.
A direct contact with Sensei developers will be sought, focusing on triggers, prevention, and repair of the lesson order issue.
Classification fields for lessons (for example WordPress version) will be defined and introduced with high priority.
Caching and Sensei issues will be addressed together with the Meta team.
Open questions:
Who from the Sensei team can contribute to the root cause analysis?
Which fields do we need at a minimum for the classification of lessons?
4. Onboarding and Guide Program
Discussion:
Huzaifa observed that 30 to 40 people attend the weekly Slack meetings, but many of them do not contribute actively. Rico noted that this impression may not be entirely accurate, because many activities of contributors are not immediately visible. They happen in GitHubGitHubGitHub 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/, in regional groups, and in other places. At the same time, there are surely people who only attend the Tuesday meeting and otherwise find no connection. To improve exactly this, the Guide or Mentor Program should be reactivated, so that no contributors are left who would like to do something but do not know what.
Outcome:
Reactivate the Guide or Mentor Program and promote it in the Slack channel and during onboarding.
Clear entry path on the handbook landing page.
Open questions:
Who takes care of reactivating the Guide or Mentor Program?
How are regional groups connected to the team?
5. Badge System Reform
Discussion:
The participants discussed the fundamental problem of the badge system. Badge hunters take up noticeable team time because they sign up for roles without bringing the basics along, and after receiving the badge, they are no longer active. Since this cannot be solved at the global level, the Training Team should develop its own pragmatic approach. This way, we avoid losing more time both through badge hunters themselves and through endless discussions about the badge system.
Outcome:
Collect concrete measures that the Training Team can implement on its own, without the Make team.
Communicate clearly to the whole team, with responsibilities and a timeline for the implementation.
Set up a review of the improvements in one year.
Open questions:
Where do we collect the suggestions?
Who takes care of turning them into a clear action plan?
6. Help Scout and Zoom Access for TT-Admins
Discussion:
The Zoom access was not available at the start of the session, because verification runs through Help Scout, and Help Scout access is only open to Team Reps. Muhibul explained that the Meta team has declined to extend the access, because the account also holds sensitive inboxes from other teams. Rade proposed a workaround: export the Help Scout tickets as a CSV, review them in the TT-Admins pool, and transfer only the relevant ones into GitHub issues. Rico pointed out that in his company a single Zoom account is shared with a passkey among ten people.
Outcome:
CSV export as an interim solution, with manual triage by TT-Admins.
In the medium term, talk with the Meta team about a leaner workflow.
The Zoom link will from now on be documented in the GitHub issue.
Open questions:
Who sets up the CSV export workflow?
How is responsibility for the Zoom account handled in the interim?
7. BlockBlockBlock 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. Editor Workshop for Note Takers
Discussion:
A specific note-taker incident led to the proposal of a mandatory “Block Editor Basics” workshop. Sumit takes over the concept. Vasant complements it with a screencast tutorial for recurring TT tasks.
Outcome:
Sumit hosts the live workshop, records it, and publishes it on Learn WordPress.
Vasant creates a screencast tutorial.
Both formats are anchored in onboarding as a mandatory step before taking on the note-taker role.
Open questions:
Who handles the editing of the recordings?
Where do we publish the workshop, and how do we communicate the “mandatory workshop”?
8. Meeting Organization and Next Meeting
Discussion:
Starting with the next meeting, Sumit will take over the Zoom link preparation through the Learn account and document it in the GitHub issue. The moderator informs the Slack channel the day before the session and one hour before the start, and publishes the main topic in advance.
We all agreed that the Office Hours meeting must not turn into a Coffee Hours meeting, even though there is a clear need for social exchange. An Office Hours meeting needs detailed preparation: the tasks from the previous meeting are reviewed, and clear agenda items for the current meeting are set. Both are communicated in advance, so that participants can prepare and the meeting runs efficiently. The meeting concept serves as the reference.
Vasant proposed that the tasks decided at the meeting be communicated to everyone afterwards, with an invitation for several people to sign up per task and work on it together.
Outcome:
Sumit hosts the next meeting and provides the Zoom link.
The reminder routine becomes binding (day before and one hour before).
Meeting flow follows the published concept; adjustments are documented in the handbook.
After the meeting, an issue list is created with one issue per task, where people can sign up to work on it.
Next meeting: Saturday, June 27, 2026, 14:00 UTC.
Open questions:
Who takes notes on June 27?
Which tasks go into the issue list?
Decisions
#
Decision
Consensus?
1
The 2026 goals will be consolidated from two working documents: a first draft by Sumit and a revised version by Rico. All TT-Admins comment on both by June 27
Yes
2
Three prioritized main goals will then be published as a blog post on Make WordPress Training
Yes
3
A separate TT-Admins meeting after the Tuesday Slack meeting
Yes
4
Sumit takes over the Zoom link generation through the Learn account and documents it in the GitHub issue
Yes
5
The Block Editor workshop becomes mandatory before the note-taker role
Yes
6
Vasant additionally creates a screencast tutorial for the note takers
Yes
7
After each meeting, an issue list is created with one issue per task; contributors sign up there themselves
Yes
8
The moderator follows the defined meeting concept; adjustments are made immediately and documented in the handbook
Yes
9
A “Last Reviewed” field will be introduced in the handbook, instead of “first published.”
Yes
10
Next Office Hours meeting on June 27, 2026, 14:00 UTC, moderation by @sumitsingh
Define badge-hunter filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. measure
Date: April 18, 2026 Time: 14:00–15:00 UTC Platform: Zoom Recording: Not recorded Moderator: Rico F. Lüthi (@rfluethi) Note-Taker: Rico F. Lüthi (@rfluethi)
This was the first meeting of the Training Team’s new Office Hours format. The format replaces the previous Coffee Hours, which generated more than 90 ideas over roughly eight sessions but resulted in very little concrete follow-through. The Office Hours are designed to close that gap: informal in tone, but clearly outcome-oriented, with actionable next steps from meeting to meeting.
As outlined in the proposal, the format initially runs as a three-month pilot phase. The goal of this kick-off was to establish the basic structure, success criteria and organizational approach together, so that future sessions can focus directly on substantive work.
Participants
Name
WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Profile
The introductions highlighted the geographic and biographical breadth of the team. Paths into the WordPress community vary widely: from a developer whose first contribution grew out of frustration, to a manager of local language projects, to community supporters and digital skill facilitators. @sonaliprajapati shared her experience from the Indian WordPress community. This diversity is relevant to the direction of the Office Hours because it shows the range of needs and perspectives that contributors bring to the format.
Topics Discussed
1. 60-Minute Structure
Discussion:
On the question of meeting duration, @rjekic noted that while 60 minutes should be set as the frame, many meetings would likely end earlier in practice. This point mattered to the group because the format is intended to be distinct from the previous Coffee Hours, which were enjoyable but not outcome-oriented.
There was consensus that perfect English should not be a prerequisite. Open exchange with the broader community takes priority.
Outcome:
Duration: 60 minutes, flexible downward
Character: informal in tone, outcome-oriented in output
Linguistic openness as a deliberate principle
Open questions: None.
2. Recurring Agenda Items
Discussion:
The group developed an agenda structure that gives each meeting a reliable framework without losing the informal character. A central point of discussion was the advance announcement of the main topic: this was introduced specifically so that non-native English speakers can prepare both in terms of content and language. This addresses a real barrier for international contributors.
It was also agreed that moderation and note-taking will rotate among team members in order to distribute responsibility. In addition, at least one team repTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. should be present at each meeting to ensure overall coordination.
Outcome:
The following items will be a fixed part of every session:
Welcome & onboarding
Brief introductions
Topic presentation (5–10 minutes) on the main topic
Open discussion
Review of open action items from previous meetings
Definition of next steps including responsible persons
Setting the date, moderator and note-taker for the next meeting
Open questions: None.
3. Onboarding New Contributors
Discussion:
A major focus of the discussion was how to prevent new contributors from dropping off after their initial engagement — particularly after WordCamps. The team’s experience shows that motivation is often high at first but fades quickly without concrete, low-barrier tasks. Thumbnail creation and translations were cited as examples of suitable entry-level tasks.
This observation led to a broader point: the Training Team needs specialized groups so that both new and existing contributors can get involved and achieve results quickly. Three types were discussed: the existing Guides, topic-specific groups for developing new learning paths, and regional groups for localized learning resources.
Coordination of these groups is to run through the TT-Admins and the Office Hours. An important point raised by the group: transparency is essential so that it remains clear to everyone why particular decisions were made. Without this transparency, the group concluded, the team risks losing touch with the broader community.
Outcome:
Low-barrier entry tasks (thumbnails, translations) as first points of contact
Development of specialized groups: Guides, topic groups, regional groups
Active promotion of these groups within the Training Team
Transparency in coordination as a coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. principle
Open questions:
How will the specialized groups be promoted and coordinated in practice?
4. Success Criteria for the Pilot Phase
Discussion:
@andrewssanya proposed an iterative, agile approach: each meeting identifies concrete problems, and progress on their resolution is reviewed in the following meeting. The group adopted this proposal and expanded it into a definition of success criteria.
The decisive point in the discussion was the distinction from pure attendance numbers. The group agreed that even a small but active group justifies the format, as long as topics are demonstrably turned into issues and worked on. This definition is important for the later evaluation of the pilot phase and protects the format from being prematurely judged by quantitative metrics alone.
Outcome:
Success = combination of attendance and concrete project progress
Attendance numbers alone are not a criterion
Progress review from meeting to meeting
Open questions: None.
5. Organization via GitHubGitHubGitHub 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/
Discussion:
The decision to organize via GitHub was unanimous, since the Training Team already works with it and no additional tooling barrier should be introduced. Topic proposals are collected as issues at wpt-office-hours / issues; the respective moderator selects the agenda from these.
@rfluethi encouraged all participants to actively contribute to shaping the repository. Specifically, it was agreed that @andrewssanya and @rfluethi will review the existing repository templates and the Training Team’s issue templates for potential improvements.
After the pilot phase, the repository is to be transferred into the official Training Team structures. This temporary solution was chosen deliberately to allow the pilot to start quickly without waiting for formal processes.
Transfer to the official Training Team repository after the pilot phase
Open questions: None.
6. Tracking Open Action Items
Discussion:
For tracking action items, the group deliberately opted to use the Training Team’s existing issue system rather than building a parallel tracking structure in the pilot repository. The rationale: Office Hours tasks should not exist in isolation alongside the rest of the team’s work, but be part of it. To still distinguish them from the broader backlog, a dedicated label will be introduced.
A dedicated Office Hours issue label will be introduced
Yes
4
Moderation and note-taking rotate among team members
Yes
5
At least one team rep should be present at each meeting to ensure overall coordination
Yes
6
Pilot phase success = combination of attendance and project progress
Yes
7
Next Office Hours on May 23, 2026, 14:00 UTC, moderation: @rjekic
Yes
Rationale for Decision 4 (Rotation): Rotation was chosen deliberately as a countermodel to fixed moderation, in order to distribute responsibility and give different team members the opportunity to actively shape the format.
Rationale for Decision 6 (Success criteria): The proposal came from @andrewssanya as part of an iterative, agile approach. The group explicitly followed the reasoning that even small, active groups justify the format, as long as topics are demonstrably turned into issues.
Publish call for Training Table lead at WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe
Follow up with the MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. Team regarding the TT-Admins Slack channel
