Topic on Talk:Core Platform Team/PET Work Processes/Clinic Duty

As much as I love that this section exists, being realistic, I do not think it's feasible to maintain its accuracy in the long run

I second Petr's comment about the clinic duty roster. For one, this should be separate from the description of the clinic duty process which seems to be the main focus of the page. Maybe a link to a page with current CPT team assignments?

In section 4: Having a one week planning horizon for CD seems too short. Should at least follow the 2 week cadence -- meaning I should know 2 weeks in advance, I'll be on clinic duty. This somewhat clashes with the Team Formation section where it states that "members transition in and out" Probably want to clarify that.

In section 5.1 (Initial task triage) responsibilities should probably be determined ahead of time. It might help to split this responsibility between a senior engineer and a junior engineer to have ongoing cross-training and a clear first line of contact in case questions arise during triage.

Section 5.4 seems to add unnecessary overhead to the process. "Waiting for Review" could (should?) probably be renamed to "In review" since the review pipeline is actually external to the work board, i.e. the source of truth is either in Gerrit or GH. It also states "If the review results in a -1, the task should be moved back to Doing.". If we renamed it that would not be necessary.

Above applies to 5.4.1.

Section 5.5 "The Engineering Manager is responsible for updating Current Clinic Duty Rotation on this page as assignments change. Or else we should figure out some other way to handle it." should go under team formation.

Section 6 should start with the goals and then propose the metrics that we think measure goal progress accurately.

I tend to agree about the roster. I wanted to leave it up to the EM to decide, though, so I just wrote in there that the EM is responsible for it.

Section 4: I have no real opinion on whether it should be one week or two weeks or what for members knowing when they'll rotate; currently my impression is that we don't really even get the one week.

Section 5.1: I didn't want to try to specify team dynamics too strongly, particularly when things like timezones are so often a concern. If we say "one senior and one junior", for example, that can break down if some week we have no "juniors" on CD, or two people with no timezone overlap, or something like that.

Section 5.4: I'd oppose removing the "move back to Doing" bit without having a functioning replacement in Gerrit. Until the replacement actually exists, we need the documented process so reviewers can easily find things to review without having to sort through all the things already -1ed. Once it does exist, we can easily change the documentation to point to it. Such a thing might also be able to eliminate the "in progress" column in section 5.3, which serves the same purpose of separating things needing review from things -1ed.

Section 6: Personally, I always get stuck hard on the problem that the things we actually want to accomplish are hard to really measure, and the things we can measure usually have only a passing relationship with the things we actually want to accomplish. For example, "number of patches reviewed" or "time until review" would have us write and review lots of small trivial patches and avoid anything major (or have so many baby-step patches that we lose sight of the forest for the trees). I haven't found a good name for this yet, but w:Goodhart's law, w:Campbell's law, w:McNamara fallacy, and w:Streetlight effect all come close.

For the metric section, can we use something like this:https://wikifarm.wmflabs.org/cpt/index.php/Clinic_Duty_Stats

• Who is responsible for updating the Clinic Duty page (not just the #Current Clinic Duty Rotation on this page)?
• How do tasks come into the Inbox column?
• What specific objectives has the team set to respond to tasks "in a timely manner"? How is the team tracking metrics?
• What other data could users enter when they create tasks to make the triage process faster?
• What information is often missing in new tickets?
• Who assigns tasks to different action columns?
• How does the team determine when to move a ticket into one of these columns? (there's already an explanation, but I would need more information).
  • Backlog
  • External code review needed
  • External code review in progress
  • External code review completed
  • Next
  • Ready
  • Doing
  • Waiting for review
  • Waiting for deployment
  • Blocked externally
  • Discussing
  • Done
• How does the team determine when to move a ticket into one of these columns?
  • Triage meeting inbox
  • Security issues triage
  • Outreachy Google mentoring tasks
  • Volunteer needed tasks
  • Feature Requests to review
  • Tech planning Review
  • Feature initiatives/ small projects
  • Tracking/ Watching
  • Icebox
• How do tickets for from each column to "Done"? I would like to map it out
• Who is responsible for preparing and organizing planning events?
• Are the tasks on the external Code Reviews Workboard counted in the Clinic Duty Metrics?
• How could we make the workboard more legible? Kanban should help us visualize our tasks and limit the work in progress. I would like to understand why each column is on the board, why there are further subdivisions in each column, and how we can work together to simplify it while keeping what matters most to you.
• How can we help team members limit work in progress?
• Do engineers always start working with tasks that are closer to "Done" first?
• Are columns prioritized? If yes, which column needs to be tackled first, second, etc.? I would like to know if it's a priority for the team to tackle blockers and tasks in review before starting a new task.