Wikimedia Technical Committee/MediaWiki Platform Architecture Principles/Hackathon Notes 2018

- Goal is focused on "Platform Evolution Program" but seems that it should be applied to all future development
- Column two seems to be a mix of product level and engineering level. To be read as non-functional requirements.
- Principles exist at the line between product and engineering
- Should perhaps be coordinated with Product Managers and Audience Teams
- collect and share learnings. post-mortem, etc. community/management policy, or part of documentation? Document rationales of eng. decisions!
- engineering *process* principles/documentation is missing.

-> For each row, say which *audience* these requirements are to benefit: readers, editors, admins, wiki-owners, developers, etc.
-> #1 and #2 needs coord with audiences

1. 1 [Equity] Make content available to users, in a form suitable for their devices, the connectivity they have, in a language they speak.
   

- consistency may counter innovation. we do it this way because we have always done it that way.
- we aim to be "eventually consistent" . "Convergence".
- ^ Perhaps we could say something to the effect of "a commitment to eventual consistency with room for experimentation"?

1. 2 [Equity] Empower contributors to grow and curate content, and to build the tools that they need to do so.
   

- examples are useful
- 2nd column seems to be about product, but we have to consider these requirements when building infrastructure, to enable extensibility, etc.
- vertical scripts should be here
- DJ: I feel that i miss the social aspect here. We are also building for people to collaboratively work together.s
- Empower contributors to grow and curate content -> Empower contributors to collaboratively grow and curate content

1. 3 [KAAS] 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.
   

- what does it mean "model around what MediaWiki does"
- does this contradict "use APIs internally"?
- APIs should not serve chunks of HTML. That does not mean nothing should be serving chunks of HTML (which could be considered to be a higher level API).
- TS: new REST api needs to support "bundled HTML"
- CF: We should support a "higher layer" of APIs that compose the the general APIs to serve specific high traffic UIs
- GT: the write aspect of KAAS should be covered more explicitly / in more detail

1. 4 [FLOSS, Equity] Provide an open-source software stack that can be easily used, modified, and extended by others.
   

- publish FLOSS, and actually support it
- Also having an environment conducive to collaboration, following Code of Conduct, encourage diversity and new contriibutors

1. 5 [Sustainability, FLOSS] Ensure programmer productivity by maintaining a code base that can be understood without difficulty and modified with confidence.
   

- move "Create reusable software components based on narrow, stable interfaces" to #4?
- tests should tests contracts, not implementation details
- "good test coverage" means good quality of tests, not just line coverage
- understood "without difficulty" is a bit optimistic. some of the problems we solve are inherently difficult to understand. perhaps it's more important that there are always enough maintainers around that do understand the difficult parts of the code and can convey them through mentorship or documentation
- dep management: make reference to eco systems, being part of the community, being a good citizen
- management tools -> 3rd column,
- mention deprecation policy, versioning
- MW uses snapshot versioning
Link: https://www.mediawiki.org/wiki/Deprecation_policy , https://phabricator.wikimedia.org/T193613
-

1. 6 [FLOSS, Equity] Provide a web application that can be freely used to collaboratively collect and share knowledge.
   

- Not just "MediaWiki", people want lots of other things (extensions, skins, non-MediaWiki services like search, parsing, etc. or they'll get very limited.
- Q: "continue to support vanilla LAMP"
- Need to make it clear that we want to support the "full" MediaWiki stack for installation by 3rd parties (which includes VE and other services)
- NASA has a good installation management system for MW. We should be in touch.

1. 7 [Scalability, Resilience, KAAS] Ensure the continued availability and performance of WMF projects through scalable and resilient system design.
   

- change management doesn't quite fit
- sustainability of *knowledge* (dumps, data formats, backups)
- ensure monitoring for *existing services too :)
- better scalability supports abilities in #1

1. 8 [Security, Privacy] Ensure the data integrity of the content on WMF systems, and protect the privacy of our users.
   

- knowledge integrity: citations etc as principles on the product level
- "perform security audits" seems like it should be in 3rd column as an 'implementation' of security
- be responsive, be proactive, not just "perform security audits".