Wikimedia Technical Conference/2018/Session notes/Keynote on Platform Principles

https://phabricator.wikimedia.org/T206087 -

Rough Transcription: of Victoria’s session

Welcome remarks
Thanks to the program committee esp
Platform timeline, the growth from "Before Mobile", to simple "Mobile", to
Creation of and evolution of “visual editor”, noting the creation of a second parser
Creation of various Apps, adding additional complexity to mobile content service
Complacency, friction, lack of speed, from the complexity of it all
Efforts to fix these problems were initiated by engineering teams, creating a path to build the platform
Moving away from a JIT architecture, to a planned architecture, hence this conference.
Intention that every year this Techconf conference will address a new topic, whatever is the priority that year.
Hoping to come out of this conf with a roadmap
If we're moving away from emergent architectures, need to think about how we're going to do that
Definition of Goals and Principles
- Architecture principles
  - In service of the strategic direction: "To become the essential infrastructure for free knowledge"
    - Knowledge equity
    - Knowledge as a service
    - Key Question as we work: How do we support one or other or both
  - Sustainability - both adapt and support the growing needs - not going to split into divergent jumbles of architecture again
  - FLOSS - Key tenant of the movement, since the beginning, and will continue to be so in the future. When we build things that we depend on, esp with mixed workflows, FLOSS is the absolute requirement. Keep the architecture open to others.
  - Scalability - especially as we fold in the partners in the GS to scale up or down
  - Resilience - adequate and adaptive defense against attacks; also has to adapt to legislative evolution
  - Security - we are often the object of attacks, so this needs to be a key focus as we spread out even further and thus become more of a target
  - Privacy - watching out for design flaws that inherently “leak” data. E.g. determining how to implement GDPR, and similar potentially upcoming legislative frameworks.
- Constituencies:
  - Editors
  - Readers
  - Devs
  - Admins / Power Users
  - Community
  - Do not take actions that preclude either these groups OR groups getting added in the future
- Goals
  - Allow users to consume, create, and interact in a form suitable for their devices, with the connectivity they have, in a language they speak
    - This is especially important for language as we move forward into the GS
    - Currently only covering ~300 languages, out of the ~6000 languages spoken in the world
    - Any architecture changes cannot preclude this as we move fwd
  - Empower contributors to collaboratively forward and curate content and to build the tools that they need to do so
  - Provide APIS that allow 3rd party interfaces to efficiently interact with wiki content and Provide reusable data that can be processed in bulk by 3rd party tools
    - Actively design for sharing, not sharing as an afterthought
  - Provide an open-source software stack that can be easily used, modified, and extended by others
    - Empowering communities with these tools
    - Shoutout to Tech Engagement team who provide many of the tools for volunteers to do this work
  - Ensure programmer productivity by maintaining a code base that can be modified with confidence and understood without needless difficulty.
    - Working to remove the mysteries associated with working on our code.
    - Documentation! As the code evolves, the documentation has to change at the same time.
  - Provide a web application that can be freely used to collaboratively collect and share knowledge
    - People primarily still come to our sites on Desktop and Mobile Web, which is likely to continue.
  - Ensure the continued availability and performance of WMF projects through scalable and resilient system design
    - SRE and Performance teams, have been key in many recent improvements.
  - Ensure the data integrity of the content on WMF systems, and protect the privacy of our users.
    - Compared with Yahoo, even with their size and complexities, our challenges are astronomically more complicated
Tools for Change
- We now have unified teams, which helps greatly
- Platform Evolution CDP
  - Working collaboratively with all stakeholders. Cross-team, affiliates, community members, external - how do we reach them? Questions to consider
- Core Platform
- Developer Advocacy
- TechComm
  - Expansion and expertise, which is necessary given all the facets of these issues
- WM Technical Conference
This Conference
- Make it a gif
- Collaboration
  - “what is different about TechConf this year”
  - Working hand in hand with product teams to understand our users and use cases
  - Several examples of collaborative successes / key collabs for the future
- Focus on roadmap, outcomes and action
- Shoutout to program committee for the action-based and collab heavy program
Questions / Comments:
- Q from Toby: one of the things in product org that they are interested in is anti-censorship, making sure the platform is secure against tampering - can you talk about plans in this area
  - A: Victoria is going to Taipei to participate in the [Toronto?] group that pursues anti-censorship software. We all need safe and equitable access to the network. The changes in China and elsewhere are likely to spread elsewhere. Communities need protection. US Net-neutrality law was overturned by current administration and still of great concern to us. Things like encrypting DNS names, DNS over HTTPS, [?], [?], wants us to be present and thoughtful in bringing these ideas into our movement. More companies/orgs (Not only Google) should be experimenting and learning about these areas.
  - Need to not be so US centric in these things, just recommending VPNs is not an effective solution for countries where users face legal ramifications for VPN use
- Q from Daniel Kinzler: example of how tech folks engineers and all need to collab: showing IP addresses for logged-out editors - fixing that is a technological challenge, we need ways to block out misbehavior or spammers, and we would have to change processes that we use; anything that needs tight integration and collab from the tech side should be main focus of this conferences
  - A: Couldn't agree more. Definite pain-point when determining how to comply with GDPR. Things like this are currently built into the DNA of how the projects function, and require major interdisciplinary understanding to tackle.
- Q from Aaron: about general vision moving away from emergent jungle [jumble?], strategy focused and Aaron hear “top-down” in that: why focus on singular direction? what do we miss from the emergent pattern that we were using up until now?
  - A: [?] that allows us to deliver within the resources we have, not just headcount but time. Need to absorb innovation, but it's always hard to predict future changes. Architecture that admits instead of throwing out. Sustainability in particular adds challenges.
- Q from [?]: looking at WMF/ WMDE, it seems like we are supporting too many thing than we can maintain and properly create; do we have a plan to drop support for services, and if so, do we have a process for that?
  - A from Victoria: When I started I asked Greg how bad the tech debt was, and he produced a multipage document listing the code without owners.
  - Greg: The Code Health project, and code stewardship review process are ways for us to find and do something about things that we're not supporting well enough. Data-driven process, with as many stakeholders as possible. That has been having good albeit slow progress.
  - Greg: Need to be better in the future about maintaining how we have things in production
  - Toby: we think a lot about this on the product side, we have to be more careful about what we move into production moving forward to cut down on tech dept
  - TheDJ: Being clear about where we are top-down and where we are emergent: not 100% on one side for all things, but knowing where the boundaries are for each project; so need a convo about where we draw that line for that

Krinkle: Re: code-ownership goal, I think we do need to aim for 100% code-ownership coverage. Not relying on SRE to the be the owners of last resort.