Distraction-free editing

Editing Wikipedia with VisualEditor on the mobile web

Distraction-free_editing.png
Illustration of a person editing Wikipedia on a mobile device — Distraction-free editing.png () by Jess Klein /Wikimedia Foundation, CC-BY-SA-3.0.

The Wikimedia Foundation’s goal for VisualEditor this year is to create a frictionless environment for editing on mobile to help editors publish more frequently, with more joy. After brainstorming, the Foundation’s Editing team came up with a set of mobile design principles to apply to a plethora of possible design interventions. This post describes our thinking behind the first round of interventions.

Intervention 1: Manage Performance Expectations

Evaluating the user experience, we noticed that certain areas of the experience felt pretty slow to editors. While performance is something that we will continue to work on (and can really only manage to some degree as the other part of the equation is the user’s environmental bandwidth), we can make this moment feel less painful for the user by managing their expectations around performance.

The key issue here is that users aren’t given any kind of feedback during moments like these. Many folks click their edit button and see this blank white screen with a spinner.

Blank_white_screen_with_a_loading_spinner.png
English: This blank white screen with a spinner provides no feedback to the editor about what is loading or happening.
Blank white screen with a loading spinner.png ( ) by Jess Klein /Wikimedia Foundation , CC-Zero.

We thought of a few different ways to address this, including microcopy telling users what’s happening, skeletons and loading screens. Ultimately, we decided to address this by creating a seamless animation transition. To do this we grey out the read mode and transition it to line up with the edit mode. Then when the editor is ready we seamlessly swap it in. We combined this with a user interface refresh to provide a more reassuring throbber and instructional microcopy. In addition to reassuring contributors, the loading overlay helps editors to maintain their focus on the edit that they initiated the editor with the intention of making.

Editing_Wikipedia_on_mobile.gif
English: In this gif, you can see that a user taps on an edit button and instead of seeing a blank white screen with a loader, they see a series of screens and overlays to indicate progress (and if we did this right, they won’t even realize that this is happening).
Editing Wikipedia on mobile.gif () by Image by Jess Klein CC0 and text from Wikipedia. https://en.wikipedia.org/wiki/Nellie_Bly, CC-BY-SA-3.0.

Intervention 2: Improve Wayfinding through Section Editing

We believe that mobile editors can be more productive when they are able to focus on editing only one section at a time.

While the performance expectation intervention is in the realm of meeting fundamental expectations, the second issue we tackled is more unique to Wikipedia: navigating to your edit! One complaint that we repeatedly heard from editors during user testing was that they would find something to edit, click the edit button and then take a really, really, really long time to scroll to the part of the page that they intended to edit. This is acutely painful for users on mobile devices because the amount of information revealed to them at any given time is significantly smaller than on a desktop experience. What was happening in mobile was that you’d click a section editing button and get taken to the editing view but scrolled more or less in the proximity of the section you intended to edit.

Our intervention removed all of the other content so that you can focus on just that one specific part of the content. This directly relates to our mobile design principles — we are removing stimulation and setting the stage so that an editor can do one thing at a time.

Way-finding_improvements_to_mobile_editing.gif
English: As you can see here, the contributor can get to the content faster!
Way-finding improvements to mobile editing.gif () by mage by Jess Klein, CC0 and text from Wikipedia. https://en.wikipedia.org/wiki/Nellie_Bly, CC-BY-SA-3.0.

Initial Testing Results

We tested these interventions on-wiki, on usertesting.com and, at in-person editing events. The initial feedback has been quite positive. Users have been able to maintain their location within the edit and are using words like “expected” or “obvious” when describing the behavior of the interactions.

We’ve also learned that many people expected to be able to have the functionality to edit the whole page as well as choosing to dive in and edit within sections. Additionally (while unrelated specifically to this intervention, but useful for the future iteration of the product), we observed several users attempting to switch back and forth between the different edit modes without much success.

Shipping and Next Steps

These first two interventions (the loading overlay and section editing) have already shipped to Wikipedia and, in addition to the qualitative analysis efforts that I described above, we have recently concluded an A/B test thatshowed that “contributors using Section Editing are ~3% more likely to save the edits they start than contributors using full-page editing.”

The loading overlay was deployed to all Wikipedias and the same was done for section editing after we analyzed the test results.

What’s next for VisualEditor on Mobile?

Although 3% seems like such a small increase, we are banking on lots of incremental interventions having a large collective impact. The Editing Team analyst, Neil Patel Quinn said, “Considering the difficulty of making it possible to contribute to an encyclopedia on a four-inch screen, a 3% increase from a single tweak to the interface is a real accomplishment.” The next three interventions that we are tackling are:

1. Make VisualEditor default for new users on mobile. All of our testing suggests that there are just too many steps for an editor to get into VisualEditor, which in theory, is the more new-contributor-friendly experience. Let’s lessen the burden and make VisualEditor more discoverable by openly testing out this hypothesis.

2. Make it easier to edit context items (links, citations, images, infoboxes, templates, etc.) on mobile. Editing these items is an unnecessarily complex activity. We’re creating a new part of the interface that will show additional details about, and actions related to, editable elements within articles. These interventions will help editors to focus on one thing at a time while simultaneously creating more structured workflows around specific editing tasks.

3. Make a single state toolbar. Contributors are confused about what steps to take to publish their changes, how to undo a mistake and go back without losing all of their changes, and how to get back into editing mode after “accepting changes”. That combined with the fact that contributors are confused about why the toolbar behaves in unexpected ways is why we need to refine the toolbar so that it can be used as a guidepost during editing.

A few things that you can do to help

Excited? Great! So are we. We want to collaborate with you to make this a great mobile editing experience. Here are three things that you can do right now.

Edit Wikipedia using your smartphone via the mobile web

The best way to help with this effort is to try editing on your phone. Don’t focus on the new features, just make some great additions to the encyclopedia.

Share feedback

After you’ve made edits or contributed in some other way on mobile, tell us about it by posting on our product page.

Incorporate user testing into an upcoming event

Do you organize events for editing Wikipedia articles? If so, we would love to collaborate with you to learn how Wikimedians are editing directly from you, so drop us a note on the Talk page.

Thanks to Ed Erhart, Peter Pelberg, Sherry Snyder, Bartosz Dziewoński, Carolyn Li-Madeo, and Ed Sanders for proofreading and feedback. Thanks again to all those who have participated as testers.

🤜🏽 David Chan, Bartosz Dziewoński, Ed Sanders, and Peter Pelberg for working on the implementation of the Wikipedia editing features described here.

Originally posted by Jess Klein to Down the Rabbit Hole on 22 July 2019.


Structured Data on Commons, Part Two – Federated Wikibase and Multi-Content Revisions

Structured Data on Commons (SDC) relies on two other pieces of software to make it work: federated Wikibase and Multi-Content Revisions (MCR). Both of these things required a lot of time and resources to make them work, with federated Wikibase developed by Wikimedia Deutschland, and MCR development shared by several teams across the Wikimedia Foundation and Wikimedia Deutschland. MCR, as one of the most significant changes to MediaWiki in the past decade, underwent an extensive proposal-and-discussion period before development.

Wikibase is a free, open-source database software extension for MediaWiki developed to as part of the Wikidata project. Federated Wikibase allows a wiki with Wikibase installed (the client) to communicate back to a central Wikibase installation (the repository). In the context of the structured data project, the client, Commons, needs to be able to get and return information from the repository, Wikidata. The information Wikidata holds that Commons needs is the structure and relationship between concepts being described in files Commons. For example, if an image depicts a house cat, the labeling of “house cat” as depicted is stored on Commons, while the concept of “depicts” comes from Wikidata.

Federation means making calls from one wiki’s Wikibase instance to another to retrieve information, and those calls have the potential to end up affecting the performance of the websites. Making sure that structured data didn’t cause such a slow down was one of the challenges with federated Wikibase. Additionally, enabling cross-communication between Wikibase instances required a lot of new code changes that sometimes had surprising side effects on the host wiki. The development teams spent months finding and fixing all of these problems.

Multi-Content Revisions completely changes how pages are assembled and displayed to a user. On a wiki without MCR, a page revision – that is, the version of a page as it exists when edited and saved at a particular state in time – is stored and displayed as a single type of data, such as some form of wikitext mark-up, JSON, or Wikibase entries. Since SDC needs to store and display more than one type of revision at a time, software needed to be written to change how a page revisions work for Commons.

MCR restructures a part of how MediaWiki stores information, by adding a layer of “indirection” as a way to link between revisions with different data components. The additional layer required not only new server-side code and an interface, but a massive change in the data schema and accompanying migration to the new schema.

To the left, the previous method of calling a page revision. To the right, calling a page revision using MCR.

Since the way page revisions and the data contained were stored in the back-end, there was additional work to make this change on the front-end, facing Commons users.

  • Diff views have to work with multiple slots. A diff view details a revision of a page, and engineering had to be done to show diffs from multiple slots of a revision.
  • Multi-slot views were needed. This work parallels the work on diff views, and shows the content of all slots when viewing a revision of a page.
  • An extra slot had to be configured in order to store Wikibase entities on MediaWiki in addition to wiki-text.
  • MediaWiki extensions have to be compatible with MCR, and the tools had to be identified and updated. This ensures, for example, that the tools we use to prevent spam and other malicious behavior work with MCR.
  • MediaWiki’s internal search engine, Cirrus Search, had to be engineered to work with MCR. Cirrus Search can crawl each slot, which will surface the information there to the widest possible audience. The enables semantic search of structured, linked data in files.

All of this engineering for MCR and federated Wikibase had to be completed before the Structured Data team was able to release its features to Commons. The Structured Data team is very grateful to the Core Platform, Wikidata, and Search Platform teams for all their work to make structured data storable, displayable, and searchable on Commons. With the infrastructure they created, the SDC team can create more powerful structured data features for Commons contributors.

Next: Part Three – Multilingual File Captions

Previously: Structured Data on Commons – A Blog Series


Art+Feminism is looking for an Executive Director to help further the vision we’ve developed over the past six years.

MoMA_Art_Feminism_2019_80.jpg
2019 Art+Feminism Wikipedia Edit-a-thon at The Museum of Modern Art, New York — MoMA Art Feminism 2019 80.jpg () by Manuel Molina Martagon, CC-BY-SA-4.0.

Founded in 2014, Art+Feminism is an award-winning do-it-yourself campaign to improve coverage of gender, feminism and the arts on Wikipedia. Wikipedia’s gender trouble is well-documented; in a 2011 survey, the Wikimedia Foundation found that less than 10% of its contributors identify as women. This lack of participation has led to significant gaps in the content on the world’s most popular online research tool. Since 2014, over 14,000 people at more than 1,100 events around the world have participated in our edit-a-thons, resulting in the creation and improvement of more than 58,000 articles on Wikipedia. Our events range from small gatherings at coffee shops to hundreds of folks at the largest cultural institutions in the world and take place on all six inhabited continents. Our organizing practices are horizontal and rhizomatic and our feminism is trans-inclusive and intersectional.

The Executive Director sets the strategic vision and executes the annual plan in collaboration with the Lead Organizers and manages relationships with the Board of Directors. The Executive Director, Lead Co-Organizers, and the Project Administrator form the Core Leadership Team of Art+Feminism. The Executive Director must have strong project management skills, a demonstrated history of work at the intersection of the arts and social justice, an understanding of intersectional feminist organizing principles, experience generating diverse financial support, and a knowledge of the Wikimedia community or another open-source/online community. Art+Feminism is entering into its seventh year but this will be our first year as a non-profit. While we do have great systems in place for community organizing, we seek an Executive Director who is also skilled at operations and development, and committed to developing leadership among other members of the team. Because the position requires international outreach and coordination, fluency in at least one language other than English is preferred.

The Executive Director’s responsibilities include:

Leadership

  • Work with the Core Leadership Team to provide a strong day-to-day leadership presence that incorporates our mission, vision, and values into our everyday operations.
  • Work with the Board of Directors and the Core Leadership Team to develop the project’s mission, vision and values.
  • Draft strategic planning documents alongside the rest of the Core Leadership Team.
  • Represent Art+Feminism at art and social justice conferences, events, and Wikimedia Community gatherings.
  • Manage all staff and contractors, including the Project Administrator
  • Collaborate with the lead organizers to plan and implement the annual campaign.

Development

  • Lead development goals and activities including grants administration and reporting.
  • Lead various fundraising activities.
  • Write grant proposals and compile supporting documents.
  • Recruit Board Members and cultivate Board.
  • Work with Core Leadership Team and Regional Organizers to identify and cultivate new funding sources.

Marketing and Communications

  • Work with the Core Leadership Team to oversee the development and execution of an annual communications plan, including marking, social media, and educational programming.

Operations

  • Co-manage key institutional partnerships, such as with the Museum of Modern Art.
  • Maintain and ensure the execution of project timelines.
  • Establish, improve and maintain efficient operations and project management platforms.
  • Direct and administer all financial plans and work with the Project Administrator to manage accounting processes for grant reporting and federal reporting.
  • Oversee regular meetings with Core Leadership Team members
  • Compose budgets for specific programs and processes.
  • Oversee risk management and legal activities, such as contracts
  • Work with the Project Administrator to analyze and improve operations and workflows.

Qualifications

  • Must be passionate about and have experience with the arts, intersectional feminism, and open source culture.
  • Must have demonstrated a commitment to developing leadership among other members of the team.
  • Requires proven fundraising and development experience.
  • Requires a minimum of 3 years of non-profit leadership experience or equivalent experience; 5 years preferred.
  • Requires strong self-awareness and high emotional intelligence.
  • Must have the ability to work independently and as part of a team.
  • Requires a demonstrated ability to develop and maintain productive working relationships with colleagues (e.g. staff, volunteers, donors, and board members.)
  • Preferably have strong financial management skills and analytical abilities.
  • Preferably have experience editing, organizing, or analyzing Wikipedia.
  • Preferably have experience with metrics/analytics tools.
  • Preferably have experience with project management and customer relations tools (we use Slack, Streak, and Trello.)
  • Requires flexibility to work evenings and weekends, and to travel for the role.

Executive Director reports to the Board of Directors. This position is entirely remote; the Core Leadership Team, which is located in four different cities, meets weekly via video chat. The candidate must be legally authorized to work in the United States. Due to our funding structure, this role is currently a one-year contract beginning September 1, 2019, with an expectation for renewal, pending the successful accomplishment of the above tasks.

Salary Range: $60-75,000/year. This is currently an independent contractor position but may be transitioned to employee status, depending on our legal and accounting advice. Application Deadline: August 13, 2019

Art+Feminism provides equal employment opportunities to all without regard to race, ethnicity, color, religion, gender identity, sexual orientation, national origin, age, disability or genetics. Candidates from groups underrepresented in tech are especially encouraged to apply.

To apply, please send a cover letter and resume to us at info@artandfeminism.org.


Upcoming Wikimedia events for August 2019

Bali_Odalan_celebration_in_Pura_Kehen_Bangli_temple,_dancing_girls.jpg
Balinese Hindu celebrate the birthday of their village temples once every 210 days (= Balinese year of 6 months each of 35 days). This festival is called Odalan. It is major performance arts and community event for the village. — Bali Odalan celebration in Pura Kehen Bangli temple, dancing girls.jpg () by BMR & MAM, CC-BY-SA-2.0.

August is an active month for the Wikimedia movement. From local meetups to Wikimania in Stockholm. We’ve collected some upcoming events from across the movement to share. Did we miss any? Add your events to the calendar, and leave a comment with suggestions!

August 1

August 2

August 4

August 8

August 9

August 10

August 11

August 14

August 16

August 23

August 24

August 29

August 31

Recurring Events


Tech News (2019, week 31)

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.

Translations are available: Deutsch • ‎English • ‎español • ‎français • ‎polski • ‎português do Brasil • ‎suomi • ‎čeština • ‎русский • ‎українська • ‎עברית • ‎العربية • ‎नेपाली • ‎中文 • ‎日本語

Problems

  • Wikidata will be in read-only mode on 30 July from 05:00 to 05:30 UTC because of a server switch. [1]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 July. It will be on non-Wikipedia wikis and some Wikipedias from 31 July. It will be on all wikis from 1 August (calendar).

Meetings

  • You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 31 July at 15:00 (UTC). See how to join.

Tech news prepared by Tech News writers. More information on how to contribute is available at Tech/News#contribute

Translate • Get help • Give feedback • Subscribe or unsubscribe for on wiki distribution.


Structured Data on Commons – A Blog Series

One_hell_of_a_mess....jpg
It’s a picture of a big analog synthesiser… — One hell of a mess….jpg ( ) by Tom Cronin , CC-BY-SA-2.0.

Wikimedia Commons is the freely-licensed media repository hosted by the Wikimedia Foundation. Started in 2004, Commons contains over 50 million files—all of which are meant to contain educational value and help illustrate other Wikimedia projects such as Wikipedia. As with all Wikimedia projects, the content is created, curated, and edited by volunteers. In addition to the content work on the wikis, the Commons community participates in organizing and running thematic media contribution campaigns around the world such as Wiki Loves Monuments, Wiki Loves Food, and Wiki Loves Africa.

Structured Data on Commons (SDC) is a three-year software development project funded by the Sloan Foundation to provide the infrastructure for Wikimedia Commons volunteers to organize data about media files in a consistent, linked manner. The goals of the project are to make contributing to Commons easier by providing new ways to edit, curate, and write software for Commons, and to make general use of Commons easier by expanding capabilities in search and reuse. These goals will be served by improved support for multilingual content and ways of working on Commons. This is the first in a blog series that will document the different parts of implementing SDC, starting with this introduction to the project and brief outlines of the software involved in making it happen, each to be covered more in-depth later.

Wikidata_for_Commons-logo.svg
Wikidata for Commons-logo.svg ( (upload date)) by , PD ineligible.

Part One – an introduction to the software

Commons is built on MediaWiki, the same software used by the other Wikimedia projects. MediaWiki was primarily developed to host text. Because of this, information about files on Commons is stored in plain-text descriptions (wikitext, templates) and categories. The information includes at least the uploader, author, source, date, and license of a file, with many other optional items. These pieces of data are usually only available in one language—mostly English—and, most importantly, not structured in a way that software developers can consistently write programs to understand the data that is stored in file pages. Data that is structured in a consistent, understandable way is called “machine-readable,” and having machine-readable data is a primary goal for the Structured Data on Commons project.

In order to provide this consistent, machine-readable data, the information needs to be stored in a database instead of plain-text in MediaWiki. Wikibase is the software solution for that need. Wikibase is the software that enables MediaWiki to store structured data or access data that is stored in a structured data repository, developed by Wikimedia Deutschland to support Wikidata. The project needed a way to use Wikibase on other wikis and connect the information back to Wikidata, a feature which had recently been developed. Called Federated Wikibase, this software is crucial to organizing media information on Commons.

The next piece of software needed was Multi-Content Revisions (MCR). MCR is a way of putting a wiki page together that needs to pull information from different places with different ways of storage—in other words, MCR can assemble information from both MediaWiki and Wikibase to be displayed and managed together. More information about Federated Wikibase and MCR will be covered in a future post in this series.

Once Federated Wikibase and MCR were ready for release, the Structured Data on Commons team produced the first user-facing feature to use the new underlying software: multilingual file captions. Captions—stored in Wikibase—have a similar function to the description template used on file pages, which is stored in MediaWiki; they both are supposed to say what is in the file. However, descriptions are not limited in length, they may contain extra detail not necessary to finding the file including wikilinks and external links, and while the template supports adding extra languages, the process is not necessarily easy. Captions support an easier way to add other languages and captions are limited in length and should describe the file only in a short, factual way. This makes files with captions easier to find in search in a structured, multilingual way for both humans and software programs alike.

After releasing Wikibase and MCR to Commons with captions to make sure it all worked, the development team put out support for the first structured statement type, “depicts.” Depicts statements make simple, factual claims about the content of a file and link to their matching concept on Wikidata. To further develop depicts statements, support for qualifiers was released as well. Qualifiers allow depicts statements to have more information about what is being depicted. So for example, a picture of a black house cat can have the structured statement depicts: house cat[color:black]. Depicts statements are on a new tab that was introduced to the file page, “Structured data.” Aside from captions, all structured data is on this tab.

Depicts_with_a_qualifier.png
An example of a depicts statement with a qualifier. — Depicts with a qualifier.png () by User:Keegan (WMF), CC-BY-SA-3.0.

After this short introduction, the SDC blog series will have further information about depicts and qualifiers, as well as support for making other types of statements about files.

Next: Part Two – Federated Wikibase and Multi-Content Revisions


Welcome, Education community, to Wikimedia Space

File does not exist : Wikimedia_Education_Conference_2019_group_photo_02.jpg

Dear Wikimedia Education community,

We’re so excited to invite you to explore Wikimedia Space with us through a new category just for Education. We’ll be piloting the use of this category to centralize communications about Wikimedia & Education, share active discussions, and announce events on the centralized map and calendar. You’ll still be able to find static information and resources on Outreach Wiki, with more dynamic information living on Wikimedia Space. 

Wikimedia Space is a new platform introduced by the Wikimedia Foundation which aims to become a point of centralization and redistribution of news and conversations. The Space is also a place where anyone can ask any question related to Wikimedia and find answers. Wikimedia Space has a variety of multilingual features that are currently being expanded, and can already host resources and conversations in multiple languages. As the Wikimedia Space is still a prototype, together we can explore different opportunities and collaborations. 

Some of the future possibilities include adding lesson plans, publishing event reports, sharing news, and even fostering mentorship in closed groups. Let’s brainstorm together on what we want for our Education category!

Cheers!


Growth Newsletters #09

Welcome to the ninth newsletter from the Growth team! This newsletter is also distributed on wikis.

The Growth team‘s objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

Opening Growth features to more wikis

The Growth team has existed for about one year. During that time, we have developed several features that we think can help increase retention. Though we are still gathering data to detect scientifically whether the features increase retention, we think that some of the features are ready to be deployed on more wikis that want to experiment with them.

If your community is enthusiastic about welcoming newcomers, we encourage you to contact us so that we can verify together if your wiki is eligible.

Then, go through the checklist to start the process of getting these features:

  • Help panel: allow newcomers to find help and ask questions while they edit.
  • Welcome survey: learn what topics and types of edits newcomers are interested in.
  • EditorJourney: learn what workflows newcomers go through on their first day.

General news

Indicator that encourages users to look at their Notifications for responses to their questions (MMiller (WMF), CC-BY-SA – source)

  • A new quarter of the year has started, and the team has set our goals for the next three months. The most important goals are:
    • Newcomer homepage: increase activity through a task recommendations module. Now that we have seen several weeks of positive activity on the newcomer homepage, we think that the most important thing to add is a way for newcomers to find tasks to work on. The challenge will be recommending the right kind of tasks at the right point of their journey.
    • Newcomer homepage: increase feature discovery rate by 100%. Right now, only 20% – 30% of newcomers ever visit their homepage. We want to double that number by making sure all newcomers know how to find it.
    • Help panel: increase usefulness through improvements to affordance, search, and UX flow. We have looked closely at data and anecdotes from the usage of the help panel, and we plan to pursue specific improvements to increase its effectiveness (see accompanying image of a feature that helps newcomers find responses to their questions).
  • Wikimania is coming up next month, which includes a “Community Growth” space. We hope to see people from all communities there to talk about how to bring newcomers into our movement.
  • We have started to deploy features to our team’s fourth target wiki: Arabic Wikipedia. That wiki is the biggest one we target, it has a high percentage of mobile users, and also is our first right-to-left language. This will help us make sure that our features are valuable for as many types of users as possible.

Mobile homepage and early analysis

Button to help newcomers find their homepage from their empty Contributions page (MMiller (WMF), CC-BY-SA – source)

  • The mobile version of the newcomer homepage was deployed to Czech, Korean, and Vietnamese Wikipedias. Now, newcomers can access their homepage from both desktop and mobile devices.
  • We have published our first set of data about the performance of the newcomer homepage. In summary, we are happy with the homepage’s performance so far. We see about half of visitors clicking on something, and the majority of them returning to the homepage multiple times.
  • Because we see positive usage of the homepage, we will deploy several small features in the next two weeks that help more newcomers discover their homepage (see accompanying image of a feature that helps newcomers discover their homepage from their empty Contributions page).
  • As listed in our goals above, we’ll be starting to focus on adding task recommendations to the newcomer homepage. We’ll be publishing early thoughts on this feature so that community members can give their thoughts and advice.

Growth team’s newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.


Tech News (2019, week 30)

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available :

Bahasa Indonesia • ‎Deutsch • ‎español • ‎français • ‎polski • ‎português do Brasil • ‎suomi • ‎čeština • ‎русский • ‎українська • ‎עברית • ‎العربية • ‎中文 • ‎日本語

Recent changes

Problems

  • The release of the last version of MediaWiki (1.34.0-wmf.14) has been blocked for groups 1 and 2. [2]

Changes later this week

  • Phabricator database will be moved to a different server. Writes will be blocked on Thursday 25 July, between 05:30 and 06:00 AM UTC. Reads will remain unaffected. [3]
  •  The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 July. It will be on non-Wikipedia wikis and some Wikipedias from 24 July. It will be on all wikis from 25 July (calendar).

Meetings

  •   You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 24 July at 15:00 (UTC). See how to join.

Future changes

Tech news prepared by Tech News writers. More information on how to contribute is available at Tech/News#contribute

Translate • Get help • Give feedback • Subscribe or unsubscribe for on wiki distribution.


Wikimedia Foundation’s final Medium Term Plan and FY2019-2020 Annual Plan

Motiur Rahman Oni CC BY-SA 4.0

After opening a community comment period in early April this year, collecting and incorporating that feedback, the Wikimedia Foundation is happy to announce our Medium Term Plan for 2019-2023 was approved by our Board of Trustees! You can view the final version here: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Medium-term_plan_2019 

This process wouldn’t have been possible without communities’ participation, and we want to thank each of you for taking the time away from doing your favorite thing on the wikis to comment on our organization’s plan for the next 5 years. This new process, which we implemented for the first time this year, allows us to plan for a longer time frame. It also gives us a more flexible structure for annual planning that allows us to incorporate recommendations from the movement strategy. 

Today, we are publishing both the Wikimedia Foundation’s Medium-term Plan and our annual budget and plan for the fiscal year 2019-20. This 2019-20 plan is the first instance in this new planning process, and over the next 5 years, we will continue to create plans that focus on the priorities we identified. We will review the progress towards our annual goals on a quarterly basis, and continue to share these reports publicly. 

We hope to continue these conversations and collaboration as we work towards our strategic direction.