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.
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?")
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.
