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
Six contributors joined this session, three of them from the start. No agenda had been published and no note-taker had been assigned in advance. The items under Decisions were agreed in the meeting; the items under Recommendations are proposals that still need the team’s confirmation. Please share feedback by the next weekly Tuesday meeting, as a comment on this post or in the #training Slack channel.
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
Rade moderated the session and dealt with an unstable internet connection throughout: in Serbia, temperatures around 40 degrees Celsius and wildfires across the country have put power, water and connectivity into emergency mode. Sumit joined from a mobile phone, had no working microphone and took part through the chat.
Context
The session opened with an uncomfortable question: should this format be discontinued? Three people were in the room at the start, six by the end. The group decided to keep the format, but to apply the existing proposal consistently instead of debating it again.
The first half was dominated by a chain of blockers that keeps translated content from reaching learners on Learn WordPress: the missing link between the language switcher and the content itself, the lack of reviewers for finished translations, and outdated lessons with no version information. What stands out is that almost every one of these depends on missing access rights rather than on missing willingness. The second half covered the focus topic of this session, the note-taking and publication workflow (#3570).
Topics
1. Continue or discontinue
The starting position was uncomfortable: three people in the room, and a proposal on the table to stop running the Office Hours.
The counter-argument was not optimism, but the question of what would replace it. Discontinuing the format without a replacement would be counterproductive, because communication across the whole team needs to improve, and dropping the format would remove the one space where cross-cutting questions get discussed at all. Feedback such as “I was in the Training Team too, but thumbnails and translations are not for me” should make us pay attention. That may well be part of why so many contributors disappear after earning their first badge. The real question is therefore: how do we improve people’s identification with the team?
That leads to a clear alternative. Rather than calling a group provisional, there are two honest paths: carry out the existing concept properly, which has barely been done so far, or develop a clear concept for an alternative, for example splitting into subgroups where contributors can get involved more easily and can identify with the work.
2. Scoping the formats and reviving the TT-Admins meeting
The responsibilities of the different groups and meeting formats need clearer boundaries.
For the Office Hours, that means: this is where questions get answered and important topics get discussed. The goal of every session is to define clear tasks and clear ownership. The output is either new issues, or, for significant decisions, an agreement on who writes a proposal to be published on the blog for the team’s approval.
For the follow-up work, the suggestion is to use topic groups with sub-issues, so that the person owning a topic can assign work to others. For larger topics, that person also reports on progress at the Tuesday meeting on a regular basis.
This requires the TT-Admins group to be brought back to life. It should meet more often, go through the open issues, assign them to the right people and topics, and set reminders for the people responsible. The goal is to close as many issues as possible and to encourage contributors to finish the work assigned to them. The first sessions will take longer, until every admin understands the process. Over time the format should shrink into a standup, covering only the issues where something is unclear.
Further responsibilities and group tasks need to be clarified and documented clearly in the handbook.
3. Translated content depends on the language connection
On learn.wordpress.org, a language detection pluginPluginA 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. controls the interface language through the MO and PO files. It does not connect content. That is what Polylang, Weglot or WPML do: they create a translation as its own post and link it to the original. The two systems know nothing about each other, so switching the language in one has no effect in the other. A translated lesson created today cannot be reached through the language switcher.
Polylang has been under test for about two months. A connector between the two systems has been found, but it lives in code rather than in a plugin. The Polylang developers have been asked whether they would adopt it. The impression from that exchange is that the problem has not been understood on their side, because the case has never been reproduced.
For local language groups this is not a technical detail. In the German-speaking group a lot gets translated, but nothing can be published until an entire lesson series is finished. The motivating alternative would be the opposite: a reviewed translation going live promptly.
4. Finished translations without reviewers
A fully translated course in Urdu is waiting for a review that cannot be found. The same pattern applies to Bengali. The principle the group agreed on: nothing gets published without someone reading it in the target language, regardless of whether AI was involved in producing it.
There is an additional difficulty. WordPress translations follow language-specific rules, because there are fixed terms for post, page and other WordPress elements. The style guide for Urdu contains roughly 27 entries. Without reviewers, finished work stays unpublished, which devalues the contribution of the people who did it.
5. Access rights and delegation
The thread running through the session: work cannot be handed over because the rights are missing. Administrator rights cannot be granted on 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/, only limited changes are possible to the layout and content of make.wordpress.org/training, and the advanced settings in Sensei are locked. The result is a pattern the group called out as wrong: someone prepares the work, and then it waits on a single person. For a team spread across time zones, that costs more than time, it costs motivation.
The prerequisite for proper delegation is an inventory: who holds which rights today, and which former administrators and team reps have long been inactive? Only then can subgroups be given real ownership.
6. Getting started without prior GitHub experience
Agendas live on GitHub, and the same ten to fifteen people read them. One likely explanation: mentoring sessions for new contributors do not cover GitHub at all, they cover the WordPress.org profile and SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. As a result, many people in the Training Team have no GitHub account and no linked profile, which also stands in the way of their contributions being credited. As an interim measure, the agenda is published as a blog post again.
How to solve this for good is still open. Three paths are on the table:
work more in Google Docs, where the barrier is close to zero for most people,
use the new notes feature in WordPress and move collaboration to where the team already works,
offer an introduction to GitHub as a workshop.
The third path is smaller in scope than it looks: what contributors actually need is working with issues plus the basics of Markdown. Forking, branches and pull requests are not part of it.
7. Outdated lessons, version information and videos
A recurring piece of feedback from the German-language live sessions: participants work through a lesson and find that their WordPress looks different from the description. Advanced users deal with it; for beginners it is the point where they give up.
Sensei has a field for the highest tested version, but it cannot be surfaced because access to the templates is missing. Part of the existing content only works with older WordPress versions and should no longer be published at all. For heavily changed lessons, a second version of the lesson, explicitly valid from version 7.0 onwards, is a workable option.
Connected to this is a question of format: a five-minute video is close to impossible to update, whereas a short click-through demo of a few seconds is not. Anyone who wants to keep content current in several languages first needs to answer how an update to the English original reaches every translation.
8. Access from 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 and from Sensei
Several of the blockers end up with the Meta team: displaying the version information, displaying the credit fields, and setting a custom lesson order. Access to the Sensei templates is being requested through a personal contact in the Meta team. On the positive side, Sensei has assigned a contact person to support the Training Team over the past few weeks. That offer should be used while it stands.
Once the templates are available, all TT-Admins get access to Sensei and the work on the lessons is split into blocks so it can be done in parallel.
9. Credit inside the lessons
Sensei has meta fields for producer, reviewer and translator. They are not visible, because access to the templates is missing here as well. In the 2020 team, naming contributors this way was standard practice.
The practical suggestion: fill in these fields during the same pass through the lessons that will be needed anyway once the language connection works. If every lesson has to be opened once, credits and version information can be set in the same step. The question of GitHub versus Sensei was answered in favor of Sensei, with access for all TT-Admins.
10. Focus topic: note-taking and publication workflow
The existing workflow for the Tuesday meetings works and is not the problem: a reminder on Friday, a demo template in the draft ticket for people doing it for the first or second time, a review over the weekend, then publication. If the person supporting the note-takers is unavailable, the team reps publish. There have been no major problems in recent months. Today’s safeguards go back to one contributor who was not sufficiently familiar with the 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; since then, people who volunteer receive a message setting out what the role involves.
The actual problem sits next to it. Tuesday meetings regularly have around 30 attendees, many volunteer as note-takers, almost nobody can be won for other tasks, and direct messages go unanswered. Note-taking is the shortest route to a badge. The answer proposed in the session is a structured onboarding path across all areas of the team, with recognition at the end of it. This depends on the roles being clearly described in the handbook. It connects to the ongoing work on the badge system (#3487, #3539).
The second part of the topic was the minutes themselves. A Slack meeting already exists as text, and 80 to 90 percent of the write-up is copying. A Zoom session is a different matter: people speak freely and topics come up unannounced. Writing up a session of this kind currently takes six to eight hours, which is too much for unpaid work.
The time goes into two things that remain manual work: the reasoning, without which people who were not there cannot understand a decision, and turning decisions into issues. Preparing an outline of the session in advance, which the write-up then follows, makes both easier.
More important than style is rotation. The write-up should not depend on one person. Different approaches are explicitly welcome; over several sessions it will become clear which one produces understandable minutes at a reasonable cost.
11. Apply the format instead of deciding it again
The question of whether the current approach has worked, and what needs to change, got a clear answer: there is nothing wrong with the proposal, it simply is not being applied. What is missing are two assignments before each session.
One term was sharpened along the way: the role in an Office Hour is moderator, not host. A host carries an event; a moderator gives out the floor and makes sure everyone present has their say. The role is not limited to team reps, and whoever takes it on gets support.
A structure already described in the proposal was suggested again: about 20 minutes of information or a practical part, then questions and discussion, with the introductory part recorded and shared with everyone who could not attend.
Decisions
#
Decision
1
The format continues. From the next session onwards, the existing proposal is applied rather than debated again
2
The role is called moderator, not host: it gives out the floor and makes sure everyone has their say. It is not limited to team reps
3
Note-taking rotates and is assigned at the preceding meeting
4
The moderator owns topic selection: they propose three topics for a vote at the weekly Tuesday meeting and announce the chosen focus topic on Slack with enough lead time
5
If a topic needs an introduction, the moderator decides who gives it, around ten minutes. While attendance is low, simpler topics are chosen
6
Minutes record not only the decisions but also the reasoning behind them, so that people who were absent can follow, and turn decisions into issues. An outline prepared before the session serves as the basis
7
As soon as the Meta team releases access to the Sensei templates, all TT-Admins receive access and the work on the lessons is split into blocks
8
Next meeting: Saturday, September 26, 2026, 14:00 UTC (#3641). Moderator: Vasant, supported by Sumit. Note-taker: Andrew
Recommendations (for the team to confirm)
#
Recommendation
Consensus of attendees
1
Introduce standup rounds once subgroups exist: per group, briefly what is done, what is open, what is blocked
Yes, as a proposal
2
Openly ask for help with labeling the lessons instead of leaving it to run on the side
Yes
3
No new lesson videos beyond a few minutes in length; use short click-through demos for steps that change often
Yes
4
Define a minimum scope for publishable minutes, so the task can be taken on with limited time
