Sunsetting Working Group/meeting notes/20171002

2017-10-02

Agenda

• Review previous meeting action items
  • ACTION: By next meeting, solidify the 2 cases in the strawdog proposal (text below)
  • ACTION: Greg to send reminder Thursday to work on the strawdog
    • Sent the first week; not the second
  • ACTION: Greg to reschedule to biweekly meetings
    • DONE
    • rescheduled Oct 16 over quarterly review meetings
• ?

Notes

• Present: Brion, Bryon, Erika, Faidon, Greg, Katie, Kevin
  • Interesting note: Attendance today is only technology dept folks until Olga came in
• Next meeting (Oct 16) are the tech quarterly presentations. OK to squeeze this between? Yes.
• DECISION: Next meeting will still be Oct 16, but will be at 11am SF time (half an hour later)
• ACTION: Greg will mention lack of non-tech participation in follow-up email

Proposal

IDEA: Enumerate list of possible orphans/sunsets prior to annual planning

Case 1 (Before annual planning - 3 months?): Straw dog proposal:

   1. Identify projects that should be evaluated for sunset
   2. Review and (if unowned) try to find owners to adopt
   3. For projects that aren't adopted, send to Leadership team prior to annual planning
   4. Leadership team picks who does the evaluation, and do it (done by December at the latest)
   5. Leadership team can choose to fund the product or fund the sunset of all projects, before finalizing budget for next fiscal

Open questions:

• Should there be an "owner by default" (eg: all user facing things are to be decided/sunet by Audiences)
• What is the criteria for nominating a project for Sunset to Leadership team (not just that there isn't an owner, maybe we identify resourcing constraints)
• At what point to involve community and get input (Maybe during the Leadership team process)
• What can we do differently upstream (earlier in the feature development process), to avoid this year's sunsetting triage in the future?
• When would community be consulted?

Case 2 (emergency):

Discussion

• Do we need a limit on the number of proposed things? Could we evaluate 16 things at once?
• Comes down to focus.
• Sounds like there is an implied step of prioritizing prior to the evaluations
• Possiblility of gaming the system by submitting low-priority pawns
• Prioritize based on reach (users), number of people it affect, difficulty of maintenance (vs sunset), available alternative, what's at risk if you do nothing
• When would community be consulted? Not always a binary decision--different work was required for different workflows
  • If done right, this could greatly delay the process
• How have conmunity consultations gone?
  • Depends very much on the project. Something used a lot, or that certain community members are passionate about, are more difficult
  • We have tried to find and target actual users (eg: banner on the OCG page, direct to a talk page) more than just doing general village pump announcements)
  • Can be difficult to identify and/or reach people who really cares about a particular feature
  • Even for editor features, an editor who really cares might not be available/attentive at the right place and time
  • The right question might be: What is the minumum time for consultation? Some might go longer. Maybe the shortest might be 4 weeks.
• Sounds like we're aiming for a point in time where all the candidates are discussed. That's good and bad.
  • CL might have to focus a lot of their time on these, for some short period of time
  • Do we want to have 6 open conversations with communities? Potential to burn out both CL and community menbers
  • Maybe we are prematurely optimizing.
  • Could filter during prioriization step to limit the consultations to a manageble number
  • Delivering information in smaller pieces can work. Reaching out as soon as a project starts, to announce the planning. 2-line update. Raises awareness, to avoid surprises later
• Should prioritization fall to the leadership team, or should a group give a prioritized list to them?
• Is this "Here is a list of all the things we think should be sunsetted"? or "Here are sunset candidates including some that have owners". If owners step forward, are there expectations from the sunsetting WG that they would need to meet? Does that proposed ownership go to the leadership team?
• We don't want to overload Toby and Victoria. So we want to limit their involvement to the key decision: Sunsetting. So I wouldn't submit logstash to them at this point.
  • The ones that don't have clear owners
  • The ones that need an owner or need someone to sunset
• Anything that lacks an owner, even if I don't think it should be sunsetted. Decide to fund it, or important but unfunded, or sunset. It would be good to flag something that is unmaintained or unmaintainable.
  • So not just a sunsetting list.
  • Not sure how something not at risk of sunsetting fits into the scope of this process and this working group
  • We need to identify risks of something not having an owner or getting funding. We shouldn't be too prescriptive about what should be done.
• Could we get Victoria to attend maybe the meeting after next? Or Toby?
  • Agree. Would be good to get their approval.
  • We don't yet have a proposal ready for them to approve async, so it would be great to get 30 minutes of their time.
• Curious about first step of process: Identification. Some things have ownership on paper, but not reality. Example: Web team technically owns 20 different extensions. Many don't need active maintenance. What would be the master list for starting the identification process?
  • Some people own things and aren't aware of upcoming problems.
  • Ops suffers from some things; once or twice a year we could come up with a list. That could be a starting point. Security team could do the same.
  • Probably a lot of the time, owners don't even realize their stuff is causing pain for other teams
  • Product managers might also have ideas
• A lot can happen in a year
  • Probably shouldn't only do this once per year
  • I don't want to have to wait to tell people something is a problem. I would prefer not to have just a big time to look at everything. We should be able to raise concerns, and have decisions made outside the annual plan. We can do this before the upcoming annual plan, but long-term, something more adaptable would be great.
• Back to Toby/Victoria: Greg can schedule time with them. Probably not with the whole group.
  • ACTION: Greg to set up meeting w/Toby and Victoria
  • Katie, Faidon, Olga, Kevin
• ACTION: Greg will clean up this proposal and put it in a google doc; will include preamble and the questions we would like them to answer
• ACTION: Greg will share the proposal gdoc with this group