Page MenuHomePhabricator

Improve the community relations process for server switches
Open, MediumPublic


During previous times working on server switches, we have observed a lot of room for improvement. The goal is to provide a better quality service.

Here is the improvement plan:

  • Discuss with Erica about having a third person involved in the process. Rationale:
    • We want to add quality checkins, with one person doing the task and the other checking up on it.
    • Since we only work for 1,5 FTE in total, can have vacations and times off, the idea is to have a third person to be a reliable backup and cover these times off.
    • Based on Tech News experience, we prefer not to rely on volunteers to help for now, even if some would be available and skilled.
  • Create a Phabricator template, maintained by us, to request banners for server switches
    • Reuse the current steps we have
    • Add a checkup step for translations (are they done, are links functioning, etc?)
    • Add a checking step for each item, written down in the checklist.
  • Improve messages sent to communities
  • We only have a reusable messages, which cover our needs: One for server switches
    • Change the date format so that translators don't have to deal with dates translations at each usage of the message (reuse Tech News') (see related translators-l@ thread). But leave space for local times for languages that cover multiple timezones.
    • Decide if we keep the possibility to translate the time of the event, which includes possible mistakes if 1/ the UTC time changes 2/ the local time observes DST.
  • Document publicly the fact that:
    • two people work on a task, the assignee and the checker
    • the assignee does the job, and the checker checks it
    • assignee can change but in this case, the task is reassigned
    • we debrief after each task, and we iterate on the process if needed
    • provide links to the two messages so tat translators can find them
  • Document a Q&A process so that an other CRS can check a banner configuration.

Until March 16 2022, this task covered read-onlys/databases switchovers. This process changed (T303605), and the scope of the current task was redefined to only take care of server switches.


Other Assignee

Event Timeline

Trizek-WMF updated Other Assignee, added: sgrabarczuk.
Trizek-WMF updated the task description. (Show Details)

Work done
I changed the date format on the Server switches message, so that translating the dates is not needed anymore. It would avoid sending a message with inaccurate dates.
I had to do it twice, since I goofed at my first attempt, by oversimplifying the date format, which lead to an incorrect display of the date for some languages. We learn new things every day, sometimes the hard way.

I changed the Read-only limited announcement to remove the number of wikis affected (one less step to change), and I tweaked the language a little bit. I also edited the date format.

The new date format for both messages it the same as on Tech News. It is supposed to be well known by our usual translators. To avoid issues with less experienced translators, I created several documentation messages, like this one, to warn them.

Open questions regarding Server switches
Regarding server switches, we still have some issues regarding the hour of the switch, especially in translation item #11. We initially choose to provide multiple times, so that we cover every part of the world. However, since some countries observe daylight saving time. So some times would be wrong time to time.

We need to find a solution:

  • only display UTC time, with a link to It is bulletproof, we can change it on our side and we are sure that users get it. But it requires one extra action for the reader to display their local time. It is the option applied on the Read-only limited announcement.
  • display various times, like it is done now: "14:00 UTC (07:00 PDT, 10:00 EDT, 15:00 WEST/BST, 16:00 CEST, 19:30 IST, 23:00 JST, and in New Zealand at 02:00 NZST on Wednesday 15 September).", with the risk of not having the right time being display, because of DST, or just because we move the UTC hour.
  • only have server switches when we are safe regarding timezones and our usual UTC time, which is kind of fun to schedule but not really practical.

For practical reasons, I'd go for the first option, now a second opinion is welcomed. I kept this part untranslated, and I froze the message while we discuss about it.

We have to add the following to the checkup:

  • Since I haven't been able to upgrade all translations, only messages with 100% of translations done must be used.
  • All <tvar> items named "date" must be updated each time we plan to send a new message.
  • Message documentation has to be updated with the right time everytime we plan to send a new message.
  • Any change to a date format must be applied to the qqq documentation, and translators have to be notified, especially the ones using a specific date format (Japanese and Korean, for instance).

Relying on translations of timezones is not possible. If the switch changes from 06:00 to 14:00 and the time is not updated in translations, we will have messages with some incorrect information. It is not acceptable regarding the quality of service we want to provide.

We benefit from, which uses Unix time as an URL parameter. As a consequence, it is easy to format our message to use it:{{#time:U|2021-11-11T06:00}}.

As a consequence, I edited the messages so that the time of the maintenance window is linked to zonestamp, with no translations. Translations haven't been updated yet, since the work continues.

As we have a new wave of read-onlys, I'm taking it as an opportunity to work on the template we wanted to create.

I planned to work on a Phabricator form for read-only-s and server switches. The goal is to prefill the task with the different steps we need to go through in order to inform the communities. I thought we had already a template, but I can't find it. If anyone finds it, please let me know.

I'm sorry I stepped on your toes (I missed this ticket.) but with recent discussions (last week). I personally we should just stop announcing them altogether. Hopefully this reduces your work.

Trizek-WMF changed the task status from Stalled to In Progress.Mar 16 2022, 1:26 PM
Trizek-WMF lowered the priority of this task from High to Medium.
Trizek-WMF updated the task description. (Show Details)
Trizek-WMF renamed this task from Improve the community relations process for read-only times and server switches to Improve the community relations process for server switches.Apr 13 2022, 12:59 PM
Trizek-WMF updated the task description. (Show Details)
Trizek-WMF changed the task status from In Progress to Open.May 11 2022, 5:44 PM

I keep this task as a background one, but I'm not focusing on it right now.