Audiences Technology Working Group

This draft is a distillation of the ideas and conversations from this etherpad

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 this was making it difficult to move discussions forward in a productive way.

Goal
This purpose of Audiences and Technology Working Group (ATWG) is to gather and organize information on these issues in a systematic way in order to facilitate collaboration, decision making, and solution development within the WMF.

Deliverables
The ATWG will develop three key documents in order to accomplish its goal: Further information on why these three deliverables were selected can be found below under the background section.
 * 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

Outcomes
After the ATWG completes its task, we hope for the following outcomes:
 * 1) TechCom will be able to use the prioritized list of issues in order to begin 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.

Out of Scope
The ATWG will not: While our ultimate goal is developing and implementing solutions for our infrastructure issues, this is outside the scope of this working group.
 * Develop or propose technical solutions
 * Vet or approve technical solutions

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 discus 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.

Joining
This interested in joining the workgroup can post a comment on the talk page or email Corey Floyd.

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.

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 what 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 leg work 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 to 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 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

What is the relationship between the Working Group 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  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 MW users, etc…