Issue Tracking Ecosystem

• Issue Tracking Ecosystem is a framework that combines central issue tracking systems with related software artifacts and stakeholder interactions to ensure detailed traceability.
• It addresses challenges like ambiguous issue descriptions, bloated workflows, and inconsistent practices by linking internal and external artifacts effectively.
• Automated algorithms operationalize best practices, enabling continuous monitoring and evidence-based improvements in software engineering processes.

An Issue Tracking Ecosystem (ITE) is the aggregate of an organization's central Issue Tracking System (ITS) and all related software engineering artifacts, stakeholders, and processes, emphasizing the contextual interactions between the ITS and its surrounding environment. ITEs support the management of requirements, development tasks, maintenance activities, and their evolution, linking issues internally and externally to other tools and artifacts, thus providing essential documentation and traceability for software engineering organizations (2507.06704).

1. Defining ITEs: Scope and Structure

An ITE is defined as the combination of the ITS (e.g., GitHub Issues, Jira), the software engineering (SE) artifacts it manages (requirements, tasks, bug reports), all linked objects (commits, test cases, releases), the workflows they traverse, and the various stakeholders engaged throughout their lifecycles (2507.06704). The ecosystem view explicitly extends beyond the capabilities of a standalone ITS by:

• Integrating internal links (issue-issue, issue-commit) and external links (to documentation, code, or external trackers).
• Enabling forwards and backwards traceability, such as linking feature requests to sprint releases and bug reports to code changes.
• Accommodating multiple and diverse workflows, attribute schemas, and project-specific customizations (2507.06704).

The context in which the ITS operates—including organizational processes, project conventions, and stakeholder expectations—is fundamental to both its effectiveness and its quality (2507.06704).

2. Challenges and Complexities in ITEs

Practitioner interviews and large-scale archival analyses reveal that ITEs are characterized by considerable complexity, arising from both information and process factors (2507.06704):

• Information Challenges: Incomplete or ambiguous descriptions; information overload resulting in “zombie” issues (unaddressed, lingering tickets); difficulty in searching and maintaining an overview when issues multiply into the thousands or millions (2403.05716).
• Workflow Challenges: Overly complex or "bloated" workflows, insufficient enforcement or support of desired processes, and misalignment between the ITS workflow engine and actual team practices, often resulting in workaround behaviors (2507.06704).
• Organizational Challenges: Discipline in usage varies across teams; scoping and triaging inconsistencies can manifest as divergent tracking needs or inadequate assignment/ownership; coordination becomes increasingly hard with scale and team heterogeneity (2507.06704).
• The evolution patterns of issues and workflows also differ substantially across projects and artifact types. For example, content fields such as summary and description typically change only within the first few hours after issue creation, while structural attributes (e.g., repository, component) may evolve over a much longer period (2507.06704, 2201.08368).

These complexities substantiate the importance of context in both the assessment and improvement of ITE quality (2507.06704).

3. Artifact Diversity, Activities, and Evolution

Archival analysis of over 1.3 million issues and 13 million evolution events across public Jira repositories demonstrates substantial heterogeneity in ITEs (2507.06704, 2201.08368):

• Artifact Types: Issues are grouped into requirements (epics, user stories, features), development tasks (implementation, code reviews), and maintenance artifacts (bug reports, incident handling) (2507.06704).
• Evolution Patterns: Median issue undergoes about eight revisions, but this varies widely by field and information type. For instance, requirements are frequently updated by non-owners, whereas some maintenance properties (such as environment fields) are often left blank (>90% absent in many projects) (2507.06704).
• Stakeholder Involvement: “Owner-based” practices (e.g., initial assignee for an issue) are largely respected, but field-level evolution often involves contributions from other roles, highlighting the collaborative dimension of the ecosystem (2507.06704).

These findings highlight the importance of considering not only the static structure but also the temporal dynamics and stakeholder interactions when assessing ITEs.

4. Best Practice Ontology and Catalogue

To address the limitations of piecemeal “smell” detection and uncoordinated improvement suggestions, a structured ontology for ITE Best Practices was developed (2507.06704):

• The ontology consists of five primary components:
  • Meta: Name and provenance of the practice.
  • Summary: Objective and motivation for the practice.
  • Recommendation: Detailed guidelines, both procedural and tool-specific.
  • Context: Stakeholder benefits/costs, ITS scope, issue types, inclusion/exclusion criteria.
  • Violation: Description of smells, negative impacts, likely causes, and often detection pseudocode (2507.06704).

This framework explicitly captures the contextual dependencies of best practices, making them more adaptable and falsifiable. The resulting catalogue comprises 40 best practices, grouped into domains such as issue properties (e.g., “Good Bug Report”, “Consistent Properties”), issue linking, and process adherence (e.g., assigning bugs to individuals, resolving severe bugs in a timely manner) (2507.06704).

5. Algorithmic Detection and Empirical Assessment

A significant contribution of the research is the demonstration that many best practices can be operationalized and monitored using automated algorithms:

• Algorithmic Checks: Algorithms were developed for twelve bug report–related best practices and more for general issue types (2507.06704). Examples include verifying that resolved bugs have non-empty assignee fields and checking for timely resolution of severe bugs (often within a set window, such as seven days).
• Empirical Findings: Application of these tools across the studied dataset revealed, for example, that roughly 9% of bug reports lacked an assignee and that failure to set the “environment” field is common (over 90% in certain projects) (2507.06704).
• Variation Across Contexts: Adherence to best practices—and the significance of their violation—was found to be highly context-dependent, reinforcing the argument for situational, not one-size-fits-all, improvement approaches.

This empirical basis supports the practical utility of the ontology and catalogue.

6. Implications and Future Directions

The adoption of a context- and ontology-based approach to ITE improvement carries several key implications:

• Comparative Research: The ontology enables like-for-like comparison of findings and practices across projects and organizations, facilitating systematic research synthesis (2507.06704).
• Tool Development: Automated, user-configurable tools can monitor best practice adherence, provide early warnings on quality decline, and assist with adaptive workflow refinement.
• Tailored Practices: The context dimensions in the ontology allow organizations to define, monitor, and adapt improvement goals to their specific needs and constraints.
• Continuous Improvement: Systematic measurement of best practice adherence (and the associated “smell severity”) provides a foundation for evidence-based process improvement and ITS policy design (2507.06704).

Planned future work includes refining best practices through additional empirical evaluation and expanding support for adaptive, automated ITE monitoring tools that can be tailored to specific organizational contexts (2507.06704).

7. Summary Table: Selected Best Practice Examples from the Catalogue

Best Practice Name	Description	Frequent Violation Severity
Assign Bugs to Individuals	Each resolved bug should have a clearly designated assignee	About 9% of bugs violate, varies by project
Timely Severe Issue Resolution	Severe bugs should be resolved within an empirically defined window (e.g., 7 days)	Project- and context-dependent
Set Environment Field	Bugs should indicate the environment in which they were observed	Often >90% missing

Only a subset is shown; the full catalogue encompasses 40 best practices, each tightly linked to its relevant context and measurable consequences (2507.06704).

---

In sum, research on Issue Tracking Ecosystems highlights their complexity, context dependence, and critical role in software engineering success. By structuring improvement activities through an ontology and catalogue of best practices—measured and monitored with automated algorithms—organizations and researchers now have a foundation for systematic, context-aware quality enhancement within modern ITEs (2507.06704).