Issues New
Question: How many new issues are created during a certain period?
Overview
Issues New measures the number of new issues created within a specified period. Each of these tickets (issues) are opened (submitted) by a certain person, and are later commented and annotated by many others. Depending on the issue system considered, an issue can go through several states (for example, "triaged", "working", "fixed", "won't fix"), or being tagged with one or more tags, or be assigned to one or more persons. But in any issue tracking system, an issue is usually a collection of comments and state changes, maybe with other annotations. Issues can also be, in some systems, associated with milestones, branches, epics or stories. In some cases, some of these are also issues themselves. Data points consist of the count of issues that were initially opened or submitted during the measurement period. Issues can be reopened after being closed. Reopening an issue can be considered as opening a new issue (see parameters, below). For example, "issues" correspond to "issues" in the case of GitHub, GitLab or Jira, to "bug reports" in the case of Bugzilla, and to "issues" or "tickets" in other systems. Tracking issues provide insights into project activity and engagement. A high volume of new issues indicates an active community discussing problems, proposing solutions, and contributing to project development. Issues New monitors the level of ongoing discussion and engagement too. Analyzing the types of issues being created can provide insights into potential areas where DEI efforts may be needed to address specific concerns to participation.
Want to Know More?
Data Collection Strategies
Specific description: GitHub
In the case of GitHub, an issue is defined as an "issue".
The date of the issue can be defined (for considering it in a period or not) as the date in which the issue was opened (submitted).
Specific description: GitLab
In the case of GitHub, an issue is defined as an "issue".
The date of the issue can be defined (for considering it in a period or not) as the date in which the issue was opened (submitted).
Specific description: Jira
In the case of Jira, an issue is defined as an "issue".
The date of the issue can be defined (for considering it in a period or not) as the date in which the issue was opened (submitted).
Specific description: Bugzilla
In the case of Bugzilla, an issue is defined as a "bug report", as long as it is related to source code files.
The date of the issue can be defined (for considering it in a period or not) as the date in which the bug report was opened (submitted).
Aggregators:
- Count. Total number of new issues during the period.
- Ratio. Ratio of new issues over total number of issues during that period.
Parameters:
-
Period of time. Start and finish date of the period during which issues are considered. Default: forever.
-
Criterion for source code. Algorithm. Default: all issues are related to source code.\ If we focus on source code, we need a criterion for deciding whether an issue is related to the source code or not.
- Reopen as new. Boolean. Default: False.\ Criterion for defining whether reopened issues are considered as new issues.
Filters
- By actors (submitter, commenter, closer). Requires merging identities corresponding to the same author.
- By groups of actors (employer, gender... for each of the actors). Requires actor grouping, and likely, actor merging.
Visualizations
- Count per time period over time
- Ratio per time period over time
These could be grouped by applying the filters defined above. These could be represented as bar charts, with time running in the X axis. Each bar would represent proposals to change the code during a certain period (eg, a month).
Contributors
- Georg J.P. Link
- Dawn Foster
- 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=3587
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.