[Feature] Measure how long ordinary issues stay open, not just security reports #537

New issue

Closed

opened 2026-07-22 11:21:22 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 11:21:22 +00:00

Owner

Problem / motivation

We measure how long security reports stay open (tool/check_service_norms.dart: 5 working days to first response, 10 to a verdict, 90 to a resolution). Nothing measures ordinary issues.

An issue sitting untouched for months is not a security problem, but it is a quality signal — and for someone reporting a bug from outside, it is the first thing they see. #150 was answered the day it arrived; nothing tells us whether that is typical or lucky.

This came out of the CRA position decision (#519): the Regulation is a guideline here, not an obligation, and the part of it worth borrowing is "handle things without undue delay" — which you cannot borrow without knowing your own numbers.

Proposed solution

Extend check_service_norms.dart, or add a sibling, to report on the ordinary tracker:

age of each open issue, and the oldest;
time to first response, per issue;
how many are open with no response at all — the number that matters most;
issues labelled triage that never moved on.

Advisory, not a gate. A hard failure here would fire on a quiet week and teach people to ignore it. The value is the number being visible and dated, not a red build. --advisory already exists in that tool for exactly this.

Marp / file-format impact

None.

Alternatives considered

Setting deadlines for ordinary issues, as exist for security reports — rejected: a self-imposed deadline you miss on a hobby week is a promise turned into a stick. Measure first, decide on norms once there is a baseline.

**Problem / motivation** We measure how long *security* reports stay open (`tool/check_service_norms.dart`: 5 working days to first response, 10 to a verdict, 90 to a resolution). Nothing measures ordinary issues. An issue sitting untouched for months is not a security problem, but it is a quality signal — and for someone reporting a bug from outside, it is the *first* thing they see. #150 was answered the day it arrived; nothing tells us whether that is typical or lucky. This came out of the CRA position decision (#519): the Regulation is a guideline here, not an obligation, and the part of it worth borrowing is "handle things without undue delay" — which you cannot borrow without knowing your own numbers. **Proposed solution** Extend `check_service_norms.dart`, or add a sibling, to report on the ordinary tracker: - age of each open issue, and the oldest; - time to first response, per issue; - how many are open with no response at all — the number that matters most; - issues labelled `triage` that never moved on. **Advisory, not a gate.** A hard failure here would fire on a quiet week and teach people to ignore it. The value is the number being visible and dated, not a red build. `--advisory` already exists in that tool for exactly this. **Marp / file-format impact** None. **Alternatives considered** Setting deadlines for ordinary issues, as exist for security reports — rejected: a self-imposed deadline you miss on a hobby week is a promise turned into a stick. Measure first, decide on norms once there is a baseline.

brenno added the

accepted

enhancement

labels

2026-07-22 11:21:22 +00:00

brenno referenced this issue from a pull request that will close it,

2026-07-22 13:53:11 +00:00

feat: meet doorlooptijd, ratchetbeweging en of de documentatie klopt #558

brenno referenced this issue from a commit

2026-07-22 13:53:13 +00:00

chore(meting): geef de doorlooptijdmeting een doel en een plek

brenno closed this issue