Audiences Technology Working Group

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

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

This purpose of this working group is to develop a framework to enable the members of Audiences and Technology to work through our technical and process problems together.

Goals
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.
 * Problem Identification and Prioritization

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 and Forum for Solution Collaboration

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.

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.

Deliverables
The Working Group will address the three issues by developing a document comprised of three key components:
 * 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

Out of Scope
This group 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.

Participation
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 incorporate both in person and asynchronous opportunities for participation.

In addition to diverse participation, it is clear that the development of a cohesive document will require some individuals to take the lead at certain times. We will need volunteers to take ownership over parts of the process to keep progress moving forward.

Process
While the process is likely to change, it is helpful to have a rough outline to get started.

TBD

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.

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…