You are here:

Time to Close

Question: How much time passes between creating and closing an operation such as an issue, change request, or support ticket?

Overview

Time to Close measures the duration between the creation and closure of operations such as issues, change requests, or support tickets. The operation needs to have an open and closed state, as is often the case in code review processes, question and answer forums, and ticketing systems; a related metric includes Issue Resolution Duration. Data points are calculated by subtracting the creation date from the closure date for each completed operation. Time to Close helps determine how responsive a community is, which can aid efforts to be inclusive, attract, retain new and existing contributors. It also helps identify characteristics of operations that affect the speed of closure, such as finding best practices, identifying areas for improvement, and assessing efficiency. It can help identify biases in timely responses to different community members, detect changes in community activity (like maintainer burnout or reduced diversity of contributions).

Want to Know More?

Click to read more about this metric.

Data Collection Strategies

The time to close metric may be contextual based on the project activity and objectives. For example, the time to close a bug report may provide different information than the time to close a new feature request. Data collection strategies should address different project objectives. Other variables that may influence these processes are:

  • Issue Tracking Systems: the type of issue such as bug report, blueprint (OpenStack nomenclature), user story, feature request, epic, and others may influence how long this event takes to be closed. Other variables, such as the priority or severity may help to advance how quickly this event will be closed.
  • Change Request Processes: this depends on the change request infrastructure, as Gerrit, GitHub or mailing lists (as in the Linux Kernel) and may differ depending on how complicated the process is. For example, newcomers or advanced and experienced developers will proceed in different ways and with more or less time required.
  • Question and Answer Forum: this depends on the quality of the answer and the opinion of the person asking the question. A valid answer is marked, and the process is closed once the person questioning has successfully found a correct answer to their question.

Filters

  • Creator of operation (e.g., new contributor vs. maintainer)
  • First closed, final closed
  • Labels (e.g., bug vs. new feature)
  • Change Request Merge Status (e.g. Time to Merge or Time to Close without Merge)

Visualizations

GrimoureLab Average and median time to close an Issue from GrimoireLab


References

Contributors

  • Matt Germonprez

  • Kevin Lumbard

  • Peculiar C. Umeh

Additional Information

To edit this metric please submit a Change Request here

To reference this metric in software or publications please use this stable URL: https://chaoss.community/?p=3446

The usage and dissemination of health metrics may lead to privacy violations. Organizations may be exposed to risks. These risks may flow from compliance with the GDPR in the EU, with state law in the US, or with other laws. There may also be contractual risks flowing from terms of service for data providers such as GitHub and GitLab. The usage of metrics must be examined for risk and potential data ethics problems. Please see CHAOSS Data Ethics document for additional guidance.

Tags:
Was this article helpful?
Dislike 0