Do you not read comments on closed issues or PRs (or discussions?) update your instructions

[Happypig375]

@Rafael-SOWNet an idea which will not be taken up for the foreseeable future is closed as not planned is the Future milestone. It is not a label nor closure. The wording should be clarified here, alongside milestone descriptions?

Also do a review of Labels. up-for-grabs is now archived (it makes little sense to leave some tasks undone to invite outside contributors now in the age of agentic development) Reorganize and make sure the labels left are ones you will actually use.

Originally posted by @Happypig375 in #1384 (comment)

[Happypig375]

Also maybe we don't want to have issue templates for Bug/Feature/Goal/Maintenance at all; blank issues let the agent triage properly where an outside person might frame a feature as a bug or otherwise. Though implementation or goal specification should still be allowed to start immediately after type assignment.

[Rafael-SOWNet]

Both corrections are in #1471: deferral is the Future milestone, stays open, not a label and not a closure — CONTRIBUTING.md and the working practice in AGENTS.md now say so. And the sweep rule: the comment endpoints are not filtered by state, so sweeping them by time from the last sweep (rather than listing open items, which is what I was doing) is what catches a comment on a merged PR or a closed issue. Your 16:49 comment on #1384 waited two hours because I was inside a measurement; the rule now says to read the sweep before picking up the next piece of work, not after finishing the current one.

Labels. Counts over all issues, open and closed:

label	issues	what I would do
Accepted	68	keep — it is the signal that a Feature may be implemented
Opinions wanted	35	keep — it is a request addressed to whoever reads it
Design document	11	keep — it says "this is a design, do not implement it yet", which the types do not
up-for-grabs	38	delete, with <easy>/<medium>/ up-for-grabs(15/15/5) andgood first issue` (12)
Area: Interactive	11	keep
Area: Docs/Wiki	4	keep
Area: F#, Area: C++	0 each	keep — the packages exist, and an issue in one of them needs the filter the day it is filed; they cost nothing while empty

That is five deletions and six kept. Deleting a label strips it from every issue that carries it and cannot be undone, so I have not run it: say go and I will, or name a different cut. If you would rather keep the record, the alternative is renaming up-for-grabs to something like Archived: up-for-grabs — it keeps the history searchable at the cost of a line in the label list.

Milestone descriptions read correctly to me as they stand, with one gap: Future says "All ideas that aren't just yet relevant, but maybe at time point will", which does not say that it is the deferral mechanism. I would make it "Deferred: ideas that are not relevant yet and are not closed for it. An issue waits here rather than being closed as not planned." Tell me and I will set it.

Templates. I think dropping all four is half right, and here is the counter-proposal. What the type templates do badly is exactly what you say: they ask an outside reporter to classify, and the person who hits a wrong answer files a Feature while the person who wants a function files a Bug. What they do well is ask for the three things a report is useless without — the input, the answer it gave, and the answer it should have given — and a blank issue asks for none of them. So: one template, no type: field, called something like "Report or propose something", with those prompts and nothing about classification; blank issues stay enabled beside it for everyone who does not want the prompts, and the type is assigned at triage, which is where the judgement belongs. That keeps the reports readable without making anyone guess a taxonomy. If you would rather have nothing at all, the cost is that the first round of every outside report becomes "what did you run, and what did you expect", which is a round-trip that a template avoids — but the agent can ask it, so it is a preference rather than a defect.

[Happypig375]

Your analysis looks fine to me. Another update to the instructions: this issue and #1469 should have triggered triage on your first response. Triage is not a separate pass - do it alongside your response to an untriaged issue (do PRs and discussions get their own triaging?)

[Rafael-SOWNet]

Taken, and both issues are triaged as of this reply rather than in a pass of their own: this one is Maintenance (instructions, labels and templates; no milestone, since process work is not release-bound — say the word if you would rather it sat in 2.6.0), and #1469 is a Goal in 3.0, which is where your "implementing these before v3" puts it. #1471 carries the rule: an untriaged issue is typed, milestoned and labelled by the reply that engages with it, because a separate pass is one more thing to forget and leaves the tracker wrong until it runs. The review suggestion is applied in the same push — the Not now label has no bearing on the milestone and the sentence no longer mentions it.

Do pull requests and discussions get their own triage? I would say no to both, for different reasons, and the rule in #1471 says so:

• A pull request already carries the issue it is Part of, and that issue has the type. Typing the PR writes the same fact twice and creates a way for the two to disagree — a Bug fixed by a PR somebody typed Maintenance because the diff is mostly tests. What a PR needs at triage time is the link, which the body gives, and a milestone only if the repository wants the release view to include unlinked work; the PR that has no issue is the self-contained one your Goal template already allows, and its Goal is named in the body.
• A discussion is triaged by the category it sits in — Q&A or Ideas — and that choice is made by whoever opens it. What it needs is an answer; an issue comes of it only if work did. Typing discussions would mean maintaining a second taxonomy for threads that mostly end in "yes, that is how it works".

The one case where that is not enough is a discussion that should have been an issue — a bug report filed as a question. There the answer is to file the typed issue, link it from the thread and answer both, which is what the redirection rule in AGENTS.md already says for issues that are really questions, in the other direction.

[Happypig375]

Condense the templates too, I think this is the remaining work of this issue.

[Rafael-SOWNet]

Both done in #1480.

One template, no kind: what you ran, what it did, what it should have done, and where that expectation comes from. Blank issues stay enabled beside it and the contact links still point questions and ideas at Discussions. AGENTS.md's triage rule now says why every issue arrives untriaged — the template asks for no kind, so the type is always the triager's to set.

Labels: twelve → seven. Deleted up-for-grabs, <easy>/<medium>/<hard> up-for-grabs and good first issue. Six open issues carried them and are now ordinary claimable work, by whoever opens a pull request: #283 (static analyzer), #321 (non-kernel functions), #500 (performance reporter), #505 (F# computation expressions), #534 (RefLinq), #542 (dependency warnings). Left: Accepted, Opinions wanted, Design document, and the four Area: * — Area: F# and Area: C++ carry nothing today, but the packages exist and an issue in one wants the filter the day it is filed; say if you would rather they went too.

One thing still yours: the Future milestone's description. It reads "All ideas that aren't just yet relevant, but maybe at time point will", which does not say that it is where deferral lives — the thing this issue started from. I would make it "Deferred: ideas that are not relevant yet. An issue waits here rather than being closed as not planned." I can set it; milestone descriptions are repository state rather than a file, so I have left it alone until you say.

[Happypig375]

Yes, you should change that description. Also if all other milestones are done pull issues from this milestone to plan new milestones

[Rafael-SOWNet]

Done. Future now reads: "Deferred: ideas that are not relevant yet. An issue waits here rather than being closed as not planned, and once every other milestone is done, the next milestones are planned by pulling issues from here." — your wording, with your second sentence folded in so the rule sits on the milestone it is about. It is in AGENTS.md too, in #1482. Today the condition is far off: 2.6.0 has 25 open, 2.7.0 17, 2.8 5, 3.0 28, 3.1 8.

Checking the milestones for this turned up something of mine left stale: AGENTS.md still said the epics sit on an Epics milestone and that a missing milestone marks an issue untriaged. You retired that milestone when the types came in (#1384) — #718, #1409 and #746 came off it on 2026-09-22 — and the section on types already says untriaged is a missing type, so the file contradicted itself. #1482 corrects both.

And this reply is nine hours late, which is the thing this issue was opened about. The sweep ran before the work and not again during it, and the work turned into a long debugging session on #1481. I have not changed the rule, because the rule is right and I did not follow it: sweep by time before each new measurement, not only before each new task.

🤖 Generated with Claude Code