Polyglots leads discussion
Leading the polyglots team isn’t an easy task. Lots of cultures, a lot of diversity. Understanding everyone can be hard. There have been issues in the past with specific communities using their sites to make money, some using it for WordPress, some not. Part of this is cultural, part of it is ignorance, part is just bad performance. Varies from culture and site.
In light of that, we created a set of expectations for Rosetta sites. Part of leading polyglots is making sure sites meet these expectations.
Process for handling bad content on Rosetta sites
- Email the validators of the site (request a response within a week)
- After a week, email again (“You have 3 days to take care of this”)
- After three days, email again (“You have 24 hours to clear this or we remove it”)
- If the content is not removed within 24 hours, login as administrator and remove bad content.
- Email validators and say if the content comes back without fixing its problems, they will be removed as validators/editors.
- Check site regularly to ensure the content doesn’t come back.
- When at all possible, we want validators to be responsive. If they aren’t, that can be an issue.
- Note that just because a validator is unresponsive, that doesn’t mean they are bad actors. It’s possible for life to get in the way for days, weeks, or months.
Finding new validators
- We are going to need more validators as plugins and themes become translatable. A good target is likely 20 active validators per language by mid-2015.
- That’s a problem across the community and we need good coordinators for different regions to mentor new validators.
- We also need to add new languages, which will need good validators. Mentoring them will be important so they can grow fast.
Things that will help with new translators/validators:
- Having better documentation
- Translator handbook
- Per language guidelines for translation
- Glossary for every language
- Better contributor recognition
- Roles: separate roles for translations vs the local community stuff (Rosetta administration, support, blog, forum moderation)
- Separate the role of the editor from the validator so validators can focus on translation and mentoring new validators
Leads
As Polyglots will get more and more busy following themes and plugins in the repository, there will be a need for more coordination and help to all the new validators. This can be accomplished by splitting locales into different regions and appointing multiple leads for each region. Separating the locales will be done geographically first and then by language so that there is no overload for any of the leads.
Proposed regions:
Region 1: Asia & Oceania: Central Asia, South Asia, East Asia, and Oceania. Perhaps does *not* include Australia / New Zealand English, but does include any future local languages. Does not include Russia or Iran. Currently, ~51 locales.
Region 2: Europe (including Turkey, Russia), Africa (entire continent), Middle East (includes Iran). Currently, ~70 locales.
Region 3: North, Central, South America, and the Caribbean. Perhaps includes Australia / New Zealand English. Also includes engineered languages (Esperanto, Klingon, Ido). Currently, ~16 locales.
Part of the goal for these regions is to have them within a reasonable timezone of each other to make coordination easier. Part of the goal is to have “similar” languages together (like the English languages).
What is a lead?
A lead is not simply a copy of Zé. We’ll all get burnt out if we try and emulate everything he did. There’s a lot of responsibilities. Let’s split the role into two.
As the role is pretty extensive, it is best for it to be split into two separate lead roles:
“Community” leads
Essentially, this role is non-technical and involves working with people. Here’s a list of a lot of responsibilities included in this role. (There may be more!)
- Review and answer “people”-based P2 comments and requests
- Answer requests for new locals (research and approve, especially using Ethnologue)
- Weekly meetings (organize, take notes, post updates on how locales are doing)
- Moderate disputes between validators/translators
- Mentorships – Connect validators with other validators who can help and give pointers.
- Validators – find and approve validators; communicate with current validators
- Interface with the community team
- Interface with legal (as a result of Rosetta contacts)
- Review Rosetta sites to ensure they meet expectations
- Contact validators if a Rosetta site does not meet expectations and work to get them fixed.
- Write and maintain documentation
- Create and maintain policies (like the Rosetta expectations; new things may be needed in the future)
- Compile and post stats (on the P2)
- Generally, find people to do things
“Technical” leads
Technical leads are responsible for doing everything needed technically. Here’s a list of things that they may need to do:
- Answer technical questions on the P2 (deployment, other related things)
- Deploy Rosetta, including forums and P2s when those exist again.
- Create locales (after community lead approves)
- GlotPress – interface with the GlotPress team, including discussing future needs and helping implement those needs where applicable.
- Interface with the core team about upcoming core changes
- Interface with the meta team about necessary wordpress.org changes.
- Work on technical problems that local translations have
- Create and compile stats (with community leads)
- Write and maintain technical documentation
How do we find/appoint leads?
Everyone here (at the community summit) should be considered a “lead” in the WordPress community. Maybe we shouldn’t have one or two leads, but instead form a leadership team with everyone here who’s interested. The leadership team can work together to ensure no one gets burnt out and that no knowledge gets lost along the way. Today, a leadership team is formed.
Moving forward, we should look at who wants to be community-focused and who wants to be technically-focused. We have good coverage for community-focused, but we’ll need to bring in people to be technically-focused. We also have great timezone coverage!
Over time, we should consider having regional leads for each of the three regions described above, both for community and technical sides. (This means a total of six “leads.”)
Weekly Polyglot meetings
First things first, we need to start a weekly meeting.
- Ideally two or three meetings a week, 8-12 hours apart. Same agenda, but this allows people from different timezones to participate.
- Let’s make a Doodle for choosing the time for weekly meetings.
- Use this meeting to help new validators / translators with questions.
- Also get stats from localizers. How are teams doing? What progress are they making? Is a team almost there? How do we get them to 100%?
- Meetings should be held in #polyglots channel on Slack.
- Notes from the first meeting of the day can be posted to the P2 in draft form. Other note-takers can update after their meeting. Last meeting of the day publishes post.
Contributor Recognition
To start, we need to improve the badges on dot org profiles. How about three polyglots badges?
- A badge for members of the polyglots leadership team
- Badge for validators/editors. Potentially use this for moderators too, though can’t they get a support badge?
- Translators (anyone who’s translated a string and had it approved) get a third badge.
Final notes / actions
- Update Handbook
- Add handbook page with leadership team (including dot org usernames) so people can reach out and get advice.
- Include timezone information so you can find a local lead.
- Add a map (image map!) that shows what the regions are and who can help you in your region.
- Add a list of regions (non-graphic) as well.
- Talk to support team (Mika) about getting badges for moderators
- Start holding weekly meetings
- Find technical leads in each region
- Document Zé (and all that he did)
Participants
The following people attended this meeting at the WordPress Community Summit: Andrew dela Serna (Philippines), Birgit Olzem (Germany), Catia Kitahara (Brazil), Marko Heijnen (The Netherlands), Mayuko Moriyama (Japan), Petya Raykovska (Bulgaria), Shinichi Nishikawa (Japan), Sam Sidler (USA, wordpress.org), Takayuki Miyauchi (Japan), Xavier Borderier (France).
DeBAAT 11:44 am on August 17, 2015 Permalink | Log in to Reply
Interesting topic and clearly written (as I would expect from a Polyglot 😉 ).
Nevertheless, here is my first question:
With the introduction of plugins and themes, will there be a new persona type?
I mean, how do I address the owner (author) of the plugin or theme? In comparison to the WP Core (Translation) team being responsible for translating WP Core.
Or is or can be someone else responsible for the plugin or theme translations? If so, how do I appoint and address this person?
Looking forward to your answer.
Petya Raykovska 2:42 pm on August 17, 2015 Permalink | Log in to Reply
Hey @debaat, you make an excellent point.
The part about getting your theme/plugin translated by the community should probably make its way into the Theme/Plugin development handbooks as well, as it’s intended for plugin/theme authors. What we can do in the Polyglots handbook (intended for the translators and translation editors) is add a link, a reference to the pages in the plugin and theme handbooks related i18n and l10n.
We should, however, include documentation about the protocol we have for plugin authors to request their existing translators be added as a per project translation editor in the Polyglots handbook.
That should be added as a whole new section dedicated to handling separate projects.
Thanks for the reminder, adding a suggestion in the hackpad.
DeBAAT 8:25 pm on August 17, 2015 Permalink | Log in to Reply
Thanks for the compliments.