Page MenuHomePhabricator

Wikimedia Technical Conference 2019 Session: Mediawiki Code Ownership
Closed, ResolvedPublic

Assigned To
Authored By
Oct 4 2019, 3:43 PM
"Love" token, awarded by Addshore."Love" token, awarded by bd808."Meh!" token, awarded by zeljkofilipin."Pterodactyl" token, awarded by brennen."Like" token, awarded by MusikAnimal."Love" token, awarded by Jrbranaa."Love" token, awarded by hashar."Like" token, awarded by Aklapper."Love" token, awarded by TK-999.



  • Track: Standardization Decisions
  • Topic: Mediawiki Code Stewardship


The Code Stewardship approach was adopted by the Wikimedia Foundation in early 2018 as a mechanism to ensure that code which is deployed to the Wikimedia production environment has the necessary guidance and resources to be evolved and maintained in a sustainable way. Unlike services and extensions, MediaWiki is particularly challenging to steward due to its architecture. This session will focus on how to best apply the Code Stewardship model to MediaWiki core as well as discuss possible evolutionary changes to the Code Stewardship model.

For more information about the current definition and processes around Code Stewardship, please see "Pre-reading" section for relevant links.

Questions to answer and discuss

Question: Should we divide MediaWiki into sections and assign maintainers?

Question: What incentives can we provide for stewarding code long-term?

Related Issues

  • Platform Stewardship
  • Community Code Stewards

Pre-reading for all Participants

Post-event summary:

  • Code Stewardship vs Code Ownership
    • Overall Code Stewardship is more inline with FLOSS although there may need to be another layer to address things like roadmap directions etc...
    • Code Stewards responsibilities need to be better defined.
  • There's no clear winner for how to segment out MediaWiki as there are often overlapping responsabilities
    • Interesting idea is meta data could be placed in the repo, better describing areas of responsibilities in addition to other meta data. This is much more useful than on-wiki info.
  • Incentivizing Code Stewards depends largely on the nature of the Code Steward (Staff vs Volunteer).
    • Gamification could be something worth investigating.
  • Code Stewardship should be a group responsibility or perhaps shared amongst groups.

Post-event action items:

  • Review existing definition of Code Stewardship with existing/practicing Code Stewards to see how to best augment it.

Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019

Session Name / Topic
Mediawiki Code Ownership
Session Leader: Jean-Rene; Facilitator: Brooke; Scribe: Brennen

Session Attendees


  • Desired outcome: better understanding of [... slides...]
  • Group discussion: Some subtle differences between ownership and stewardship:
  • Used interchangeably quite a bit.
    • Fisch: Was this about mediawiki core or all extensions...?
  • JB: mostly core, as extensions are a bit clearer and already defined.
  • DA: Ownership is easier to define, stewardship harder?
  • slides: Things to consider: What do we mean by responsibilities, authority, differences between the ownership/stewardship?
  • BD: Differences: Ownership i think of as "this is mine, I own and responsible for this one". Stewardship is more about "problems of the commons" like i am a steward of the land". For Core, can't define anything smaller than "wikimedians" as owners, but e.g. "logging" i felt like the "owner" for some years. Does that match up with others?
  • Piotr: Ownership = you own it and tell people what the direction is, and are guiding it, and have a vision of where it will be in 5-10 years. Stewardship, you're helping other people to define it, and helping them get to that place.
  • DA: ownership is about your life in the project, so when you leave it stops [or someone else takes over]. Stewardship is more about setting something up so it still works after you're gone.
  • BM: agree with BD, ownership is about wikimedia owns is. but not necessarily all leading it, too many cooks, so that's more about leadership, leadership as a service to our shared product.
  • Leszek: i'm not sure about "wikimedians being owners", as too broad a definition. But i don't have a clear definition yet, though I'd be thinking about responsibilities and leadership. Authority to say, if there's a suggestion to do x, you can say "no we cannot do tht". I want to hear more about how Wikimedians could be considered Owners.
  • GG: Similar to Leszek, ownership i think of as being like a PM/PO (product manager / product owner). This session is because MediaWiki doesn't clearly have a PO. Cindy et al are POs of parts of the stack. But Wikimedians are not very good at being product owners.
  • GT: ? clearly defined areas. Licenses declare who owns the code. I'd like to see us distancing ourselves from that term.
  • BM: +1 to GT, That's how OS is defined, i think we need a different term.
  • JB: Stewardship seems to be more reflective; looking at specific areas of code, and has the code's best interests in mind. To some extent a cat-herder.
  • Fisch: I'd still want to see 2 terms used. Authority and responsibility are relevant. Ownership = "I want to see this direction", stewardship =" I feel responsible for this software's stability"
  • GT: 1) code is on fire. Production/platform stewardship. 2) not actively working on it but reviewing patches and supporting contributors and ?? 3) actively working on it.
  • WD: in last few months my team has taken responsibility for some bits that others were working on. But accountability and responsibility not clear, because we're now ALSO paying attention to it. Not clear what level of service we should be providing.
  • JB: Things that led to this: response to code-reviews, and ???. "Who do i talk to? it's great there's all these maintainers, but they might not have time to help in this moment". What do we need to clarify to be successful? I do want to make the distinction that we're talking here primarily about stewardship.

Breakout groups

  • Question 1: What are some logical ways to segment MediaWiki? What are the pros/cons of each approach?
  • Do the namespaces reflect logical domains? -- partially, but also some cross-cutting areas like security, etc.

Group 1

  • LZ:
  • What about services?
  • By functionality
  • Ability to watch only certain parts -- Broken out into components and repos, and watch the board, but only care about 1 part of it, so if smaller then more people will follow it and thus give more code review
  • With enough granularity that a max of 3 teams share the stewardship
  • Cons: Often more than 1 team will be owner. More cross-cutting across components and teams. More communication and coordination between teams is needed.

Group 2

  • AS:
  • On phabricator, we have different parts of MediaWiki without herald rules so are often unseen. Would be good to fix that. - cons: more cross-cutting across components and teams. cons: multi-ownership.
  • list and list --. Pro: already exist, Con: neither are clear or comprehensive or uptodate.
  • -- pro: exists, con: 2011
  • Structured data in code? Linking to phab projects? Perhaps combined with Regexes searches and whitelist/blacklist? -- Pro: ties together lots of different things; files->teams->projects->workflows. Pro: identifies multiple stewards of single elements (multi-ownership)
  • More boundaries; decoupling; librization; componentization; modularization. Or... Directories (or namespace) in mw core. -- Pros: sorting out code base doesn't actually map to teams/stewards. Pro: Cleaner boundaries = easier ownership (e.g. extensions). Con: There are Dirs are useful (auth, object cache but also Dirs that are Not useful (specialpages, API)
  • Contributors: who edited what. Do what github/gitlab do, expose previous contributors. Pro: less to think about.
  • Cross-functional teams! Split by use-cases.
  • Fallback team.

Group 3

  • BD:
  • Could split by:
  • classes,
  • components,
  • use-cases,
  • personas (At highest level there's editing and reading, but then patrolling and curating and creating. and then ...)
  • By date or "last touch".
  • Libraries.
  • Design-patterns.
  • Not janitors.
  • Responsibilities of cross-cutting concerns, like dependency injection. caching, load balancing.
  • Skill sets.
  • Overlapping nesting of this, venn diagram. Maybe this is a discussion of cons, e.g. classes and components, there's an intersectionality with a common core but cross-cutting concerns.
  • Code Stewards should seek to create better paths for the next stewards.
  • Stewards should be teams/collections, not individuals
  • Stewards as "king" who listens to problems and makes decisions

Group discussion

  • Gerrit-bot: let's you subscribe to notifications to gerrit changes, by directory repo file regex.
    • PM: Once i did it by all repos Readers Web maintains but quickly got overwhelmed.
    • Tobi: enables ways for people to take responsibility. But there should also be a way of assigning accountability, which wasn't discussed much yet
    • AK: also a way for who wrote that code. gerrit internal watching feature and git-reviewers page.
    • Problem is people don't need to accept a review - it's unclear if the mail was read or anyone is ever going to review it.
    • 3 different levels in gerrit, reviews
  • JB: there's always the tendency of overlap between teams. The main challenge, and not obvious how to get past it. But as long as we're clear about where ownership/stewardship live, we can improve.
  • Monica: Platform evolution should help us to get there, [and we should define this further before we're too far along with that?]
  • AS: Instead of a wikipage or bot, let's have a single overview tool that shows us what's missing.
  • GG: differential and diffusion have a mechanism called owners, where different people or teams could own different [?] and thus own code-merges in those areas.
  • Piotr: I know it's controversial but: gamification, badges, incentivization, stickers on laptops. Might be the way to go for younger generation at least.
    • DA: used to be active on StackOverflow, and the badges are great, but the best part was the Reach metric. "Your answers were seen by 1.9 million people". We can get those metrics to our contributors in a meaningful way.
  • Leszek: ramble but... what is the reward for people doing it, and for communities who get things faster and smoother. Rewarding to say "i'm doing that, and doing a good job". For stewardship we should revisit the responsibility and accountability - we're not just responsible for reviewing things, but it should be clear what we are supposed to be doing - not just reviewing things when i feel like it, not avoiding difficult and complicated areas.
  • JB: Want to see the stewardship metrics in the future, responsibilities. How can we help people feel good about doing the low-level boring work.
  • TG: org has a default structure, annual reviews OKRs etc. Code-review doesn't factor into that at all. For volunteers there's the default structure of appreciation, where we're also not doing very well.
  • L: As a manager, Code-reviews is definitely part of the thing I review in a reportee.
    • Yes, but inconsistent.
      • As an engineering culture we need to make it clear that if we don't do this we can't do anything else well.

Event Timeline

This is especially important when deploying code to production, it might be difficult to find the proper code maintainer. I am worrying this session might be to short to address the problem and find a clear solution.

Happy to help with this session.

@Jrbranaa @D3r1ck01 - Would either or both of you be interested in leading this session?

@Jrbranaa - Great! Please add yourself as the session leader above and flesh out the description as needed.

Personally I am not a fan of the focus on team ownership. It is entirely possible for a developer community to have shared ownership of code, and IMO it's a better fit culturally. The problem is indeed the lack of incentives (fixing a problem in some random area of code means you are taking away time from the work you are going to be evaluated on, and the push for OKRs makes that even worse).

debt triaged this task as Medium priority.Oct 22 2019, 7:06 PM

(Programming note)

This session was accepted and will be scheduled.

Notes to the session leader

  • Please continue to scope this session and post the session's goals and main questions into the task description.
    • If your topic is too big for one session, work with your Program Committee contact to break it down even further.
    • Session descriptions need to be completely finalized by November 1, 2019.
  • Please build your session collaboratively!
    • You should consider breakout groups with report-backs, using posters / post-its to visualize thoughts and themes, or any other collaborative meeting method you like.
    • If you need to have any large group discussions they must be planned out, specific, and focused.
    • A brief summary of your session format will need to go in the associated Phabricator task.
    • Some ideas from the old WMF Team Practices Group.
  • If you have any pre-session suggested reading or any specific ideas that you would like your attendees to think about in advance of your session, please state that explicitly in your session’s task.
    • Please put this at the top of your Phabricator task under the label “Pre-reading for all Participants.”

Notes to those interested in attending this session

(or those wanting to engage before the event because they are not attending)

  • If the session leader is asking for feedback, please engage!
  • Please do any pre-session reading that the leader would like you to do.

Personally I am not a fan of the focus on team ownership. It is entirely possible for a developer community to have shared ownership of code,

@Tgr I agree, I think that it's important that the developer community continues to share that ownership. To a large extent that's why the Code Stewardship approach is less about ownership and more about stewardship. Meaning, the Code Stewards don't necessarily make the decisions (especially in isolation), but work to ensure that the overall health of the code is acceptable and that the necessary resources are in place to ensure it's success once deployed into WMF production. In all actuality, there's no reason that Code Stewards need to be WMF staff/teams. Albeit in the early stages of implementing this model, that has been the case.

When first proposing the Code Stewardship model, I was particularly sensitive to finding something that would fit the broader community's culture whilst also solving some of the problems we had with making progress in things like increasing code quality and addressing technical debt. In the end, if it's implemented well, this will be an enabler for the broader community to contribute even more.

It might be mentally easier to "own" a library with well-defined scope (see T234654: Wikimedia Technical Conference 2019 Session: Componentization and sharing with the open source community) than a vaguely specified area of MediaWiki core.

Would it be beneficial to discuss also what we mean with ownership/stewardship? I feel there is a friction between different responsibilities that cannot be filled by one person: understanding how it works, doing basic maintenance, giving a product vision, providing SLAs for fixing UBNs, etc. E.g. says that you must commit to imho unrealistic SLAs to be a steward. Is there a way to perhaps split these responsibilities somehow?

What if I am a developer of an extensions that gets deployed to WMF? I would still like to "steward" the extension, but not be responsible for handling WMF production issues.

@Nikerabbit agreed. My initial thought about segmenting the Code Stewardship of core is that it should be logical and avoid abstractions as much as possible, as abstractions ultimately need to be managed/maintained and often fall into disrepair. It will be interesting to see if the outcome of the session you mentioned could yield such a segmentation.

As for the sharing of Code Stewardship responsibilities, there's nothing inherent in the Code Stewardship model that requires a steward to be a single person, in fact it's preferable if it a group/team. The key goal of the Code Stewardship model is to ensure that code in production is properly cared for and resourced. What that looks like will continue to evolve for some time, to be sure. As for SLAs and such, they need not be unrealistic, they simply need to reflect the needs of the community, which today is inconsistent at best. That being said, it's also important to note that the Code Stewards are not necessarily expected to single-handedly meet expectations. As Code Stewards the primary responsibility would be to work towards identifying the needs and working with the broader community (including WMF, WMDE, etc...) to ensure those needs are met.

In short, yes, I agree that more definition would be beneficial and would lead us to be able to better share Code Stewardship responsibilities :-)

kaldari updated the task description. (Show Details)

Con: There are Dirs are useful (auth, object cache but also Dirs that are Not useful (specialpages, API)

I find the core includes/api/ directory very useful. It could probably use a bit more sub-structure (e.g. separate actions, formatters, query submodules, utility classes/traits), but that'll probably come if we ever get back to namespaceization.

Thanks for making this a good session at TechConf this year. Follow-up actions are recorded in a central planning spreadsheet (owned by me) and I'll begin farming them out to responsible parties in January 2020.