Wikimedia Developer Summit/2017/Platforms are Products too/Detailed notes

From mediawiki.org

Authors of these notes: Brion, Leila, quiddity, Daniel Kinzler aka Dan K, Dan Garry + 2 unnamed authors

Introduction

  • Dan K: Questions came from Wishlist (Should MediaWiki platform be a product? What should the role of the arch. committee be?)
    • At some point, we decided that the WMF would push features out the door. --> Verticals
    • Who are we catering to? Which features should we develop? With verticals, everyone "does their own pluming". Turns into a mess.
    • Shortcuts happen. It's OK, People's job to get things done.
    • Sometimes you need to rebuild the road. Sometimes it makes sense to build new infrastructure that really solves a problem.
    • Question: Who owns the road and who builds the bridges?
  • Who owns the infrastructure?
    • If you want to have verticals, they need to stand on something. That's what platforms are for. But platforms need owners. These are the people who will figure out what should be developed, maintained, etc. If you don't have these owners, things can start nicely but become flawed over time.
    • We use platforms that others create and that we create. They also need someone to look after them. We (feature developers) are the users.
    • When there is a plan for pluming -- that makes it easier to roll out new features and there's less baggage to work around.
  • How do we get there? Get input on the two questions from the Wishlist
  1. Does it make sense to treat the MediaWiki platform (not the web app!) as a product, *with developers* (us!) as the users?
  2. What should be the role of the Architecture Committee in WMF planning (priorities, goals, resources, ...) and are we there yet?

Discussion:

  • Greg-g: Two questions are the same question. To have a team or whatever responsible for the platform requires that they *are* the arch committee or work for them. We need to figure out what to do with the arch committee -- not everyone reports to the Wikimedia Foundation
    • Dan K: It's not that closely related. There needs to be a product owner for the platform. it doesn't need to include a development team. There needs to be responsibility in decision making. Arch. Committee should be involved in this decision making, but I don't believe that they should be the product owner.
  • Brion Vibber: Thanks! Fantastic! Absolutely yes, we need to treat MediaWiki as a platform/product. We allow people to do their work. There's no question, absolutely yes. But how do we get there? I don't know the answer to that. Throwing around ideas. What do we want it to look like (beyond RFC process)? Make sure that we have a vision of what the platform looks like and that we're working towards it. Great that we're starting conversations.
    • Dan K: There has been some talk about having a charter for the Arch Comm. Perhpase we can have a session about it, maybe tomorrow (although it looks already quite full).
      • Brion Vibber: Yeah we should squeeze something in.
  • Victoria Coleman: [Introduction] I have added a session for tomorrow about the role of the architecture committee. Two questions are closely related. MediaWiki itself is a product that the Foundation relies on. Looking forward to the discussion in the uncoference session if it gets approved.
    • Dan K: that's very encouraging. thanks!
  • Giuseppe Lavagetto: Very concerned about these kind of problems. The first one to suffer will be me and my team (ops). I don't think the platform is just MediaWiki. It's a lot of things. It's search functionality and all the other services. It the WDQS. It's all the platforms we can build on products. Never really solved -- "Are we talking about MediaWiki, the software -- or the whole foundation?" I think that we're failing a bit in both (??). Architecture committee is mostly working on MediaWiki, but we don't have a team working on it. How many people here know the roadmap for MediaWiki? I don't think we have one. We don't have a list of <??> that we want to run. The function of the committee should be coordinate the teams working on the individual parts of the platform. I would extend the view outside of MediaWiki. Wikidata is outside of MediaWiki. We need to coordinate together and extend the way we coordinate. Left to the goodwill of individuals to self-coordinate.
    • Dan K: That's a very good point, and it's not just about MediaWiki. The reason I have been focusing on that is that there is a specific lack in MediaWiki ownership. [distinction between development platform and operational platform?] For all the other things we are using, there is at least some sense of ownership. But again: good point. Is there a sense of ownership for the entire operation. The same principle applies there. I wish the Arch. Committee was more active in that area.
      • Giuseppe Lavagetto: We have many things that don't have ownership that are used in production. It's more of a bridge to get everyone on the same page.
  • Matt Flaschen: Thank you for running this session. I want to talk more about product owner role and Arch Committee role. To me the current work of Arch Comm. is the product owner role. What would the product owner will be doing that the Arch. Comm is not doing right now?
    • Dan K: In contrast to what the arch committee is doing now (which is being reactive) a product owner would be proactive. Doesn't do this, probably, because a lack of resources. No time allocated to this. Is there enough buy-in? We have no official power to prioritize anything. Part of what we should be deciding.
      • Matt Flaschen: Architecture committee could take that role and it would be an expansion of their role.
  • Dan Garry: As a former member of Mobile Apps team, I found it frustrating that when I made requests of the platform for a specific improvement, I never got a clear answer on my request. I prefer the answer "No" to not getting an answer at all. Speaking as a former member of Platform team, I can say that there was always a scope problem. I would like to see the scope being defined here.
    • Dan K: yeah. I see that being a problem. It's not clear what the scope should be or are we talking about one thing -- one platform. Is MediaWiki core? vs. operational platform? Not sure.
  • Quim Gil: As an observer, I'm disappointed/frustrated with the some time mismatch between people who can chime in and vote and people who can actually make decisions and make things happen. There should be better alignment and collaboration between plus-two arch committee and budget owners.
    • Dan K: How many budget owners are here now. (4) That's not bad. These are the higher-ups. Thanks for being here.
  • Brion Vibber: Bringing up something I forgot to mention earlier. We have often talked about the idea of specific/ad-hoc functional committees. ... err working groups. Related to or sponsored by the architecture committee. Would help get work done. Thinking about verticals. Not a good thing, but it's not a good thing either to shut people out. Much better to have people working in different verticals, but are interested in accomplishing some specific goal -- should do so in a structured way. (Example) E.g. a specific project-oriented group. I like that model more than a big, standing committee. It's OK to have a committee to look at stuff. We should not just make decisions, but implement decisions. E.g. looking at an RFC, if there's no resourcing behind it, it'll never get done. Important to look at the actual, functional groups for getting stuff done.
    • Dan K: Working groups. We experimented with it. It takes a lot of time to get people to subscribe, and contribute. In the end, talking more reduces velocity. It does make sense to slow down a bit from time to time. We'd talked about a "no feature year" at some point. It was kind of a joke, but maybe we should do it in order to focus on some of this stuff.
  • Faidon Liambotis: We talked about architecture and product. What we haven't talked about is plain bug-fixing. Things that have been broken for a long time. They have been broken for a long time. This is the third pillar to talk about. We need actual support there. Speaking from Ops side, we are the ones suffering the most from that, but the Movement also suffers from that.
    • Dan K: I agree. It actually keeps back feature development.
  • Gabriel Wicke: If we have one owner as the default owner -- I'm the leader of the services team, but I'm very shy of owning all services. I don't think that it scales. I don't think you can have a team that owns all the parts. It should be split up. One team can be responsible to be the owner. Triaging parts of the platform and making sure they are not neglected. Needs understanding of the wider platform. Looking at MediaWiki in isolation, it will be hard to make decisions. I'm consuming a lot of things -- MediaWiki is an important part, but not all of it. Same with VE. If we continue on our path, we'll have more services that will require this platform experience. We need to have an idea of where we are headed. It should be taken into account for MediaWiki as well. We haven't had that clarity so far. No 3 year plan. We need a better understanding, but no magic bullet. With some structure we can get there if we work together.
    • Faidon Liambotis: I think it's not entirely true. We need the equivalent of what Services team is for MediaWiki. We can't have a team for every small feature/issue of MediaWiki.
    • Dan K: In general, we should ack. the horizontals. If we have owners of the parts, we can have someone responsible for integrating the parts.
    • Gabriel: if only having someone to shut it down. At the moment, we don't have that. It's not fun work, shutting things down is not fun. We need to make sure someone owns it and makes the call for shutting it down if needed.
    • Dan K: Having an owner means that there's someone responsible for making the decision. Not necessarily the one who does it.
  • Victoria Coleman: Plugging one more session. Session tomorrow on tech debt. Related to the work that the Architecture Committee is doing. We feel the need to do better about it. While we're all here, let's come together. Greg and Kevin will have ears wide open. I don't know what we've done in the past. Everyone feels the need to do better around arch committee, tech debt, etc. and I'm committed to help make sure these things happen
    • Dan K: technical debt is a big topic and related to the topic being discussed. There are people who have been willing to fix bugs/jobs, but they felt that they were fixed to specific bugs/jobs and they could not go and address the technical debt.
  • Bryan Davis: I've been here 3.5 years and I think I've heard this talk 9, 10, or 11 times. One of the things I have been thinking about more and more... When we talk about this, it becomes confusing who "we" are. "We" is sometimes the paid staff. "We" is sometimes the volunteer contributors. One of the things I think is worth thinking about is -- are there problems of scale that we are creating when we think of "we" as the paid staff of the Wikimedia Foundation? Always finite resource. Is it possible that the role of the Wikimedia Foundation should be to provide better support for volunteer developers? Better specify the things that are hurting us right now.
    • Dan K: Encouraging more contributions from the outside is an important aspect. There are lots of obstacles to that. Not a very welcoming environment, etc. One of the aspects that keeps people from contributing is the tech debt, that makes the code base much more complicated to understand.
  • Brad Jorsch: I'm doing platform stuff on the reading infrastructure team. This is how we get things done -- doing platform stuff despite what their vertical is supposed to be doing. Some of the reason this discussion hasn't gone anywhere is because this discussion hasn't included the people who can put together a team. Re. MediaWiki as a platform vs. the operational platform, we do have the operations team that works on the operational platform. I might be mistaken, but there's a team there.
    • Dan K: I also have the impression that we have had this conversation quite a few times. The "we" who had discussed this was mainly developers, when it came to creating a team and budget, we were not involved as much.
  • Gergő Tisza: Tying in with what Bryan said before. We are not considering developers as an audience and I think we should do that. The mission of the Wikimedia Foundation is to share knowledge. To do that, we need developers. We do all sorts of things to understand the editors. We don't seem to do the same things for the developers. Developers make ??? changes to the Wikimedia Foundation projects. We don't have a structured way of thinking about them. We have ?? and they made a big deal about that. We have less developers every year. Maybe what we should be thinking about is ???.
    • Dan K: Do you want to talk about the Developer Wishlist?
    • Gergo: We are trying to put together a wish list much like the community wish list, but focused on the developers. The problems they have in working effectively. It's in the unconference sessions stage. You can find it on the session board even though the session happened already. Feedback is welcome.
    • Dan K: that's an interesting aspect. A lot of people are talking about UX, there is such a thing as code usability. There is such a thing as discoverability and readability of the code base. Hardly anyone looks at it. This is important for bringing new/more developers in. Looking systematically at this would be good.
  • Greg Grossmeier: Over the next few weeks we will decide the reality of the foundation for the next year and a half. This is the moment in time that we can use to make changes. That makes things more real. We need to make a proposal for what needs to happen. We need owners of last resort. We need a team to do something like product management. The details are details at that point. Summary: Let's actually follow up the next day and the next day. Who should own that?
    • Dan K: quite a few of you were involved with Annual Planning process. There must have been things that kept these things from getting traction.
    • Greg Grossmeier: two answers (one over beers). One is that the org structure wasn't designed right. The second is that the people in charge didn't want that. We need that desire. Victoria is on board with this proposal. She'd be able to help in many ways.
    • Quim Gil: +1 The developer audience thing. I'm not a vertical. Complaint number 1 after the reorg is "Where is the developer audience?" We could start ?? the developer audience. This would take releng, ops, labs, & technical collaboration. (If your team has a dimension, please join.) Come together to discuss intersection. We have so much in common and then work comes and we don't talk.
  • Mark Bergsma: [introduction] We talked about the distinction between Arch Comm and a team responsible for MediaWiki. If we have a team, the team should have a larger scope. The team should be resourced, and that's a challenge. Half of the current people are volunteers. Making them be able to spend more time. Separately, it's important to have a team that can support MediaWiki. Having a platform team responsible for everything won't work, I agree. Part of the reason that has failed in the past, is that there is a continuing discussion whether third party support should be provided. I would be happy if we had a team at all to take care of MediaWiki as a whole. Getting there would be good. Performance and availability team took care of part of that responsibility, but they were not resourced for that.
    • Dan K.: Good to have *someone* responsible for MediaWiki. Reiterating: There are two different kinds of users for MediaWiki. (1) Mediawiki.tar.gz 3rd party (2) Developers writing code in MediaWiki. Both exist and we need to cater to both of them. We have to make conscious decisions about this.
  • Greg Grossmeier: this isn't a question, but a statement about reading the tea leaves at the Foundation. You will be able to determine the answer, based on where the people will be added to the Foundation next year. Looking at the proportion of people in Technology versus Product. Where people are being allocated is priorities. My new year's resolution: I'm not going to say that I don't have time, I'm going to say it's not my priority. Being honest with myself that something isn't a priority, but others are.
    • Dan K.: Would love to have time for so much more.
  • Giuseppe Lavagetto: What we are as a movement and a foundation. A traditional management infrastructure? And then we have committees who determine what we want to do. Then we have people who discuss what's needed in terms of a platform. Main problem in arch committee -- tech dept on one side, we have a community driven structure that dictates ?? for an infra problem. Then the WMF has its own structure that determines priorities independently of that. Until we rectify these two parts, we'll never have something that is functional. As an example, we want to do inter-wiki notifications (as an example). That needs profound changes to the way our software projects are built. The working group decides that this is the way we should go. But then we don't have staff dedicated to that. So we take a shortcut to implement the feature. We need to sit in a room and decide -- if the devs decide on a thing, are we going to give it resources?
    • Dan K: how to incorporate technical ... into the decision making by Arch committee is very important. The people who know how ... it is, should be consulted.

Closing

  • Dan K.: Thank you for the input. Let's hope we don't have the same conversation again next year
Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Developer_Summit/2017/Platforms_are_Products_too/Detailed_notes&oldid=2370275"