Page MenuHomePhabricator

(To discuss) Implement "Request time to response" KPI
Closed, DeclinedPublic

Description

Definition: The average time between a request being submitted to a project owned by RelEng and having the request responded to.

Goal: TBD after seeing the data

Purpose: Much of what RelEng does is supportive to others (infrastructure team...), and responding to requests in a timely manner is A Good Thing(TM).

Event Timeline

greg raised the priority of this task from to Needs Triage.
greg updated the task description. (Show Details)
greg added a project: Release-Engineering-Team.
greg added subscribers: greg, Aklapper, thcipriani.

Bear in mind we receive requests both through Phabricator and Gerrit. The later is hard to track since lot of repositories have shared responsibilities (such as mediawiki-config).

Regarding Phabricator, the raw material is available (find out the time between a task is added to a Release-Engineering-Team project and the time a member reply / triage. I am sure it would benefit a lot of other teams as well and that might need an Epic of some sort for Phabricator.

Bear in mind we receive requests both through Phabricator and Gerrit. The later is hard to track since lot of repositories have shared responsibilities (such as mediawiki-config).

Good point. I didn't think of the Gerrit issue. I think we'd have to scope this to Phabricator only. "If it ain't in Phabricator, it didn't happen." :)

Regarding Phabricator, the raw material is available (find out the time between a task is added to a Release-Engineering-Team project and the time a member reply / triage. I am sure it would benefit a lot of other teams as well and that might need an Epic of some sort for Phabricator.

Maybe? I'm hoping the TPG's https://github.com/wikimedia/phab_task_history code could be wrangled to do some of this.... (haven't looked closely at all, it might be over-engineered for our use-case).

From our team meeting, we have a bunch of feature/enhancement requests which we know will take a while to respond to. We could potentially just track the maintenance / defect issues which are most probably flagged high / unbreak now priorities.

By restricting the metric to only the highest priority items, we might have a useful KPI to act on.

My point above still stand, that kind of metric would be useful for the whole organization and some utility could be written to generate them automatically for all team/projects.

greg triaged this task as Low priority.Aug 27 2015, 4:02 PM
greg set Security to None.

declining for now