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

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

= Questions to answer during this session =

= Attendees list =


 * Effectively everyone.

= Structured notes = There are five sections to the notes:


 * 1) Questions and answers: Answers the questions of the session
 * 2) Features and goals: What we should do based on the answers to the questions of this session
 * 3) Important decisions to make: Decisions which block progress in this area
 * 4) Action items: Next actions to take from this session
 * 5) 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)

= Important decisions to make =

= Action items =

= New Questions =

= Detailed notes = SCRIBE INSTRUCTIONS: Session sections:


 * 1) 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.
 * 2) 3 breakout groups - we will mostly be transcribing discussion, and making important points in bold.
 * 3) Break - take photos of posters
 * 4) Single discussion - transcribing discussion.
 * 5) 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 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


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

Group 3
Roles


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

Gaps, uncertainties, Blockers


 * 1) Reconciling needs of wikimedia and non-wikimedia Wikis
 * 2) Relates to: WMF Engineer, PM, TechCom, 3rd party
 * 3) Hard to understand and negotiate with will of the community
 * 4) Relates to: WMF Engineer, PM, modeller
 * 5) Wikis are not approachable for new users due to UI/UX and the cultural change of sharing and collaborating by default
 * 6) Relates to: PM, 3rd party
 * 7) Unwillingness to make tough decisions (management)
 * 8) Relates to: WMF Engineer, PM, SRE, TechCom, modeller
 * 9) Complexities: many voices, many goals
 * 10) Relates to: WMF Engineer, PM, TechCom, Strategy WG,
 * 11) Dismissive Communication within community/Multiple disorganized communication channels
 * 12) Relates to: WMF engineer, Strategy WG, PM, modeller
 * 13) Resourcing too inflexible
 * 14) Quarterly (illegible) of scheduling anything
 * 15) 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


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

Gaps, Uncertainties, Blockers


 * 1) OOJSUI - Docs not useful
 * 2) Relates to: WMF, 3rd Party
 * 3) How-to docs, especially MW internals
 * 4) Relates to: WMF, 3rd Party, WMDE
 * 5) Changes introduced by new stable versions
 * 6) Relates to: 3rd Party, WMDE
 * 7) Tutorials for how to use APIs
 * 8) Relates to: 3rd Party, WMDE, WMF, Sage?
 * 9) Focus on tech over outcomes
 * 10) Relates to: WMF
 * 11) Security review
 * 12) Relates to: WMDE, WMF, 3rd Party
 * 13) New service deployment (timeline)
 * 14) Relates to: WMDE, WMF
 * 15) Staging is not like prod
 * 16) Relates to: WMDE, WMF, WMF Prod
 * 17) Budget cycle
 * 18) CI / QA bottlenecks
 * 19) Relates to: 3rd Party, WMDE, WMF, WMF Prod
 * 20) Service bureau vs. self-serve
 * 21) Relates to: WMDE
 * 22) Code review
 * 23) Relates to: 3rd Party, SRE, WMF Prod
 * 24) WMF plans and timelines are not reliable to plan against
 * 25) Relates to: Toolbuilder
 * 26) Staff turnover makes long-term collaboration and coordination hard
 * 27) Relates to: Toolbuilder
 * 28) Gaps in common / shared knowledge silos
 * 29) Relates to: WMF Prod
 * 30) Building consensus
 * 31) Inter dependent timelines
 * 32) Relates to: Toolbuilder, WMF, SRE
 * 33) Uncertainty - What os core platform? What is it not?
 * 34) Relates to: WMF, Design
 * 35) Poor release tagging
 * 36) Relates to: 3rd Party
 * 37) Design support for core platform
 * 38) Not cross functional at team level
 * 39) Relates to: WMF, WMF Prod, WMDE
 * 40) Time needed to deploy
 * 41) Relates to: WMDE, WMF
 * 42) Capacity planning
 * 43) Relates to: SRE, WMF
 * 44) Age of tech stack (Frontend and backend)
 * 45) Relates to: Everyone
 * 46) Gerrit
 * 47) Relates to: Everyone
 * 48) Late to learn of project intersecting horizontal skill
 * 49) Relates to: WMF, WMDE
 * 50) Design support from code platform

Group 7
Roles


 * 1) Product Manager
 * 2) Empowering people to share knowledge
 * 3) Volunteer Dev
 * 4) Be engaged in an open source project -> MediaWiki
 * 5) Important that the software is used
 * 6) Product Manager
 * 7) Better and more multimedia in our projects
 * 8) Product Manager
 * 9) Bring the community to be actualized, be productive, be inclusive to new comers
 * 10) TechCom
 * 11) Making architecture decisions so that the platform is more sustainable
 * 12) Engineer
 * 13) Creating great software
 * 14) See contributor community grow

Gaps, Uncertainties, Blockers


 * 1) Time
 * 2) To give other people what they need
 * 3) Code Review
 * 4) Getting it is hard
 * 5) Cross team needs
 * 6) Volunteer devs especially
 * 7) Consensus
 * 8) Both community and internal
 * 9) Influence requires certain positions in the Org
 * 10) Silos
 * 11) product|volunteers|Technology|WMDE
 * 12) Many communications channels
 * 13) Planning vs Flexibility
 * 14) Understaffing!!!! OMG
 * 15) Service work time
 * 16) Techcom members work is quasi-volunteer time
 * 17) Why? (explanations)
 * 18) 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?
 * 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
 * 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?
 * There have been multiple previous attempts
 * 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
 * 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?
 * Gendermag
 * 3 different path styles / contributor motivations: [?]
 * Abstractly want to help the movement
 * Want to fix something specific
 * 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?
 * 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)