Sunsetting Working Group/meeting notes/20171030
Appearance
2017-10-30
[edit]Agenda
[edit]- Review document, finalize for sending to Toby/Victoria
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?
- Operational issues often raise the issue. Example would be needing hardware. That's part of the logstash problem.
- Question: Do we have good metrics on incident where ops has to take care of something on the fly?
- Answer: At that level, not so much. A human decides whether to document when something happens.
- https://wikitech.wikimedia.org/wiki/Incident_documentation overlaps the phab incident project https://phabricator.wikimedia.org/project/board/2143/
- The scale of the required response is not explicitly [?]
- 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?"
- What are the quantifiable aspects of operationally supporting something. (Rather than asking "how do you feel about X?")
- When we can quantify, we should.
- We used an Emergency Room pain chart in fundraising for a little while. :p ( https://dfzljdn9uc3pi.cloudfront.net/2013/37/1/fig-1-2x.jpg )
- 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.