Repository navigation
Run and document Office Hours on August 22, 2026 #3640
Description
The topic was discussed during the “Office Hours” session on July 26, 2026.
Responsible Persons
Tasks
- Prepare the agenda based on open issues at github.com/rfluethi/wpt-office-hours/issues. Use the templates and the first meeting's notes at #3413 as reference.
- Ensure a note-taker has been confirmed for the meeting
- Set up and test the Zoom link
- Share the agenda link in the #training Slack channel at least 24 hours before the meeting
- Post a reminder in the #training Slack channel before the meeting
- At meeting start: post
<office hour meeting>+ Zoom link in Slack - Moderate the meeting following the agreed recurring agenda structure
- At meeting end: post
</office hour meeting>in Slack - Confirm note-taker for the meeting (currently TBD)
Context
The document “Organizing Office Hours Meetings” provides additional information on how to organize the meeting.
Activity
[-]Host Office Hours on August 22, 2026[/-][+]Run and document Office Hours on August 22, 2026[/+]rfluethi commentedon Aug 23, 2026
Office Hours Meeting Recap, August 22, 2026
Related links:
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
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 plugin 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 GitHub, 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 Slack. 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:
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 Meta 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 block 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
Recommendations (for the team to confirm)
Action Items
Next meeting
Focus topic: open. The moderator will put three topics to a vote at the Tuesday meeting on September 15 and announce the result on Slack afterwards.