Session

• Track: Standardization Decisions
• Topic: Mediawiki Code Stewardship

Description

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

• https://www.mediawiki.org/wiki/Code_Stewardship
• https://www.mediawiki.org/wiki/Code_stewardship_reviews

---

---

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
https://phabricator.wikimedia.org/T234655

Session Attendees

Notes:

• 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.
• https://www.mediawiki.org/wiki/Developers/Maintainers list and https://phabricator.wikimedia.org/project/ list --. Pro: already exist, Con: neither are clear or comprehensive or uptodate.
• https://www.mediawiki.org/wiki/Feature_map -- 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.