You are here:

Development Responsiveness

Context tags: Community, Software, Ecosystem

Keywords: Model, Review Cycle, Pull Request, Issue, Defect, Bug

Why It Matters

Development responsiveness reflects a number of things relevant to the capacity of a project to operate and scale effectively. Responsiveness can reflect a project’s investment (including abandonment), capacity and can be indicative of engineering priorities, and at times bias towards certain types of interactions and people - responsiveness can reveal a lot, including things you weren’t looking for including how well bots are (or are not) working to solve common pain points.

User Stories

  • As a company or non-profit and individual I want to evaluate how well an upstream project is set up to respond to priority issues like security.
  • As a contributor, I want to evaluate whether or not a project is actively engaging with people.
  • As a community manager/maintainer I want to evaluate how well our project is responding in various capacities (issues, comments etc), and where possible compare to other projects who are similar or direct competitors.
  • As an OSPO manager (or someone in charge of OS standards at a company/institution/org), I want to identify inactive projects for possible archiving, or remedial/supplementary support.

Metrics in the Metrics Model

  • Review Cycle Duration within a Change Request
    • A change request is based on one or more review cycles. Within a review cycle, one or more reviewers can provide feedback on a proposed contribution. The duration of a review cycle, or the time between each new iteration of the contribution, is the basis of this metric.
  • Change Request Duration
    • The change request duration is the duration of the period since the change request started, to the moment it ended (by being accepted and being merged in the code base). This only applies to accepted change requests.
  • Issue Response Time
    • Issues are the central process of accepting code contributions. Matters of responsiveness can be traced to urgency, maintainer availability, timezone and other influencers but ultimately reflects the reliability, and scalability of a project. This metric is an indication of how much time passes between the opening of an issue and a response from other contributors.
  • Defect Resolution Duration
    • What is the median time between the report of a defect to the project (using the project’s defect reporting mechanism) and the time where the project resolves the defect? Note the resolution could be to address (resolve and merge) and make the update available to its users or explicitly choosing to not address (reject).

Contributors

  • Emma Irwin
  • Matt Germonprez
  • Yehui Wang

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

Was this article helpful?
Dislike 0