Audiences Technology Working Group

Disbandment

This working group was officially disbanded in June 2018 with the work of the group being carried out in an official capacity in the Platform Evolution Program.

Problem Statement

In recent months, teams across the organization have authored documents outlining both needs of, and issues with the current WMF technical infrastructure. During conversations around these topics it has become increasingly clear that stakeholders around the organization are not aligned on goals for our infrastructure which was making it difficult to move discussions forward in a productive way.

Goal

Enable teams within the Wikimedia Foundation to execute our Movement Strategy by facilitating technical collaboration, decision making, and solution development.

Deliverables

The Audiences and Technology Working Group (ATWG) will work towards its goal by working in a technically diverse, cross departmental group to develop 4 key deliverables:

1. A comprehensive, prioritized list of issues and requirements for our infrastructure
2. Infrastructure goals to serve as criteria for evaluating technical solutions
3. Process recommendations for developing product and technical solutions with proper feedback loops
4. Develop a Cross Departmental Program (CDP) on Platform Evolution to be funded in the FY18-19 Wikimedia Foundation Annual Plan.

Outcomes

After the ATWG completes its task, we hope for the following outcomes:

1. TechCom will be able to use the list of issues in order to prioritize solving issues in a systematic way.
2. Cross-department groups will use infrastructure goals in order to develop holistic solutions. TechCom will use these goals as guidance for evaluating solutions.
3. The CPO and CTO will implement process recommendation in order to facilitate better planning and roadmap alignment between the Audiences and Technology departments.
4. The CDP on Platform Evolution will be used to fund the work in order to execute solutions using the priorities, goals and process recommendations developed by the ATWG.

Out of Scope

The ATWG will not:

• Develop or propose technical solutions
• Vet or approve technical solutions

While our ultimate goal is developing and implementing solutions for our infrastructure issues, this is outside the scope of this working group.

We believe that development of technical solutions should happen in forums like the Dev Summit and with cross-discipline teams throughout the year. Those solutions should lead to Technical RfCs that TechComm can discuss and evaluate.

We do hope that the recommendations and outcomes of this working group will make it easier for teams to develop holistic technical solutions which incorporate the needs of the entire organization by providing a framework and process for doing so.

Participation

Joining

Those interested in joining the workgroup can post a comment on the talk page or email Corey Floyd (cfloydwikimedia.org).

Venue

As this group will attempt to synthesize the needs of the entire organization into a single document, it is key that we can gather view points from a diverse group of individuals and disciplines. At the same time, we have time zone constraints and practical limitations for productive in-person meetings.

For these reasons, this working group will try to incorporate both in-person and asynchronous opportunities for participation.

Time Investment

The goals of this group are ambitious and will require a lot of thinking and writing. The hope is that through collaboration we can shoulder this load together, but we also need to be realistic and honest about the fact that this will mean a significant time investment from multiple individuals over the course of several months. Those who join this group should be aware that they are signing up for multiple hours of work.

Leaders

While collaboration is key for gathering the information we need, ownership is important for assembling this information into a cohesive document. We will need volunteers to step up and coordinate during the process of creating these documents.

Process

The work will be split up into several exercises and meetings. The first is problem identification, which is outlined here:

Exercise 1: Problem Identification

More exercise and steps will be added here as the group identifies more concrete actions.

Timeline

The goal is to have a document prepared for leadership before annual planning to help guide and shape the work for the upcoming year. This is an ambitious goal. However, we can organize the work in order to make it more manageable.

Time	Milestone
November 2017	Create Work Group Proposal
	Organization socialization and participation invitation
	C-Level sponsorship
December 2017	Gather and organize issues
January 2018	Define Infrastructure Goals and Criteria
	C-Level check in
February 2018	Develop Program for Platform Evolution
	Submit Program for Annual Plan
March 2018	Develop Process Recommendations
	C-Level check In
	Dissolve Group

Background

The following section outlines the general thinking behind the three major deliverables of the working group.

Problem Identification and Prioritization

There has been a large generation of ideas regarding our infrastructure. This information is scattered across several documents, email chains, and verbal communications. The scope of these topics range from deep technical issues and open source principles to user value and engineer productivity.  

Before we begin solving our issues and planning for the future, we first must begin the arduous task of assembling this information and organizing it in a form that can be systematically discussed.

Infrastructure Goals and Solution Criteria

While many solutions to our issues have been proposed, we have had difficulty discussing them productively. We believe this difficulty partly stems from the lack of a shared set of goals around our infrastructure. Or to put it another way, since everyone is judging solutions by a different set of criteria, it is much harder to have to come to consensus on which tradeoffs are acceptable and which are not. 

In order to facilitate any decision making processes, we need to develop some overarching goals for our infrastructure to make discussions around solutions more productive.

Process for Collaboration and Alignment

Generally, technical solutions are developed by a single team and are primarily designed to serve a team goal. While in the best cases, teams do the legwork of ensuring that the needs of the rest of the organization are well considered, this is a difficult burden for any one team to shoulder. It requires a lot of cross team coordination which often “interrupts” other teams as they don’t share the same goal and haven’t budgeted time or resources to support other teams' goals. Without aligned roadmaps, teams find it difficult to work with one another.

Solutions that are typically developed within the Audiences department are, in many cases, only presented to Technology teams well after the bulk of product thinking and technical design is complete. This frequently results in Technology teams feeling that they weren’t consulted early enough in the process or that TechCom RfCs are proposed much too late to receive meaningful input.

On the other side, Technology solutions are many times developed and discussed in forums where Audience representation is low and the ramifications aren’t fully understood by product teams. These solutions often don’t receive evaluation from product managers, which can led to solutions that don’t consider user value or long-term product goals.

In addition, there are needs or users which are not fully represented by either Technology or Audiences or which relate to broader mission objectives, such as expanding the volunteer community or encouraging third-party use of our tools. Even some of our existing products are not fully supported by a team. Solutions proposed by Technology or Audiences can find themselves at odds with underrepresented projects or objectives, which can undermine consensus without an effective means to address the conflict.

It is clear that we have a gap in our processes where we need to obtain cross-team buy-in and collaboration much earlier on. Rather than analyzing benefits in one department and then looking at costs in another, we need a way to analyze product goals and technical impacts sooner in the process. We also need a place to set goals and align roadmaps before work begins to ensure teams are working on common goals.

Contributors

The following staff have contributed thoughts or text to this Working Group proposal:

• Corey Floyd
• Subbu Sastry
• Tim Starling
• Cindy Cicalese
• Sam Smith
• Marko Obrovac
• Nuria Ruiz
• Faidon Liambotis

FAQ

What is the relationship between the ATWG and the TechCom?

The TechCom is the forum where we come together as a technical community to discuss and decide the issues that affect the technology foundations of the movement. The scope of the committee includes all the official software that serves Wikimedia users. It has standing on questions around architecture, performance, security, database schemas, automated tests, and other technical matters. TechCom works closely with teams within the foundation to ensure alignment between the architectural vision and product development. Any technical decision in these areas should be brought to the committee if it is strategic, cross-cutting, or hard to undo.

The Working Group on the other hand is a working forum where collaborative work gets done on identifying matters that may or may not rise to the level of strategic, cross-cutting or hard to undo. Where matters are indeed within the purview of the TechCom, the role of the Working Group is to identify them, bring together the people that are needed to frame them and solve them, and initiate the TechCom discussion and review process. In these matters, the Working Group will engage with the TechCom as early as possible to ensure proper review and broad consensus before expending resources in building a solution.

Why not solve problems individually with Technical RfCs?

While this is certainly possible, we believe this has several pitfalls:

1. Without prioritizing a list of problems, we will divide our attention among competing issues instead of focusing on the most important things first.
2. Without a clear set of goals for our infrastructure, we leave ourselves open to the same issue we have now, which is not having clear criteria for which to judge technical solutions. 
3. Without first having a discussion around all of our issues we have the possibility of creating solutions in isolation further fragmenting our infrastructure by implementing solutions which don’t solve the needs of all stakeholders.

What about Community Needs and Participation?

This Work Group is squarely focused on the Audience and Technology departments and so will not include community members directly. However, community needs are a large part of the conversation and work group participants are expected to represent the needs of contributors, editors, readers, 3rd party MediaWiki users, etc. Information about a related project focused on identifying non-WMF audiences for Technology team products and identifying opportunities to support those audiences better can be found on the research page on Meta.