Repository navigation
[Feature Request] prior issues should assessed for closure or implementation #383
Description
Activity
Analysis
This request ("several issues are dated and should be either closed or implemented") doesn't name which issues, so I pulled the current open list to see what "dated" might mean here:
# Age Title 148 ~125d MASTER: Feature lock plan — BBQS v1.0 178 ~119d QA Checklist (tracking issue) 179 ~119d [QA] §1 — Sidebar collapsed state not persisted across refresh 180 ~119d [QA] §1 — Theme ignores prefers-color-scheme on first visit 182 ~114d [QA] §2 — Home hero renders two <h1>elements183 ~114d [QA] §2 — Pages fail to scrollToTop on card/chip click 185 ~114d [QA] §4 — Investigators page missing mobile card fallback 186 ~114d [QA] §4 — Investigator column headers don't reorder 187 ~112d [QA] §1 — Console errors on every page load, masked in CI 188 ~112d [QA] §8 — ~4/15 species cards fail to open summary panel 189 ~111d [QA] §13/§14/§17/§18 — inconsistent anon-route gating 194 ~94d [Feature Request] Additional field for projects 232 ~63d [Feature Request] person missing on People group 234 ~62d [Feature Request] set up calendar of upcoming conferences 235 ~59d [Feature Request] WG folder access 241–243 ~55d DB audit 🔴 #1–#3 (affiliation / provenance / embedding index consolidation) 283 ~37d Role identity has no single source of truth 306 ~30d EMBER-Vault tracker Why I'm not closing or implementing anything yet
Deciding "close vs. implement" for each of these requires judgment I don't have standing to exercise unilaterally:
- Several (148, 178) are tracking/master issues — closing them is a project-management call, not a code change.
- The QA items (179–189) are still-open findings against the live app; closing them without verifying each is fixed would hide real bugs, and several look like they'd need actual fixes (multi-file, some touching CSP/auth-route gating, which is Class-C territory).
- 241–243 and 283 are DB-audit items that explicitly touch schema/RLS/migrations — Class-C by this repo's own triage rules, not something to fold into a "close stale issues" pass.
- The feature requests (194, 232, 234, 235) each need their own scoping — "implement" isn't a single PR.
I don't have a specific list or criteria (e.g. "close anything untouched >90 days with no repro," or an explicit set of issue numbers) to apply mechanically, and bulk-closing other people's issues without that would be guessing.
Could you confirm one of:
- A specific list of issue numbers you want closed (and why — fixed already? no longer relevant?), or
- A criterion I can apply mechanically (e.g. age threshold + label), or
- Which single issue from the list above you'd like implemented first, so it can go through the normal spec/PR flow.
No code changes or PR from this run — there's nothing concrete yet to implement, and closing others' issues without explicit direction isn't something I'll do on a guess.
i am doing it manually
User Request
several issues are dated and should be either closed or implemented.
Submitted via BBQS Suggest a Feature