DV-31
Excessive Comment Volume by Author
Discipline
Default severity: medium
ProcessMetricsQuality
What it detects
One changelog author accounts for a disproportionate share of comment events across the snapshot, or sprays many comments across many issues — a person-level signal of documentation overhead. Detected from comment event counts and author display names on changelog rows only; comment bodies are never read (N2).
Detection formula
FOR each author A in snapshot: author_comments = COUNT(comment events by A) team_comments = COUNT(all comment events) issues_touched = COUNT(DISTINCT issues where A commented) avg_per_issue = author_comments / max(1, issues_touched) IF author_comments >= config.discipline.author_comment_min_absolute // default: 20 AND author_comments / max(1, team_comments) > config.discipline.author_comment_share_warning // default: 0.35 THEN FLAG author_comment_dominance IF issues_touched >= config.discipline.author_comment_min_issues // default: 5 AND avg_per_issue >= config.discipline.author_comment_avg_per_issue // default: 6 THEN FLAG author_comment_spray Report: author, author_comments, team_comments, share, issues_touched, avg_per_issue, sample issue keysExamples in practice
- Assignee, field, hierarchy, or sprint hygiene rules are violated on active work.
- Issues miss mandatory fields or ownership while still in progress.
- A team shows one changelog author accounts for a disproportionate share of comment events across the snapshot, or sprays many comments across many issues while author comment min absolute is set to 20.
Suggested response
Enforce assignee, field, hierarchy, and sprint hygiene rules your team agreed on.
Coaching playbook
Symptom
One changelog author accounts for a disproportionate share of comment events across the snapshot, or sprays many comments across many issues — a person-level signal of documentation overhead. Detected from comment event counts and author display names on changelog rows only; comment bodies are never read (N2).
Why it matters
When "Excessive Comment Volume by Author" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.
What you can achieve
Enforce assignee, field, hierarchy, and sprint hygiene rules your team agreed on.
Facilitation questions
- What system change would stop "Excessive Comment Volume by Author" from firing again?
- What do the cited issues have in common — same root cause or same workaround?
- Who owns the two-week experiment and how will we verify on the next import?
Run this rule against your own tracker data with Flow Analyzer.