Skip to content

Analyzing Issues

Carlos Paradis edited this page Dec 22, 2020 · 1 revision

1. Issues

Developers create issue ids to identify and manage new requirements, new features, or required changes in the existing codebase. The developer community can use the built-in Issues feature of Github or employ an external issue tracker. To track if an issue is addressed, developers annotate associated commits with existing issue ids which can be found in gitlog.

2. Issue id formats

The format of the issues may change from project to project depending on the community choices. The following is a community effort list of hash tags used in their respective projects. Note this does not mean the project only uses this pattern. You can manually inspect commit messages, and then use Kaiaulu to assess their coverage (i.e. how many issues including the label).

3. Legacy Issue IDs per Project

The following table is legacy. They should eventually be moved to project configuration files and versioned in the repo.

  • Mostly reliable: Most of the time developers consistently tagged the commits with the issueid format
  • Partial: Some of the commits are tagged with the issueid format
  • Unreliable: No or ambiguous formats are used for issueid.
MOSTLY RELIABLE
Project name Issueid format
APR APR-\d+
Audacity Bug\s\d+
Cassandra CASSANDRA-\d+
Cayenne CAY-\d+
Django #\d+
Gnome shell #\d+
Jackrabbit JCR-\d+
Jena JENA-\d+
Mahout MAHOUT-\d+
Pig PIG-\d+
PARTIAL
Project name Issueid format
Ffmpeg CVE-\d+-\d+
libuv #\d+
UNRELIABLE
Project name Issueid format
Arduino #\d+
Bitcoin #\d+
Enlightenment #\d+
Git #\d+
Grub fix#
Gstreamer #\d+
ipython #\d+
libva #\d+
matplotlib #\d+
NetworkManager #\d+
nginx fixed#
Okular #\d+
OpenSSL #\d+
Salt #\d+
Sympy #\d+
Tomcat #\d+
Clone this wiki locally