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

Session Setup
https://phabricator.wikimedia.org/T206065 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

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

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

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 8

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