Session Setup

Theme: Working together, decision making and responsibilities Type: Facilitation Exercise(s):

Leader(s): Birgit, Greg Facilitator: Deb Scribe: We need all 3!

Description: At this session we will look into intersections and requirements between different stakeholders and discuss processes, responsibilities and roles. It’s going to be interactive, challenging and fun :-). We want to develop a: joint understanding about requirements, intersections, dependencies and gaps between teams, orgs, individual contributors joint understanding about roles and responsibilities in the product development process, both in different scenarios and for different stakeholder groups joint understanding about best practices for collaboration, feedback iterations and decision making

Facilitator Instructions: https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2018/Session_Guide#Session_Guidance_for_facilitators

Questions to answer during this session

Question	Significance: Why is this question important? What is blocked by it remaining unanswered?
Who owns the decisions in the development process and at what points?
What does effective collaboration look like between individual contributors, teams, departments, and organizations? Who owns which parts of the processes? What feedback loops need to be established?
Where should the TechCom process fit into the engineering and product planning processes?

Attendees list

Effectively everyone.

Structured notes

There are five sections to the notes:

Questions and answers: Answers the questions of the session
Features and goals: What we should do based on the answers to the questions of this session
Important decisions to make: Decisions which block progress in this area
Action items: Next actions to take from this session
New questions: New questions revealed during this session

Questions and answers

Please write in your original questions. If you came up with additional important questions that you answered, please also write them in. (Do not include “new” questions that you did not answer, instead add them to the new questions section)

Q: Who owns features, UIs, code and processes? What process determines code ownership and establishing operational responsibility? Who owns the decisions in the development process and at what points?
A (If you were unable to answer the question, why not?):

Q: How do platform teams serve and schedule the features to serve multiple use cases, organizations and products?
A (If you were unable to answer the question, why not?):

Q: What does effective collaboration look like between Audiences and Technology? What about product and engineering? Research and Product? What about WMF/WMDE? Who owns which parts of the processes? What feedback loops need to be established?
A (If you were unable to answer the question, why not?):

Q: Where should the TechCom process fit into the engineering and product planning processes?
A (If you were unable to answer the question, why not?):

Important decisions to make

What are the most important decisions that need to be made regarding this topic?
1.
Why is this important?	What is it blocking?	Who is responsible?
2.
Why is this important?	What is it blocking?	Who is responsible?
3.
Why is this important?	What is it blocking?	Who is responsible?

Action items

What action items should be taken next for this topic? For any unanswered questions, be sure to include an action item to move the process forward.
1.
Why is this important?	What is it blocking?	Who is responsible?
2.
Why is this important?	What is it blocking?	Who is responsible?
3.
Why is this important?	What is it blocking?	Who is responsible?

New Questions

What new questions did you uncover while discussing this topic?
1.
Why is this important?	What is it blocking?	Who is responsible?
2.
Why is this important?	What is it blocking?	Who is responsible?
3.
Why is this important?	What is it blocking?	Who is responsible?

Detailed notes

SCRIBE INSTRUCTIONS: Session sections:

8 breakout groups - No major notes needed. We will all (6 of us) wander between the groups, to make sure people are writing things down on post-its and staying on-track.
3 breakout groups - we will mostly be transcribing discussion, and making important points in bold.
1. Break - take photos of posters
Single discussion - transcribing discussion.
1. Lunch - take photos of posters

Notes from initial slide presentation
- “Why We Need This Session” → not learning from mistakes can be dangerous
- Short video (link)
- We want to develop a:

- - joint understanding about requirements, intersections, dependencies and gaps between teams, orgs, individual contributors

- - joint understanding about roles and responsibilities in the product development process, both in different scenarios and for different stakeholder groups
  - joint understanding about best practices for collaboration, feedback iterations and decision making

- Important questions for the process:
  - Who owns the decisions in the development process and at what points?
  - What does effective collaboration look like between individual contributors, teams, departments, and organizations? Who owns which parts of the processes? What feedback loops need to be established?
  - Where should the TechCom process fit into the engineering and product planning processes?
- Explanation of session format
  - Part I: Roles & Gaps, split into 8 groups of 6 people
    - What is your role and what is your motivations?
    - What gaps, unclarities, and blockers hinder productive collaboration for you?
Notes (if needed) from initial breakouts. [We will take photos during the break, once the posters are on the walls]. Summaries from groups are on post-its of posters which will be photographed - highlights are below
- Timezones and volunteer vs paid staff working times
- Not enough time to complete projects
- long-term maintenance
- Who to contact to get decisions made
- Not able to affect annual planning unless you’re a manager
- Workflow issues
- Bug Report Responses (esp from outside the foundation)
- Trust, communication, ownership
- Unclear Communication channels (too many, and hard to find, and often silent)
- Change aversion
- Too many communication channels
- Hostile communication,
- lack of support for new projects
- Unclear responsibility,
- Uncertain what people are working on
- Code review (mentioned by several groups)

Digitalising outcome of the 7 working groups:

Group 1

Role/Motivation/Goal	Gaps, Unclarities, Blockers (not clearly related to the roles, best guess)
R: SRE/Traffic G: Fight censorship G: Global Performance Equity Ensure Users’ privacy	SRE: Blockers: Complexity of MW -> Edge integration
R: PM M: Ensure to help retain new contributors as an active part of our communities R: Director PM M: help product teams to make good decisions about what to work on, and how to work on it
R: Volunteer Dev M/G: Give other volunteers the tools to do their work more efficiently R: Geek M: Play with interesting tech and solve interesting problems to benefit the community (maybe)	Not sure what IRC channel to use, people don’t respond
R: a.) 3rd party community organiser, b.) 3rd party sys admin, c.) 3rd party software documentator M: a.) understand better to interact with wmf b.) understand better who to interact with c.) understand better what to do to support better outcome	How to find who to work with on support, deployment, etc.? Even if you find someone, do they have time? Code security reviews. Hard to find both internal and external. Where to go for questions? Phab - bugs only! IRC - unreliable availability of support Sysadmin needs for some VMs and wiki tools are too complex. Simplify administration. Ex: PHP on tool forge Best practices and libs for tools: Ilgn - yi access etc
R: TechCom, Use my 15 years of experience to advise others working on changes to the system. M: Help others to do the work I don’t have time to myself. Force multiplier! R: Architect, Look at how the software fits together and improve it M: Make the software work better for its purpose R: Video person Maintain and add features to media tools not getting other support M: Browser media is fun and useful! Make it work!
R: Tool/gadget volunteer js/css developer Motivation: address needs of a local wiki	Unclarity/complexity: Not sure who to contact for help when I want to import/localize a tool; generally: Too many communication channels and no clear contacts for questions on gadgets etc.

Group 2

Roles

PM Product Manager

- increase the reach of MediaWiki for collaborative knowledge sharing

CP Engineer at core platform team

- working on the platform used by others

- my success comes from other developers viability to use the platform and achieve their goal

RE Director of SRE

- coordination about ( eventual ) production deployment at the right time

- input on (SRE-related) architectures

- long-term maintenance

EM Engineering Management

- growing content on projects

- growing communities

- building sustainable contemporary experiences

SE Software Engineer

- superot OSS developers

- support collaborative development

- make the software flourish

- support the users behind and in front of the software

VD Volunteer Developer

- help the community especially with areas WMF cannot

- fun altruism

Gaps, Uncertainties, Blockers

Silos - EM
Lack of shared understanding
Long Term maintenance - PM CP RE
3rd party only vs must include projects vs must include 3rd party - PM EM
Lack of shared vision - CP
(lack of?) balance between focus and collaboration - CP SE
Unclear code ownership / stewardship - SE E PM
Difference in pace - SE
Gap: volunteer patch SLAs - VD
Opposite work times ( weekend, evening, work days, mornings, timezones ) - RE VD
We do not have a good shared understanding of what is a success - SE
Huge amount of time to get my development back in sync - VD
Planning timelines - EM
Architectural input / coherence - CP RE
Which team / silo do I need - SE
Planing inclusivity
No dedicated planning “sprints”
Too many comm channels
Trust decision rights w/ product managers
Road mapping & priority tools - PM VD RE
Capture information about what and why we NOT do things (now)

Group 3

Roles

Mgr/Engineer - WMF
1. Role: engineer, manage a team and a project
2. Motivation: Improve mediawiki, address tech challenges for wikimedia projects (wikitext/page content, specifically)
PM
1. Role: PM
  1. Channel voice of the user
  2. Definite and prioritize software changes
  3. Ultimately responsible for impact
2. Motivation: Maximize learning on wikimedia projectsl particularly among people wilthout other options
SRE
1. Role: SRE
  1. Increse reliability of our infrastructure
  2. Allow erasier and faster dep[loyment of code and services
  3. Make sure we have a good architeecture
  4. Provide feedback/copunsel/advice to teams
TechCom
1. Role: TechCom chair; Core Platform architect; wikidata community
2. Motivation: I want to make MediaWiki easier to use, modify and extend by engineers
.
1. Advisor at Strategy WG
2. Recommendation which will bring a better movement
1. Role: Data modeller and gatekeeper curator
2. Motivation:
  1. Breaking down data silos
  2. Focus on content
  3. knowledge/data modelling
Software Engineer
1. Discoverability of content
2. Supporting a wide variety of languaghes
3. Uptime
3rd party/volunteer
1. Role: 3rd party/volunteer
2. Motivation: To improve the MediaWiki platform for use cases outside of WMF use
3. Goal: For the MW platform to crush and destroy Sharepoint and become the defacto knowledge management tool

Gaps, uncertainties, Blockers

Reconciling needs of wikimedia and non-wikimedia Wikis
1. Relates to: WMF Engineer, PM, TechCom, 3rd party
Hard to understand and negotiate with will of the community
1. Relates to: WMF Engineer, PM, modeller
Wikis are not approachable for new users due to UI/UX and the cultural change of sharing and collaborating by default
1. Relates to: PM, 3rd party
Unwillingness to make tough decisions (management)
1. Relates to: WMF Engineer, PM, SRE, TechCom, modeller
Complexities: many voices, many goals
1. Relates to: WMF Engineer, PM, TechCom, Strategy WG,
Dismissive Communication within community/Multiple disorganized communication channels
1. Relates to: WMF engineer, Strategy WG, PM, modeller
Resourcing too inflexible
Quarterly (illegible) of scheduling anything
1. Relates to: WMF Engineer, SRE, PM, Search

Group 4

Roles

Engineering Director, Core Platform

Help define the core platform and make it easier for everyone to use

Volunteer

Extensions/gadgets/bots
Integrate Wikidata and Wikipedia
Contribute to Wikidata
RTL issues

TechCom and Performance

Establish guidelines and principles for architecture and performance.
Make the platform easy to work with as a developer and feel fast to use.

Apps

Furthering the mission
Cracking editing on mobile
Being able to be more experimental in the features we deliver
Rapid prototyping

Product Manager, Readers Web Team

Motivation: Bringing new people with new perspectives into the movement.

3rd party user of MW

Learn about future of platform
Influence its direction?
Identify pain points/ease them

Director of Security

My role is to build and develop the security org.
My motivation is to build a bridge between security and the org.

Gaps, Uncertainties, Blockers

We can’t find the right channels to communicate to [community, teams, 3rd parties, organizations]
Communication
Working with volunteers individually is not scalable
Phab seems to be more effective than mail lists
Lack of cohesion in direction
Fragmented communication channels. Phab, IRC, Discourse, mailing list.
Who should respond to questions?
People want to see different kinds of changes.
We don't know who owns what
Responsibility, roles, ownership
Volunteers don't know who is responsible for what
Accountability is unclear from a volunteer perspective
The experience is different based on the tech stack or UI
For third parties, it's hard to know:
- which services are necessary
- who to ask for help
- what channels to use (phab, mailing list, talk pages)
Complexity of software is bad for third party users
Restbase is confusing
Hard to find responsible people (mailing lists? discourse? phab?)
Internally productivity is blocked because of complexity and that impacts on the community
Finding channels to the community is difficult
Complexity
Different stacks make skills and relationships non-transferable
There is not a clear overview of how our sites work for real users -- encompassing also the gadgets and tools
It's hard to understand how things work together
Lack of consistency in both tech and UI causes confusion and duplication of work
Change
New is scary
Internal to the WMF we feel resistance to certain kinds of changes
Unclear ownership of components and when to involve other teams internally
It's not clear who is responsible for what feature (esp. for volunteers)
Ownership and responsibility is unclear internally as well
Complexity and accountability are worrisome
The complexity is limiting
Responsibility is unknown

Group 5

Roles

Engineering Manager, WMF Tech team

Solve big problems -- technology (sometimes), organizational (always)
Equity of access -- breadth of views

Engineering Manager, WMDE / Wikidata

Taking care of engineering processes, allowing engineering to achieve product goals
Motivation: Have clear responsbilities between WMDE/WMF to achieve our goals and fulfill the mission

Role: TechCom / Architect / Engineer / Tech Lead

Motivation: software design, product conception
More broadly: Knowledge dissemination, Wikipedia

Engineering Manager, Audiences

Represent upcoming/ongoing engineering efforts. Outreach and discovery, ideally. Shrink impedence mismatch between audience and tech.

Volunteer, Tools / gadgets / bots / extensions

Help contributors to be more efficient
Make Wikipedia & co. grow
Share free knowledge

Product Manager - Apps and strategy

Understand and speak for users (existing and potential)
Craft compromises and take responsibility
Advocate for strategic objectives, focus
Motivation:
- Wikimedia needs to evolve to survive. I think I can help
- My team
- My users

Gaps, Uncertainties, Blockers

Self assigned scope
Lack of documentation for newcomers (or a lack of a way to find the existing documentation)
Unrealistic ownership expectations
More products than people
Who does what? Who owns what?
Opacity of the organization
Getting code reviews
Trust
Settling genuine disagreements
Integration between product conception/development and architecture, feasibility
Mismatch between distributed team and centralized product process and technology stack

Group 6

Roles

SRE / OPS
1. Security
2. Stability
3. Performance
4. Empower content projects
3rd Party
1. Guide the future of the Hydra-Wiki Platform
2. Monitor performance and and server errors to preemptively prevent outakes
Design
1. Making sure product teams have enough design and research support
2. Cultivate culture of design and lead by research
3. Design products for readers and contributors
4. Motivation: To unfuck 15 years of undesigned products / make someone ffel good about using our software
Toolbuilder
1. Build tools for helping new editors and for program organizers that work with new editors
  1. Oauth editing
  2. Analytics
  3. Workflows
2. Motivation: To save wikipedia by getting the next generation of contributors
SE Language
1. Build technology to help people to contribute and consume knowledge in all languages
WikiData / WMDE
1. Structured data
2. Wikibase reuse / ecosystem
3. Stability, security, scalability
4. Guide Wikidata development and architecture
5. WMF integration with infrastructure
Engineering manager audiences WMF (product) - WMF Prod
1. Enable and empower product teams on their goals with technology that they can successfully fulfill Wikimedia’s mission

Gaps, Uncertainties, Blockers

OOJSUI - Docs not useful
1. Relates to: WMF, 3rd Party
How-to docs, especially MW internals
1. Relates to: WMF, 3rd Party, WMDE
Changes introduced by new stable versions
1. Relates to: 3rd Party, WMDE
Tutorials for how to use APIs
1. Relates to: 3rd Party, WMDE, WMF, Sage?
Focus on tech over outcomes
1. Relates to: WMF
Security review
1. Relates to: WMDE, WMF, 3rd Party
New service deployment (timeline)
1. Relates to: WMDE, WMF
Staging is not like prod
1. Relates to: WMDE, WMF, WMF Prod
Budget cycle
CI / QA bottlenecks
1. Relates to: 3rd Party, WMDE, WMF, WMF Prod
Service bureau vs. self-serve
1. Relates to: WMDE
Code review
1. Relates to: 3rd Party, SRE, WMF Prod
WMF plans and timelines are not reliable to plan against
1. Relates to: Toolbuilder
Staff turnover makes long-term collaboration and coordination hard
1. Relates to: Toolbuilder
Gaps in common / shared knowledge silos
1. Relates to: WMF Prod
Building consensus
Inter dependent timelines
1. Relates to: Toolbuilder, WMF, SRE
Uncertainty - What os core platform? What is it not?
1. Relates to: WMF, Design
Poor release tagging
1. Relates to: 3rd Party
Design support for core platform
Not cross functional at team level
1. Relates to: WMF, WMF Prod, WMDE
Time needed to deploy
1. Relates to: WMDE, WMF
Capacity planning
1. Relates to: SRE, WMF
Age of tech stack (Frontend and backend)
1. Relates to: Everyone
Gerrit
1. Relates to: Everyone
Late to learn of project intersecting horizontal skill
1. Relates to: WMF, WMDE
Design support from code platform

Group 7

Roles

Product Manager
1. Empowering people to share knowledge
Volunteer Dev
1. Be engaged in an open source project -> MediaWiki
2. Important that the software is used
Product Manager
1. Better and more multimedia in our projects
Product Manager
1. Bring the community to be actualized, be productive, be inclusive to new comers
TechCom
1. Making architecture decisions so that the platform is more sustainable
Engineer
1. Creating great software
2. See contributor community grow

Gaps, Uncertainties, Blockers

Time
1. To give other people what they need
Code Review
1. Getting it is hard
2. Cross team needs
3. Volunteer devs especially
Consensus
1. Both community and internal
Influence requires certain positions in the Org
Silos
1. product|volunteers|Technology|WMDE
Many communications channels
Planning vs Flexibility
Understaffing!!!! OMG
Service work time
1. Techcom members work is quasi-volunteer time
Why? (explanations)
1. Turn into disagreements

Part II: Defining effective collaboration processes

- 3 groups with 3 different focuses

- - Wikimedia - WMF & WMDE product development
  - Wikimedia - Volunteer driven projects
  - Projects for/by 3rd party users
- Instructions for Groups:
  - List all steps in ideal process, Who should be involved at each step. -
  - When you think "here's the good connection between groups" mark it with a heart.
  - Broken lines: breakdown / problems
  - Question mark: open questions
  - Then identifying what already exists, what can be moved to be in this ideal process, etc
Notes from breakout groups:
- Nick (volunteer driven)
  - Attendees: TheDJ, Florian, Nirzar, Ramsey, Ian, Mark B, Fisch, Zach, Cheol, Tim, Kate, Gergo, Marko, Adam, Santosh
  - Think about an idea, if you were to contribute, what are the various ideal paths. How to get to idea, how to get guidance, how to communicate, get code review, make docs, who makes decisions, who are stakeholders. And highlight break points.
  - Adam & TheDJ: Need dedicated personnel to review volunteer contributions. Or at least determining who to pull in, and next steps. "Like Andre but for gerrit".
  - Alice has a feature she wants to implement, or a bug she wants to fix, or is a newcomer and wants to have an #easy task.
  - What are Alice's motivations? Different support types for different motivations. "I want to help Wikimedia" vs "I want to fix this bug". Do we need different documentation for different personas?
  - Research - Alice researches to get understanding of audience she is building for.
  - Cheol: Some ideas need more support than others.
  - TheDJ: Need to triage ideas so that 'bad' ideas don't get as much effort invested before we give negative feedback. E.g. much before code-review stage.
  - Adam: WMF has processes for triaging ideas, perhaps we should use some of those?
  - Marko: even bad ideas shouldn't be shot down too soon, as that can be demotivating.
  - Tim: 1st step is idea, 2nd step is talk to people and get feedback started. "Socialize and validate".
  - Q. What communication channels should they use?
  - WMF could organize note-taking and similar, but volunteer committee to validate ideas,
  - Nirzar: Capacity building in the community for these roles and skills
    - Difficulty with volunteer burnout, and simple lack of numbers
  - Q. how to validate it's a good idea?
  - 4th step: collaborators. Finding people to help implement and iterate on
    - Q. what is the process/channel for finding them?
  - How to get access, whether to contribute to existing work or start your own project
  - Design consultation
  - Ideally one portal - perhaps iterate on https://www.mediawiki.org/wiki/New_Developers ?
  - There needs to be expert support. PMs and Devs and Editors and Design
  - Code review
  - Consultation to validate that something met its goals?
  - Q. How much consultation is too much?
  - It shouldn't be a 'gate', just a reliable way to get feedback or support
  - Something feels wrong - too much centralization? Too many gates?
  - Do we push people towards gadgets?
  - Difficulty with implementing all ideas is long-term technical maintenance burden (often passed along to WMF)
  - All pathways are optional, we're just trying to provide assistance when it's needed and/or wanted.
  - Regular question on Wikipedia Village pumps "I want this feature, who can help me with it?"
  - Goal: Don't let people waste their time
  - Goal: Don't block people on implementing their ideas,
  - If something is going into an extension, it needs quality, and tests, and i18n, etc. https://www.mediawiki.org/wiki/Best_practices_for_extensions
  - Penultimate: Deployment.
    - Beta deployment
  - Final: Maintenance.
  - [final final: sunsetting]
  - Q. How firm to be about coding styles?
  - Q. how to find subject matter experts, e.g. DBAs.
    - Distilled:
    - Beginning: Volunteer has Idea
    - We could have a dedicated location for them to (optionally) get feedback on their idea, before they invest too much effort
    - They should do research, understanding audience and refining goals
    - Get feedback on idea.
    - Find collaborators and peers.
    - Need product managers to be available to give feedback, or point towards existing products.
    - Implementation!
    - Important to have experts available. E.g. DBAs, UI designers,
- Michael (3rd party)
  - Attendees: Brion, Karsten, Daniel, Lydia, Sam, Olga, John B., Dmitry, Alex, Sage, Eran, Daren, Cindy, Brandon, Raz, Magnus
  - Q: What is a third party installation?
  - Whose responsibility is it to build it?
  - Different users have different needs. Some just want the source, some want a docker image
  - Question of process -- who does it?
  - Daren: Third party users should be part of that process
  - How do we keep people in the loop so their concerns are heard?
  - Cindy: Currently we deliver a tarball, not ideal
  - Most third party installs use something else like a script or ansible playbook
  - Alex (Gamepedia) actually uses the tarball
  - Brandon: (Q about versioning of releases)
  - Cindy: Sounds like the distro method depends on who’s consuming it
  - We’re not going to define the distro method, just define a process of how to decide it
  - Alex: discussing Gitlab distribution: variety of methods
  - We’re not trying to solve the tech problem here, we’re trying to solve the process problem
  - Process:
    - Starts with someone having an idea of what they want
    - John: Is there a decision point when someone looks at that and provides feedback?
    - What’s the first step when someone looks at our offerings and decides they don’t meet their needs?
      1. Phab?
    - Daniel: Whoever does the defining needs to assess the needs
    - Someone needs to ID themselves as the owner of a release
    - Raz: Maybe we should start with identifying problems, not necessarily solutions
      1. Magnus: We can also sometimes map problems to existing solutions
    - Brandon: In a commercial offering there is a support layer that handles this situation
    - Sam: On Reading Web we refer to this as “triage and analysis”
    - Bryan: From a MW Core perspective I’d point to the MW Help Desk. But that channel is generally missing feedback to the software developers. More of a end-user to end-user support group.
    - Cindy: Right now, we have a release cycle of 6 mos without any particular planning around features, just cut the branch and whatever makes it in makes it in. Other environments often have a theme.
    - There is no one to prioritize
    - Bryan: Current model is more like a Debian distribution than a feature product. Release is primarily timeline-driven. That’s worth considering changing.
    - BB: Even from the SRE perspective, better third-party support would help SRE
    - Daniel: Releases and bundles to install need not correspond exactly
    - Daren: Don’t assume it’s only Core that third party users are interested in, it’s all the extensions. Can be a big challenge during upgrades to keep everything happy
    - BB: I assume there’s also the matter of integration of the various pieces (Apache, db, mw)
    - Daren: Yes, we have a script for all of this. Would be great to have it more repeatable and predictable.
    - Cindy: There is no sane way of upgrading currently. Basically installing a completely new thing and then updating the DB.
    - We are talking about shipping a product here, not writing software
    - Sage: As a small wiki admin, something like a WordPress distribution/upgrade method would be welcome, currently it’s almost not worth upgrading at all
    - Daren: So that testing block could include testing different sets of extensions
    - BB: Do we have a signaling mechanism for “well supported” vs not well supported extensions?
      1. There have been multiple previous attempts
      2. There is also the “production deployed” template on mw.org
    - Cindy: There is little overlap between the extensions I had installed in my prev life, and the once installed in wikimedia production. ~10.
    - BB: An extension needs to have some kind of integration testing in order for an extension to get the “seal of approval”
    - Cindy: We could decide on different “types” of bundles (i.e., “flavors”: Wikimedia, etc.)
    - Alex: We go straight for the language extension bundle since we know all of those will work together
    - Bryan: I often hear from external parties that they look to WMF to be the solver of problems rather than feel they are part of a community that solves problems together. My view is that without community support we won’t be able to sustain things.
    - Cindy: Someone (NASA/NISA) is starting to do that
      1. Daren: But we’d be happy if WMF took care of it!
    - But there should be some organization around it, it’s not going to happen out there by itself
    - Cindy: The other reason it needs to be collaborative is that we don’t have a lot of insight into external users’ problems
    - Daren: Looks like it needs to be easier to spin up new wikis
    - We need an internal and external stakeholder org that meets regularly that discusses and makes decisions about releases
    - Bryan: In the Kubernetes community this is a standing weekly conference call
    - (See docs on mw.org about forming a SIG)
- Irene (wmf/wmde) → images of poster can be found at bit.ly/2OGaoPH
  - Attendees: Danny Horn, Addshore, Derk-Jan, Josh Minor, Jon Katz, Andra Waagmester, Antoine Lamielle, Subbu, Krinkle, Leszek, Corey, Joaqium, Halfak, Erik B +1 others
  - Where to start: movement strategy or context, vision/mission/strategy/annual-planning?
  - No, let's start with some user feedback, or? Defining a concept
  - Research is an important step after the concept but also before
  - Budgeting doesn’t happen on the feature level (J) - Leszek reminding that we’re trying to build ideal process
  - Budgeting and community discussion will have lots of loops and re-enter the process
  - Checklist at the product stage (stakeholders, legal, security)
  - Define success metrics early on, before proof of concept
  - (scribe note: this group is not really moving along the “idealized” path but is instead discussing current issues and how to move around them)
  - Concerns: does the system handle capacity, does one serve username? They are different in terms of how variable they are, as traffic will change overtime
  - There are two security reviews - whether or not they are involved, assessing security implications, and then later towards the end there are security testings
  - “Search for Gravestones” would be a really useful step, but it currently relies on personal/institutional knowledge
  - (scribe note: this group has no women in it beyond the scribe and the facilitator)
  - Where does define metrics go?
  - There’s a fallacy that “concept” is the start of the process but a lot goes into the before step for that - Not everyone can go first, so the “start” is pretty nebulous and different ideas can come from many places (research, user idea, product vision, etc)
  - How do we break out of the concept “cycle” and move into being developed? What is the “go” moment? Who owns that yes/no decision?
    - Currently its c-levels “dark room,” although if its a smaller project it will be department level. The team that is the implementing group should be the owner of the yes/no moment.
  - Things get front-loaded and that means that it waterfalls and we are expected to know everything up front. Some things have to happen as we learn it. The ideal process needs to be more agile as we move along than it currently is.
  - Don’t stop talking to each other as the process moves along; you don’t have to finish the discussions in the early stages
  - Ideas -> verification -> implementation
  - Should product or technology decide [lost rest of Krinkle’s point]
  - Who owns each of these “cycles”
  - The prototype teaches us if this is feasible - the whole team but especially the product managers say yes/no of when you move out of proof of concept/prototype and into wholesale development
  - Is there a difference between v1 production and maintenance production, since maintenance becomes mandatory for many projects immediately?
  - The depressing reality of sunsetting
  - Overall, we tending to get stuck in loops that are important but that can go on over-long, and it isn’t clear who makes the decision to move us out of each of these loops
  - The forgotten issue of maintenance - question of maintenance responsibility AND who decides when it’s time to shutter the maintenance (egos can get in the way)
  - Overall ideal process: Idea → Validation → Beta → Production (including testing) → Implementation → Maintenance → Sunsetting
  - Some issue of leadership helicoptering but that has died down
  - Still the major unresolved question - who owns the decision to move from each stage to the next?
  - Distilled presentation to conference:
    - Lots of circles and feedback/fwd loops
    - Starting with strategy, there’s developing the idea step, which gets discussed and pitched. “At some point” the idea is validated, still an unidentified step.
    - Then another cycle of validation to build proof of concept and take in more input. Moving is still an unowned step.
    - Implementation then production and deployment.
    - Maintenance is a very broken step
Takeaways from Posters
- Volunteer poster:
  - Identified Takeaways
    - How do we ensure volunteer time isn’t wasted?
    - No process to support volunteers in their contributions
    - "Socialize and validate" touch point early in the process ("good idea"/"bad idea" "this is how you could do it")
    - Code review team for volunteer contribs
  - Different cognitive styles and contribution styles that volunteers might bring, supporting the diversity of styles
    - How can we identify and prioritize this type of discussion?
      1. Gendermag
    - 3 different path styles / contributor motivations: [?]
      1. Abstractly want to help the movement
      2. Want to fix something specific
      3. Big idea
    - Optional middle parts that work for many types of things
    - TODO: Clearer definitions of the 3 styles.
    - There are a lot of tools to help contribs (hackathon, workshops, hangouts) so this is a helpful thing, some love for that
- WMDE/WMF Poster
  - Identified Takeaways:
    - How do we plan for maintenance once a product is in production
    - How do we figure out security + privacy implications
    - How to decide on impact metrics - perennial problem, measuring impact, not enough analysts, not enough instrumentation, event-logging schemas are complicated, time-consuming process - old feature usage and new feature usage, to determine impact
  - Additional Ideas
    - Come up with better ideas to get new proposals into the pipeline and communicate these ideas - overlap with volunteer developers and other communities as well, better sourcing ideas from everywhere
    - Documentation, user design, and proof of concept are all important
    - Several cycles where people collab, but unclear how to exit the cycle - e.g. is an idea validation exit "get your project approved by techcom"?
    - Unclear owners at each stage, very fuzzy. How do we formalize consensus towards a decision point.
    - [Daniel] Since techcom approval is a point of confusion, for relevant tech changes, techcom approval is necessary but not necessarily enough on its own, there is other approval to secure
- 3rd Party Poster
  - Identified Takeaways:
    - Choosing a release manager for 3rd party releases
    - Need to define bundles of extensions - having a "seal of approval"
    - Need to define update mechanism - e.g. like wordpress with 1-click update
    - Need to define delivery method - talking about containers vs tarball vs whatnot
    - Release got some love, yay
    - Governing body/SIG (Special Interest Group) which has regular meetings and diverse participation (external members) gets to be able to help make these decisions, move things forward, prevent them from being forgotten
  - Additional Ideas
    - Where does this diverse participation spring from?
      1. We have some formalized groups that provide venues (MW stakeholders, foundation, user-groups) BUT the main one is the mediawiki stakeholders, which doesn't inherently get other aspects of diversity (diversity VS Diversity, ie more focused on internal vs external rather than other elements of diversity [GS, gender, etc])
Dot voting! Link to photos of dot-voted posters →
- Each participant got 3 dots to divide as they saw fit between all three posters.
Notes from single discussion / wrap-up
Key Results (maybe drag them down from the detailed notes to here to make documentation easier?)

Dot Voting results

3rd Party

Currently not working well:

Choose a Release Manager for 3rd party releases (0)
Define bundles of extensions (1)
Define update mechanism (9)
Define delivery method (3)

Idea:

Governing body, SIG with regular meetings and diverse participation (16)

Wikimedia - WMF & WMDE product development

Open questions/currently not working well:

How do we plan for maintenance once a product is in production? (21)
How do we figure out security and privacy implications (2)
How to decide on impact metrics (8)
Decision, approval, Technical Committee (10)

Ideas:

Come up with better ideas to get new ideas into the pipeline and communicate these ideas (3)

Important/good that we have this:

Documentation, user design, proof of concept (9)

Wikimedia - Volunteer product development

Open question:

How do we ensure volunteer developer time is not wasted (12)

Currently not working:

No process to support volunteers in their contributions (2)

Ideas:

“Socialize and validate” touch point early in the process (“good idea/bad idea”, “this is how you can do that”) (8)
Dedicated code review team for volunteer contributions (17)
Cognitive styles/GenderMag (0)
Contribution styles (0)

Important/good that we have this:

Events/Hackathons (0)

Wikimedia Technical Conference/2018/Session notes/How do we work together

Contents

Session Setup

Questions to answer during this session

Attendees list

Structured notes

Questions and answers

Important decisions to make

Action items

New Questions

Detailed notes

Digitalising outcome of the 7 working groups:

Group 1

Group 2

Group 3

Group 4

Group 5

Group 6

Group 7

Dot Voting results

3rd Party

Wikimedia - WMF & WMDE product development

Wikimedia - Volunteer product development