Staying in sync on a globally distributed team spread across timezones takes a lot more than using the right tools!

In part 1, we discussed the various tools the distributed mobile web engineering team at the Wikimedia Foundation uses to stay synchronized. While the tools are critical to our success, it takes a lot more to ensure that we can successfully work together despite the geographic distances between us. Our development procedures and team norms are the glue that holds it all together.

As with the tools we discussed previously, the practices and norms I’ll discuss below are by no means unique to—or only useful for—distributed teams.

Rituals

When you can’t just walk across the office or poke your head over the cubicle wall to sync up with a teammate, regular, structured moments for real-time, intra-team communication become critical. The mobile web team is a scrum-inspired agile team. As such, we use regular stand-ups, planning meetings, showcases and retrospectives to have some real-time, focused conversation with one another. Because we hold these meetings at a regular cadence and consider them critical touch points for the entire team, we think of them as rituals rather than regular meetings.

The WMF Mobile Apps engineering team holding a stand-up meeting with remote participation.

The stand-ups in particular are excellent for synchronization. Unlike traditional Scrum, we do not hold stand-up meetings every single day; rather, we do ours on Monday, Wednesday and Friday. We use this time to let everyone know what we’ve been working on, make commitments about what we will be working on, alert the team if there’s anything blocking us from getting our work done and quickly triage any bugs that have been reported since we last met. While we can always look in Mingle (our project management tool, see part 1) to see who is working on what and when, these brief meetings make it easier to raise issues and communicate about where further collaboration between teammates may be valuable.

Often, conversations about blockers and problem areas start during the stand-up and continue between the interested parties after the meeting has concluded. The meeting is kept short, time-boxed at 15 minutes, so there is little overhead; the meeting stays focused and we communicate just enough to keep us all moving forward.

The other rituals provide a great way for us to stay in the loop, bond with one another and allow the team tremendous influence over the product and our process. While their primary purposes are not about day-to-day synchronization like the stand ups, the other rituals are essential for reinforcing our self-organizing team. Particularly since we are distributed, these rituals are sacred, as they are the primary moments when we all know we can work together in real time.

(more…)

Developing and maintaining the code and infrastructure that enable the global Wikimedia volunteer community to contribute to Wikipedia and our other projects is at the heart of the Wikimedia Foundation’s work. In the past 2.5 years, I’ve led our combined Engineering and Product department. We’ve done lots of hiring and grown the department from roughly 35 to 100+ people during that time period. We have many projects underway which we hope will dramatically improve the experience of our contributors and our readers, including VisualEditor, Flow (a new discussion system), and new reader and contribution features for mobile users.

About a year ago, I announced that we needed to start thinking about dividing the responsibilities of the VP of Engineering and VP of Product into two separate leadership roles (closely collaborating on a day-to-day basis), at which point I’d focus on the VP Product part of my current role. The Director-level roles referenced in that announcement now exist—we’ve since hired a Director of User Experience and a Director of Analytics. Now it’s time for us to search for a VP of Engineering to complete the change. We’re partnering in this search with Julie Locke from Vantage Partners, an executive search firm.

We’re looking for someone who shares some fundamental beliefs with us:

• that working in partnership with a global community of open source developers, and in close dialog with our users, is the best way to achieve lasting and positive changes to our technology;
• that teams do their best work when they’re inspired and empowered to do good work, not because they’re “managed” to do it;
• that it’s the job of management to create the conditions for teams and individuals to succeed, by equipping them with resources, mentoring and supporting them in their adoption of effective processes for self-organization;
• that highly iterative development (“release early, release often”) delivers the most value to our readers and our community;
• that hiring for diversity—of geography, gender, culture, skills, etc.—leads to more successful and effective teams.

Ideally, you’ve put these beliefs into practice in the real world, in a context where you’ve delivered open source technology to users with short delivery/deployment cycles, where you’ve supported operation of a high traffic site reaching millions of users, and where you’ve held leadership responsibilities in service of multiple, diverse, interdependent teams. You’re passionate about open source, and above all, you’re excited by the Wikimedia vision: a world in which every single human being can freely share in the sum of all knowledge.

Wikimedia has great technical challenges ahead: continually modernizing our user experience, decoupling monolithic aspects of our architecture, and supporting the greatest innovations our community comes up with. We’re looking for a collaborative, brilliant and effective leader who can help us tackle these challenges. If that describes you, take a look at the full job description, and apply today.

Erik Moeller
Vice President of Engineering and Product Development, Wikimedia Foundation

Major news in October include:

• A report on the Open Access Media Importer, a tool that transfers multimedia files from scientific publications to Wikimedia Commons;
• A request for proposals for a new datacenter in the continental US, published by the Operations team;
• The creation of the Autonym Font, which allows language names to be displayed properly without degrading page loading time.

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.

(more…)

This post is available in 8 languages:

English • Afrikaans العربية •  Español • Français • עברית • Nederlands • Português • русский • isiXhosa

English

In November 2012, the students of Sinenjongo High School penned an open letter on Facebook, encouraging cellphone carriers to waive data charges for accessing Wikipedia so they can do their homework. In May 2013, filmmaker Charlene Music and I asked them to read their open letter on camera. Below is the video of their letter:

The cost of data is a major obstacle to accessing the free knowledge on Wikipedia for hundreds of millions of people. These students want their cellphone carriers to sign up to Wikipedia Zero, a partnership program organized by the Wikimedia Foundation to enable mobile access to Wikipedia – free of data charges – in developing countries.

We will be sharing the longer documentary about the class as soon as it’s ready. While we are still editing the longer documentary, we’re looking for:

1.) A few skilled volunteers who can help to translate captions to accompany the video above and the longer documentary. There are currently eleven official languages in South Africa alone. We need volunteers to create captions for all those languages, and as many other languages as possible.

2.) A motion graphics or digital artist who could help us design and animate a few titles, maps and statistics for the documentary. If you are interested, feel free to email me: vgrigaswikimedia.org or get in touch with me on my talk page User:Vgrigas.

3.) If you agree with these students, please share the video above.

Victor Grigas
Visual Storyteller, Wikimedia Foundation

(more…)

Wikipedia founder Jimmy Wales and Telenor CEO Jon Fredrik Baksaas at celebration.

As we announced today, the Wikimedia Foundation and Telenor have expanded our Wikipedia Zero partnership established in early 2012 to now include Myanmar. Wikipedia founder Jimmy Wales was in Oslo today and celebrated the agreement with Telenor’s President and CEO Jon Fredrik Baksaas.

On 27 June 2013, Telenor was named one of two successful applicants for a telecommunications license in Myanmar. With new mobile competition the country will see better network service, internet-capable phones and lower prices to drive mobile internet usage.

This is a big deal because Myanmar currently has one of the lowest mobile penetration rates in the world of less than 10 percent – only North Korea and Eritrea have lower rates. The Myanmar government’s stated objective is to increase mobile penetration to 80 percent in the next three years (overall internet penetration is estimated at roughly one percent). Another 40 million people will get mobile service, and many of them will be introduced to the internet for the first time.

With the extension of the partnership, Telenor Myanmar’s future mobile subscribers will be able to access the vast knowledge base in Wikipedia free of data charges. And they will be able to freely contribute their voices to Wikipedia. Today some people in Myanmar use Wikipedia, primarily in English, but usage is not widespread. The local Wikimedia community is working to grow the Burmese language version to reach a wider audience.

Removing barriers to access Wikipedia for people in Myanmar is a major step toward our goal of making the sum of all human knowledge available to everyone. We’re excited to see the benefits of this new partnership unfold.

Carolynne Schloeder
Director of Mobile Programs, Wikimedia Foundation

The Beta Features preferences page.

We’re pleased to announce Beta Features, a way you can try out new features on Wikipedia and other Wikimedia sites before they are released for everyone.

Beta Features lets developers roll out new software in an environment where lots of users can use these features, then give feedback to help make them better.

You can think of it as a digital laboratory – where community members can preview upcoming changes and help designers and engineers make improvements based on their suggestions. (more…)

Language Committee Logo

The Language Committee of the Wikimedia Foundation, which is in charge of developing and processing new language projects, has decided that any language should be admissible for use on Wikidata. As always this comes with several considerations.

• The language needs to have an ISO-639-3 code, which is a numeric representation of language names particularly in computer systems. Languages used with multiple scripts need to be configured in this way.
• Historic languages are permitted; newly minted words are not.
• Constructed languages are permitted.
• Language Localisation on MediaWiki is not required for the use of Wikidata.

When content is added by users that do not comply with the prescribed conditions, the labels added by such users will be removed.

As Wikidata moves towards a repository of useful statements, it is likely that this information will be presented in an increasing number of Wikipedias. As items in Wikidata are enriched, all infoboxes in various Wikipedias that rely on data from Wikidata will be enriched as well.

Gerard Meijssen, Language Committee

Discussions are the backbone of all Wikimedia projects. Whether it’s finding a reliable source, settling on spelling and punctuation conventions, or picking an article to feature on the main page, our community of volunteer editors makes countless decisions each day simply by talking to each other. However, the way that editors communicate today – using freeform wiki pages – is confusing and difficult for new users to grasp. Flow is the Wikimedia Foundation’s project planned to create discussion and collaboration software that improves the experience for all our users, letting them focus on creating and improving content instead of mastering the talk page form.

When comments and discussion first appeared on the Internet, they brought the promise of brilliant minds discussing the issues of the day in a thoughtful, courteous fashion. Instead, what we got was a lot of: “FIRST POST!” “Jake sucks,” “Kylla rulez”, and “aliens caused climate change!!!” The Internet world dealt with this problem in various ways: by locking down poster permissions, paying staff to moderate content, or even turning comments off entirely.

Wikipedia and its sister projects face some different challenges – while the content of the encyclopedia grows in size and quality through peer-to-peer discussion and collaboration, the fact that anyone can participate in this process is still not obvious to most people who use Wikipedia as a resource. We know that a small, homogeneous contributor pool leads to gaps in knowledge and biased content, as well as overworked and frustrated editors. There are countless potential contributors who could pitch in to help, but who are dissuaded from participating in content discussions because of intimidating software. But, like other online discussion spaces, we also need to balance openness with tools to keep discussions productive and healthy.

(more…)

When an article on Wikipedia is available in multiple languages, we see the list of those languages in a column on the side of the page. The language names in the list are written in the script that the language uses (also known as language autonym).

This also means that all the appropriate fonts are needed for the autonyms to be correctly displayed. For instance, an article like the one about the Nobel Prize is available in more than 125 languages and requires approximately 35 different fonts to display the names of all the languages in the sidebar.

Language Autonyms

Initially, this was handled by the native fonts available on the reader’s device. If a font was not present, the user would see square boxes (commonly referred to as tofu) instead of the name of a language. To work around this problem, not just for the language list, but for other sections in the content area as well, the Universal Language Selector (ULS) started to provide a set of webfonts that were loaded with the page.

While this ensured that more language names would be correctly displayed, the presence of so many fonts dramatically increased the weight of the pages, which therefore loaded much more slowly for users than before. To improve client-side performance, webfonts were set not to be used for the Interlanguage links in the sidebar anymore.

Removing webfonts from the Interlanguage links was the easy and immediate solution, but it also took us back to the sup-optimal multilingual experience that we were trying to solve in the first place. Articles may be perfectly displayed thanks to web fonts, but if a link is not displayed in the language list, many users will not be able to discover that there is a version of the article in their language.

Autonyms were not needed just for Interlanguage links. They were also required for the Language Search and Selection window of the Universal Language Selector, which allows users to find their language if they are on a wiki displaying content in a script unfamiliar to them.

Missing font or “tofu”

As a solution, the Language Engineers came up with a trimmed-down font that only contains the characters required to display the names of the languages supported in MediaWiki. It has been named the Autonym font and will be used when only the autonyms are to be displayed on the page. At just over 50KB in size, it currently provides support for nearly 95% of the 400+ supported languages. The pending issues list identifies the problems with rendering and missing glyphs for some languages. If your language misses glyphs and you know of an openly-licensed font that can fill that void, please let us know so we can add it.

The autonym font addresses a very specific use case. There have been requests to explore the possibility of extending the use of this font to similar language lists, like the ones found on Wikimedia Commons. Within MediaWiki, the font can be used easily through a CSS class named autonym.

The Autonym font has been released for free use with the SIL Open Font License, Version 1.1.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering, Wikimedia Foundation

Today Airtel and the Wikimedia Foundation announced a partnership to launch Wikipedia Zero, an initiative to provide free access to Wikipedia on mobile phones. This partnership with Airtel will help provide Wikipedia access to 70 million new users in sub-saharan Africa, starting in Kenya.

One exciting aspect of this partnership is that we are reaching a group of people we’ve never been able to reach before: mobile phone customers who don’t have internet access.

Throughout most of the developing world, data-enabled smartphones are the exception, not the rule. That means billions of people currently cannot see Wikipedia on their phones. Which phones? Low-cost basic phones (usually called feature phones or candy-bar phones). Phones like this:

So the challenge is, how do we reach the billions of people in the world who aren’t on the internet?

With text messaging. Even phones like these can send and receive text messages.

So for the first time, we are testing a service to allow access to Wikipedia articles via text message. It can work with any phone, even the most basic feature phone. You don’t even need an application.

How does Wikipedia via text work? A search is started in the same way people already use their phone to check their balance or add airtime. To search for a Wikipedia article through the Airtel partnership, a subscriber simply dials *515# on their phone, and they’ll get a text message inviting them to search Wikipedia. The subscriber enters a topic (like ‘Cheetah’) in the same manner they would send a text message.
(more…)