Page MenuHomePhabricator

Wikimedia Technical Conference 2018 Session - Architecting core: layers/components/libraries
Closed, ResolvedPublic


Session Themes and Topics

  • Theme: Architecting our code for change and sustainability
  • Topic: Definition of Core, how code fits together, architecture, code encapsulation, FE/BE separation, extension interface

Session Leader

  • Daniel Kinzler


  • Joaquin Hernandez


This session focuses on defining criteria and methods for improving modularity of MediaWiki core and other software components. A key task will be to define components in a way that removes circular dependencies, and provides stable interfaces for use by other components and extensions. On the organizational level, we hope to establish clearer rules for code ownership, by splitting the code base into individual components with clear responsibilities.

Questions to answer during this session

QuestionSignificance: Why is this question important? What is blocked by it remaining unanswered?
What are the advantages of modular software over monolithic software?We should agree on the rationale before we discuss concrete goals and next steps.
Which units of modularizations are useful for this discussion? What defines a “modules” or “component” in this context?Let’s establish if we are talking about classes or namespace or repositories or layers, etc. Let’s agree when code is “one thing” as opposed to “multiple things”
Which components in MediaWiki are “knots” that need to be solved to remove circular dependencies?Identifying components to refactor with high priority leads to concrete next steps and resource estimates.
What best practices can we follow to reduce and avoid spurious dependencies and improve modularity? How should the code be refactored?Agreeing on a set of best practices should aid the discussion and provide guidance to architecture discussions and strategies for day-to-day work.
Who will do what to improve modularity? What should we all do, what will individuals do?Agree on concrete next steps and assign responsibility

Facilitator and Scribe notes

Facilitator reminders

Session Structure

  • Define session scope, clarify desired outcomes, present agenda
  • Discuss Focus Areas
    • Discuss and Adjust. ''Note that we are not trying to come to a final agreement, we are just prioritizing and assigning responsibilities!''
    • For each proposition [add etherpad link here]
      • Decides whether there is (mostly) agreement or disagreement and the proposition(s).
      • Decide whether there is more need for discussion on the topic, and how urgent or important that is.
      • Identify any open questions that need answering from others, and from who (product, ops, etc)
      • Decides who will drive the further discussion/decision process (ie: a four month deadline)
  • Discuss additional strategy questions [add etherpad link here]. For each question:
    • Decide whether it is considered important.
    • Discuss who should answer it.
    • Decide who will follow up on it.
  • Wrap up

Session Leaders please:

  • Add more details to this task description.
  • Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc).
  • Outline the plan for discussing this topic at the event.
  • Optionally, include what it will not try to solve.
  • Update this task with summaries of any pre-event discussions.
  • Include ways for people not attending to be involved in discussions before the event and afterwards.

Post-event Summary:

Action items:

Event Timeline

kchapman renamed this task from Wikimedia Technical Conference 2018 Session - Core: layers/components/libraries to Wikimedia Technical Conference 2018 Session - Architecting core: layers/components/libraries.Oct 3 2018, 2:25 AM
debt updated the task description. (Show Details)
debt added a subscriber: Jhernandez.

I read the notes. I saw discussion about this being a resourcing problem, but I also think there is a skill problem: it's not realistic to expect developers to be able to refactor old core code (which they likely unwillingly inherited) to produce a new well refactored code while keeping adequate backwards compatibility to not drive all users of the code mad. What support can the organization give to the teams (besides time on their annual plans) to ensure code gets better, not just different? Or from a different angle: what kind of support would the teams need or benefit from?

I created several tasks for implementing the things that were discussed during the session. They currently hang off the session as sub-tasks, but that doesn't make sense semantically (they don't block the session, the session is done). As soon as the new tag proposed in T207976: Create "MediaWiki-Decoupling" phabricator project exists, they should be tagged accordingly, and this ticket should be closed.

daniel updated the task description. (Show Details)

Session done, tickets filed.