[Paper] Smells Depend on the Context: An Interview Study of Issue Tracking Problems and Smells in Practice
Source: arXiv - 2601.04124v1
Overview
The paper “Smells Depend on the Context: An Interview Study of Issue Tracking Problems and Smells in Practice” dives into the day‑to‑day pain points that developers and managers face when using Issue Tracking Systems (ITSs) such as Jira, GitHub Issues, or Azure DevOps. By interviewing 26 seasoned practitioners across different companies, the authors reveal which “smells” (questionable practices) actually hinder work and how context—team size, workflow stage, and ITS configuration—shapes their impact.
Key Contributions
- Empirical grounding of ITS “smells” – Validates 31 smells from prior literature against real‑world practitioner experience.
- Identification of 14 recurring problems – Includes issue findability, “zombie” issues, workflow bloat, and weak enforcement of processes.
- Context‑sensitivity model – Shows that the severity of a smell depends on factors such as project scale, custom fields, and stage of the development lifecycle.
- Tooling roadmap – Proposes concrete ideas for configurable detection, monitoring, and visualization of ITS smells.
- Methodological blueprint – Demonstrates how thematic analysis of semi‑structured interviews can uncover nuanced workflow challenges beyond what log mining alone can reveal.
Methodology
- Participant recruitment – 26 experienced software engineers, product owners, and QA leads from a mix of startups, mid‑size firms, and large enterprises.
- Semi‑structured interviews – Each interview covered two parts: (a) open‑ended discussion of general ITS frustrations, and (b) rating of 31 pre‑identified ITS smells (e.g., “empty priority field”, “over‑labeling”).
- Thematic analysis – Researchers coded interview transcripts, iteratively grouping statements into themes until saturation was reached.
- Cross‑validation – Findings were triangulated with the participants’ own ITS configurations to ensure that reported smells aligned with actual system settings.
The approach is deliberately developer‑friendly: rather than mining massive issue logs, the study leans on conversation, making the results directly relatable to everyday workflow decisions.
Results & Findings
| Theme / Smell | What the study found | Practical meaning |
|---|---|---|
| Issue Findability | Search queries often return irrelevant or outdated tickets; missing tags exacerbate the problem. | Developers waste time locating the right issue, leading to duplicated work. |
| Zombie Issues | Issues that linger in “open” status long after the problem is solved, often because the workflow lacks a closure trigger. | Inflates backlog metrics and creates confusion about what still needs attention. |
| Workflow Bloat | Over‑customized workflows (many statuses, transitions, required fields) slow down issue creation and updates. | Teams spend more time navigating the ITS than writing code. |
| Lack of Enforcement | Required fields (e.g., priority, component) are often left empty or bypassed via bulk edits. | Reduces the usefulness of automated triage and reporting tools. |
| Context‑Dependent Smells | Some smells (e.g., “empty description”) are harmless in small teams with informal communication but problematic in large, distributed teams. | One‑size‑fits‑all policies for ITS hygiene are ineffective. |
Overall, only about half of the 31 literature‑derived smells were deemed problematic by practitioners; the rest were either absent (due to configuration) or benign in the given context.
Practical Implications
- Tailor ITS policies to team size and distribution – Small, co‑located squads can relax certain field requirements, while larger, remote teams should enforce stricter metadata (priority, component).
- Automate “closure hygiene” – Set up rules that automatically transition issues to a “Done” or “Closed” state after a pull‑request merge, reducing zombie tickets.
- Simplify workflows – Audit custom status flows and required fields; eliminate rarely‑used steps to cut friction in issue creation.
- Invest in searchable metadata – Adopt a consistent labeling/tagging strategy and enable full‑text search extensions to improve findability.
- Implement smell‑monitoring dashboards – Use the paper’s tooling suggestions (e.g., configurable linting plugins for Jira or GitHub) to surface problematic patterns in real time, allowing teams to react before issues pile up.
- Continuous feedback loop – Periodically interview team members about ITS pain points; the qualitative approach proved more revealing than pure metric analysis.
For developers, the takeaway is clear: the health of your issue tracker is as much a product of process design as it is of tooling. Small adjustments—like enforcing a priority field or pruning unused statuses—can yield measurable productivity gains.
Limitations & Future Work
- Sample bias – Participants were self‑selected and may represent teams already interested in process improvement, limiting generalizability to all organizations.
- Tool focus – The study centered on generic ITS concepts; platform‑specific quirks (e.g., GitHub Projects vs. Jira) were not dissected in depth.
- Static snapshot – Interviews captured a single point in time; longitudinal studies could reveal how smells evolve as teams scale or adopt new practices.
Future research directions suggested by the authors include: building automated smell detection plugins for popular ITS platforms, conducting large‑scale surveys to validate the context‑sensitivity model, and exploring the impact of ITS smells on downstream metrics such as release frequency and defect leakage.
Authors
- Lloyd Montgomery
- Clara Lüders
- Christian Rahe
- Walid Maalej
Paper Information
- arXiv ID: 2601.04124v1
- Categories: cs.SE
- Published: January 7, 2026
- PDF: Download PDF