Wikimedia Technical Conference/2018/Session notes/Applying the MediaWiki Platform Architecture Principles

Session Setup

• https://phabricator.wikimedia.org/T206065

• Wikimedia_Technical_Committee/MediaWiki_Platform_Architecture_Principles

Theme: Architecting our code for change and sustainability Type: Technical Challenges Facilitation Exercise(s): Small group rotation.

Leader(s): Daniel Kinzler Facilitator: Zach Scribe: Nick, Irene, Michael, ???

Description: The Wikimedia Technical Committee recently drafted a series of Architecture Principles. These principles and requirements SHOULD guide the Platform Evolution Program and other Wikimedia engineering endeavors. This session seeks to familiarize participants with the Architecture Principles and obtain feedback on those principles prior to the principles being placed on “last call”.

Station 1:

Group Leader: Brion?

Goal 1: Allow users to consume, create, and interact in a form suitable for their devices, with the connectivity they have, in a language they speak.

Goal 2: Empower contributors to collaboratively grow and curate content, and to build the tools that they need to do so.

Station 2:

Group Leader: Daniel?

Goal 5: Ensure programmer productivity by maintaining a code base that can be modified with confidence and understood without needless difficulty.

Goal 4: Provide an open-source software stack that can be easily used, modified, and extended by others.

Station 3:

Group Leader: Timo

Scribe: Irene

Goal 3: Provide APIs that allow 3rd party interfaces to efficiently interact with wiki content. Provide reusable data that can be processed in bulk by 3rd party tools.

Goal 6: Provide a web application that can be freely used to collaboratively collect and share knowledge.

Station 4:

Group Leader: Marko?

Goal 7: Ensure the continued availability and performance of WMF projects through scalable and resilient system design.

Goal 8: Ensure the data integrity of the content on WMF systems, and protect the privacy of our users.

Session Schedule:

14:00-14:10: Session Instructions and Set-up

14:10-14:25: First rotation

14:25-14:40: Second rotation

14:40-14:55: Third rotation

14:55-15:10: Fourth rotation

15:10-15:30: Report backs

Questions to answer during this session

Question	Significance: Why is this question important? What is blocked by it remaining unanswered?
What is the acceptance criteria for the technical product? How can we measure success of each of the principles?
What custom code can we replace with FLOSS components to reduce maintenance burden, and what are the tradeoffs for doing that?
Dispel slim MW core say that "Do we want a slim MediaWiki or not?" is irrelevant and present the alternative thinking.

Action items

• Clarify principles that led to confusion. Discuss suggestions on the talk page of the principles document, https://www.mediawiki.org/wiki/Talk:Wikimedia_Technical_Committee/MediaWiki_Platform_Architecture_Principles (Daniel)
• Align Architecture Goals with Product Visions (Corey)

Summary

• Cheol: there are more "SHOULD" than "MUST" in these. Is that purposeful?
• Sam: could split some of them so there is a MUST and a SHOULD
• Corey suggested: Maybe “Architecture” is too narrow, perhaps we should have “Technical Principles” or “Engineering Principles”. That would include processes, tooling, etc.
• Explicitly reference volunteer devs as “re-users” or “3rd party”
• Have “must be OSS” as a separate principle (but not arch!), not part of “reusable”?

Goal 1

• TheDJ: We need to provide for a variety of workflows.  I don’t think we’re ready to do that which is why we haven’t been able to deliver.
• BV: Speech is another very different form factor, do we need to handle smaller units of text, pulling stuff from Wikidata, there’s a lot of vectors.
• Sage: a lot of our devices is tied to a specific proprietary ecosystem (apple, google). Login is a nontrivial barrier.
• MH: Issue of norms -- editors have control over presentation as well as content -> DJ: WE could give editors that control
• IM: Localized by default, that’s a pretty significant lift in a lot of cases.  Separation of data layer from processing layer and display layer is a necessity.
• BV: A lot of these are aspirational, but we want to make sure our system provides for this.  Need to provide infrastructure for doing translations so that when conditions improve, editors can do their work.

Goal 2

• AH: I don’t like “ensures” consistency, prefer “directs toward” consistency.  Hesitant when we take a parental role over contributors.

Goal 3

• entire goal talks about 3rd party interface but it should talk about public interface - strike 3rd party and change to public? we want to phrase this in a way that allows for 3rd parties which makes it more inclusions; 3rd party and public api are synonymous
• action item: rephrasing goal to change 3rd party to public, or more obviously including those APIs
• what does semi-structured mean? timo doesn’t know. action item to find out and probably strike
• "data formats" a lot of confusion around that wording
• not covered - anything about public vs private, access controls, rights controls; separation between access to public and private

Goal 4

• "Software MUST provide a test suite". - change other testability SHOULD to a MUST.
• No point in every single class being reusable. But ultimately comes back to modularization/granularity
• Accessibility! You need design resources. Good user experience needs user expert feedback and UI design feedback.   
• Re: "deprecation must be documented" - should be announced, advertised, more effectively - which venue?

Goal 5

• Currently not designed for testability
• Conceptual model could be improved

• [2nd mention of] Design for testability doesn't demand actual tests!
• "We should have something like vagrant to help ppl develop", and "we should have [?] to help people install" - Should this go in Product Practices and Guidance? Yes.
• Who is "we"? Whoever subscribes to these principles. What is "MW"? Is it just core or all extensions?
• Point #1 is unclear. "Reflect conceptual model …" is obfuscated!
• How to determine external stakeholders - might not know at the time.  How much resources do we invest into finding out who might reuse it and their needs?
• "Must be testable" vs "must provide test suite" - how designed vs which code actually exists.

Goal 6

• definition of terms (stack and standard hosting platforms esp) so we can collaboratively create this
• tradeoff between catering the wmf use-cases vs others? important to decide!

Goal 7

• Gergo: tradeoff is per-user customization vs scalability & isolation boundaries vs ease of data access

Goal 8

• John: change SHOULD to MUST in goal 8 item 1
• Marko: add data sanitization