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

Why not TechCom?
When discussing how to move forward with our discussions, one of the first things we discussed was using TechCom as a forum. After some conversation we came to the conclusion that while TechCom meetings are well suited for technical discussions and vetting technical solutions, other considerations made it not a good fit for this topic:
 * TechCom meetings aren’t generally a forum to discus product goals and user value which affect infrastructure requirements
 * TechCom doesn’t have representation of key Audiences staff (Engineers, Product managers, Designers)
 * TechCom is now an official arm of the CTO and by extension, the Technology Department - this makes it less ideal as a forum for discussing Audience needs

It’s particularly important to note that we see TechCom as integral to the process of figuring out solutions to our technical issues. Prior to developing thee solutions, we would like to first get a high level agreement on problems.

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…