Sunsetting Working Group/meeting notes/20171030

From MediaWiki.org
Jump to navigation Jump to search

2017-10-30[edit]

Agenda[edit]

Notes[edit]

  • Question: Do we have a tech debt PM?
    • Answer: Yes, JR, as he is the program manager/owner of the Tech Debt program from the annual plan
  • Second fork should say AND/OR?
  • First fork refers to "needs sunsetting", but nothing addresses "no owner but can't be sunsetted"
  • Seems like a matrix
  • Also possible that someone claims to own something, but it still needs to be sunsetted
  • Maybe 2 independent outcomes? Needs owner (yes/no), Should be sunsetted (yes/no)
    • Yes that would be the outcome, but maybe we should ignore that they are separate: If needs owner OR should be sunsetted, then submit to CPO/CTO
  • If this is the sunsetting process, it's about sunsetting. But highly related is "is this an owned product" with long-term maintenance?
  • Sunsetting has 2 questions: Is this breaking? Do we need this? But I think and/or covers it.
  • Risk of pulling up too many details from the rubric into the outcome.
  • We need to highlight projects that need futher investment to either turn them around or throw them away. Toby/Victoria needs to decide and fund some action.
  • Maybe Tech Debt PM needs to define their own process to handle what happens after the rubric.
    • Not sure the TDPM should inform staffing levels. But raising "not enough of these things are happening in this project" seems safe
    • Example: Logstash. Sunset was proposed due to lack of resouces. Would TDPM make a recommendation of adding a person because the manager said so?
    • Isn't the outcome always tied to finances? We raise the concern, and execs decide how to allocate resources.
    • Decision comes later. Maybe this should be a filtering process--output a smaller list, rather than specific recommendations.
    • If the TDPM is not a manager, they could jump to conclusions about staffing, and might make the problem seem smaller than it is. Might be better to keep them out of that.
    • ACTION: Greg: change from "decide it needs to be sunsetted" to "needs to be escalated to CPO/CTO".
  • Question: Can we have things owned by community menbers (outside the foundation)?
  • Answer: Yes. We already have WMDE, for one external example.
    • That's like a third option. So there is funded (WMF/WMDE) and then community members
    • In an ideal world, we make it easier for volunteers to take on ownership
    • In an ideal world, paid staff handle the unpleasant parts, freeing volunteers to do the fun parts they love
  • Does the rubric look good?
  • Rather than "ops is upset", a more empirical point might be "If there are automated alerts, are they being responded to by a combination of ops and devs?" or "is it a frequent cause of monitoring alerts?"
  • Getting this into annual planning is great, but what do we do when something shows up in April?
    • We could boil the ocean and submit a ticket for every project in wikimedia, but that's not practical.
    • This process is probaby going to come up during emergency situations.
    • Maybe add a line to say that an evaluation could be done at any point during the year.
    • If we raise an issue outside the annual planning cycle, what could be done to address the problem?
    • There is usually a way to juggle resources mid-year when necessary.
    • Mythical man-month problems. These usally can't be solved with a new hire. They require shifting an existing person, which creates a new orphan. CPO/CTO can help identify what we can drop, and for how long before it becomes the new emergency
    • Solutions tend to require ongoing expenses, not just one-off.
  • There is a bullet in the rubric about usage. This focus is on the technical side, but should we address strategic need, etc.? Or do we leave that to someone else?
    • That's definitely data that CPO/CTO need to make their decision.
    • Maybe it's needed if it's not a community-owned thing. If it's external, the external folks can decide?
    • Maybe there is a CPO/CTO rubric.
    • We hand them a status, and then they can evaluate how it fits into the bigger picture.
    • There could be a case where there is a barely-used feature, which is OK technically, but might not be worth supporting. That should be a valid case to consider sunsetting.
  • Next steps: Greg will clean up, and re-circulate for final review. Then will share with Toby and Victoria to get their input.