Sunsetting Working Group/meeting notes/20170911

From mediawiki.org

2017-09-11[edit]

Who: Bryan, Greg, Katie, Adam, Gabriel, Corey, Olga, Kevin, Erika

Agenda[edit]

  • Proposal: Split into What group and How group; work independently, then sync up
    • Bigger question is "who owns the decision". Once you have that, the how becomes easy. Need to address the who.
    • There are other conversations and processes around ownership (it's a big portion of Tech Debt work)
    • Worries me that this group could make decisions but not be able to execute them. Compare with TechCom which is now an arm of the CTO.
    • This came out of TechMgt offsite, and Victoria was keen on it, so I expect she would "bless" any outcomes.
    • Finding owners may be half the problem. What if no owner wants to turn anything off? We need institutional pushback--we can't support everything.
    • Might help to have clear expectations of what it means to be an owner. Questions about graphoid are product questions. Same for PDF. Those decisions have always been the holdup. Tech debt seems more like the "how".
    • This group should focus on how to make the decisions. Shouldn't depend on the thing or the who.
    • Question of whether "owner of a project" would be the same as "owner of the decision to sunset"
    • Would be convenient to have the same owner, but that's only reality if the same person controls everything to keep it alive.
    • That's not the case now. Baseline problem is that the maintenance load is not on the same teams. No good way to close that loop now.
    • Specific case: Logstash. Used by a number of groups, but nobody committed to maintain it. Search platform set a goal of investigating possible ownership, consider alternatives, sunsetting, taking ownership. Calls to sunset it, due to lack of resources.
    • Current situation: People who support infrastructure for wonderful things coming out of product...people deciding to cut things due to capacity are not the ones coming up with ideas. In FR Tech, we implement ideas from elsewhere. Strategy on the other side may not be informed by what we can do. Smaller ideas might not get time because of the big projects. We shouldn't make those decisions, but it's hard to get those doing the prioritization to understand how much we can get done.
    • Most useful for me: A tool to force decisions [in product] to inform our priorities. The exchange of info doesn't exist yet. "What is more important for us not to lose?"
    • Even before that, as we create things, we should have something written which is a priority list of things that exist. That allows a discussion about what to cut when necessary. Constant prioritization.
    • Concern that this could be an expansion of scope for this group. We could cover What and How with blinders on, fairly easily. I don't want to work on things that won't be useful for a long time. Maybe the discussion of What/How is premature, and we need to look at org priorities and communications first.
    • Do we expand the scope, or stick to the initial small scope as Greg understood it?
    • Let's do something small. I would find it most useful to find a way to know that we need to send up a flare.
    • Part of the What would be clear guidelines for how the burdened should communicate to others that something is causing pain/needs change.
      • Who gets to say, and how, that something needs to be sunsetted
    • Sounds like the process of finding an owner
    • We could set up a strawdog process. Like a court case. Criteria, defense, etc.
    • Has to go beyond an individual owner. If someone owns one thing, the decision might need to come from higher. Or the decision to prioritize that over something else would also have to come from higher.
    • During the tuneup reorg, there was an explicit(ish) listing of owners. Falls to Victoria or Toby
    • Teams outside the owner might have the burden of maintenance (e.g. ops). So there needs to be a way for non-owners to request sunsetting.
    • Part of having an owner is responding to needs like that. There need to be paths of recourse if other teams are not getting support from the owner that they need.
    • Re-iterating part of what Katie said: There will always be un-owned things; things that slip through the cracks. There will be another OCG (for different reasons). These docs should inform ops of how they should deal with things like a huge maint burden. If the owner is not responsive (or if there is no owner), what would the burdened (e.g. ops) do to fix the pain. Maybe by sidestepping the ownership question we get better results because that case will happen anyway.
    • Back to starting small: Maybe we could come up with criteria for nominating something for sunsetting. One criteria would be no owner. One criteria would be if ops feels it's not maintained.
    • I'd love to see a list of things that will go away if nobody takes care of them.
    • How to do that responsibly.
    • Proposal for next meeting: Start with What and How. If there are enough problems then we could bubble up concerns about ownership, we could check with Victoria about expansion of scope.
  • Benefits of SIG:
    • ???
    • Structure for when a SIG is no longer useful
  • Not sure about membership, since almost everyone in the world is a stakeholder
  • Anyone opposed to being a SIG? Any concerns? (ACTION: Greg will follow up via email about becoming a SIG)

(No time this meeting) ACTION: Everyone should read the OCG retro etherpad, and bring something important from it to the next meeting

  • Next meeting: Should we all meet next week and figure out how to split up?

ACTION: Greg will send summary email and agenda for next week

Retrieved from "https://www.mediawiki.org/w/index.php?title=Sunsetting_Working_Group/meeting_notes/20170911&oldid=2561847"