Our date filter used two qualifiers ("created:>START created:<=END"),
which isn't valid range syntax, so GitHub ignored it and returned every
open issue. Use a single "created:START..END" range. Also fix the window
math, which was a business day too recent and excluded its start day.
Release Notes:
- N/A
GitHub issue search can't express the one filter we want here: "created
at least one business day ago." That's the whole reason the project
board #\87 exists — since we can't save it as a search, we keep a
project's membership in sync to stand in for it.
So: an hourly workflow runs script/github-triage-queue-board.py, which
adds the open issues that fall in the eligibility window to project #\87
and removes the ones that have aged out. Also wires the workflow into
the community automation failure Slack alert, so if it breaks we hear
about it.
Release Notes:
- N/A
`priority:*` labels in the github repository are becoming `severity:*`,
and `frequency:*` — `reach:*`. This commit will update the slack
notifications for the first responders accordingly.
Also, delete the github-label-issues-to-triage.py one-off script, which
worked with the old label names and is by now too distant in the past to
be useful as reference or anything.
Release Notes:
- N/A
What looks like a single event of applying a few labels is actually
multiple events, and the raciness is racy as we've recently experienced.
One solution would've been adding a “first responders notified” label
for enforcing consistency but issues already have enough labels (and we
could take it off by mistake), so a bot reaction will instead serve as a
marker for any later runs.
So if we're applying multiple labels or changing our mind about, say, an
area label after the notification has already been sent, this should
work fine now, without duplicate notifications.
Release Notes:
- N/A
Automates the Guild contributor program on project board #74 so the
cohort is recognized and kept unblocked without manual babysitting.
- Move a board issue to In Progress when a Guild member self-assigns it,
and post a friendly heads-up when they are assigned an issue that is not
on the board.
- Flag when a Guild member opens a new PR while another of theirs is
still open, to help them land work before spreading thin.
- Check in on quiet assignments and, if an assignee stays silent, free
the issue back to a to-do column so others can pick it up; a "guild
hold" label lets maintainers pause check-ins after they have followed
up.
- Share a weekly digest of what the Guild shipped.
- Label PRs from Guild members and recognize a Guild contributor tier on
the community PR board.
Release Notes:
- N/A
Rather than continuing to try to persuade Claude to pretty please only
output json, or to parse json out of Claude's prose, switch to forced
tool calls with a json schema and hope this works better.
And bump the version of the bot to 4 since the model upgrade which was
shipped earlier today is evidently behaving differently enough.
Release Notes:
- N/A
The GitHub workflow was sometimes failing when someone edited the
already-merged PR that had been archived on the board because archived
items can't have their fields changed. The project board fields don't
need to be updated when the PR is already merged or closed.
Release Notes:
- N/A
claude-sonnet-4-20250514 was retired by Anthropic on June 15, 2026,
causing the "Comment on potential duplicate bug/crash reports" workflow
to fail with a 404 from /v1/messages on the first call_claude
invocation.
Switch to the recommended replacement, claude-sonnet-4-6.
Release Notes:
- N/A
For the ease of finding something that fits the time that reviewers have
and for making it mechanically easier to prioritize the PRs from the
community champions, surface some meta information on the PR board (and
make it updatable). Meta information here means things like size and
whether there's an issue linked to the PR (and what is its type if there
is).
Release Notes:
- N/A
We've been doing it manually when the stalebot keeps coming back to
deep-sitting bugs that we'll pretty much never fix accidentally / in
passing, now we're automating it: the stalebot will lay off the bugs
that have already gone through the cycle of “reported — stalebot asks to
confirm — the users confirm” once.
This might need to be complemented with a yearly sweep of the `never
stale` issues as a sanity check, but first we just shed the manual work.
Release Notes:
- N/A
To keep the area-to-track mapping up to date, notify the team whenever
someone creates a new `area:` or `platform:` label prompting them to
choose which Track it belongs to on the “Community PRs by area” board.
Release Notes:
- N/A
- don't fail to parse json when Claude ignores the instructions and
returns fenced json
- don't fail to search for issues by area labels when Claude ignores the
instructions and returns prose instead of comma-separated list
- don't mark workflow runs as successful when json parsing blew up or
posting the comment failed
Release Notes:
- N/A
In addition to the user-facing suggestions with potential duplicates,
the bot will now also have a separate collapsible block in the same
comment that's meant more for the triagers. This block will list the
duplicates we're less sure about as well as recently closed issues that
seem related to the issue at hand.
This commit updates the bot to V3 for the tracking-effectiveness
purposes and fixes some leftovers from the previous dupe bot change
(activating the bot for issues with no type).
It also improves the reliability of the script a bit, wrapping some
calls to the GitHub API into retries.
Release Notes:
- N/A
We regularly get a certain amount of 'blank' issues on github — those
created bypassing all our templates — and since a fair share of them are
bug reports, it would be helpful for the person triaging if the
duplicates bot has left suggestions on these issues too.
Release Notes:
- N/A
We shouldn't trigger this workflow on pull_request_review.submitted
because (1) two out of three possible cases here are already handled by
the build-in workflow automation of the project board itself, and (2)
this takes us into the territory of workflow runs that require approval.
Release Notes:
- N/A
The case of false negatives (“Missed opportunities”) was not considered
when the bot versioning was added. Now we're also automatically
attributing the false negatives to the bot version that made them.
Release Notes:
- N/A
Turns out you can't query the duplicate issue for the id of the
original/canonical issue, even though GitHub UI displays “Closed as
duplicate of <original issue id>”. Oh well. For the bot performance
tracking all that matters is whether any of its suggestions were the
actual originals, so we're working around the API limitation by querying
the suggested issues instead.
Release Notes:
- N/A
Obviously™, we add the bot-commented issues onto the tracking board at
the time of the issues getting closed, which is very much not the same
time as when the bot commented. We could very well be adding the issue
with a v1 bot comment to the board when v2 is already deployed. This
commit stops messing up those stats.
Release Notes:
- N/A
More precisely, the name of the GitHub project board in question is
“Closed bugs with new comments”, and since GitHub seems to do the
closing and the commenting separately (and, crucially for this
automation, in that order) when the closer uses the “Close with comment”
functionality, we want to skip the comments added within 30 seconds
after the closing.
Release Notes:
- N/A
Add a script that classifies open and closed issues that the duplicate
bot commented (or not commented) on and puts them into the appropriate
columns of the dedicated github project board. Add a workflow that calls
that script for every closed issue and also on a schedule (that's for
the open ones).
If you're reading this some time way later and there's no bot running
around the repository leaving comments like “This issue appears to be a
duplicate of...”, you can delete these files.
Release Notes:
- N/A
While the 60 days of inactivity works for a lot of the issues, with
other (more stubborn and popular) bugs it's too noisy to nag people
every eight weeks.
Also changing days-before-close after seeing a few cases of people
getting back to us after more than two weeks since the bot's question.
Release Notes:
- N/A
In combination with auto-labeling staff PRs, this makes it possible to
see the community PRs with `-label:staff -label:bot` in the search query
on https://github.com/zed-industries/zed/pulls
Release Notes:
- N/A
Modifying the existing github workflow here instead of adding a new one
because we're already triggering on the same thing (new PR opened) and
checking the same thing (staff team membership) but throwing away the
result. Another CI job doing largely the same checks seemed unnecessary.
Release Notes:
- N/A
This is still only a debugging/evaluation version (which is why it has
e.g. hardcoded stuff). It successfully ran a few times triggered
manually, so we're replacing the broken version on `main` with this to
see how it fares on incoming issues.
Release Notes:
- N/A
Sometimes github issues are created without following the template, and
if they don't receive the `state:needs triage` label from a template,
it's easy for us to miss them. Well, not anymore, thanks to this new
github workflow.
As an extra measure, the label is also added on reopened issues. All of
this only applies only to actions carried out by people outside of the
staff team.
Release Notes:
- N/A
Remove the attempts to have these issues land in the same 'inbox' (the
existing project board for triage). Since they're closed, the automated
workflow of the project board will move them to the 'Closed'
column/status even with the API call specifically moving them to
'Incoming' instead. It is what it is, we'll have a separate project
board for this.
Also:
- don't look at comments on PRs
- don't freak out if the issue has no type
- add a permissions block as a defensive measure (in case someone adds
secrets.GITHUB_TOKEN later)
- add a timeout to avoid hanging out for six hours or whatever the
default is
- add some logging.
Release Notes:
- N/A
Since the project board to which the closed bugs with new comments are
added might have an automated workflow for moving closed issues to the
"Done" status, we need to override the status to ensure the bugs are
actually surfaced to the team and not buried in "Done".
Release Notes:
- N/A
Sometimes bugs come back or are not fixed all the way. We want to
preserve the context of the issue we've closed prematurely so instead of
always making people open a new github issue in this case we want to be
able to notice if someone* comments on a closed bug and decide what to
do about it.
Before:
Bug is closed → A user can again/still reproduce it on a new version and
leaves a comment → Maybe someone sees the notification about it, maybe
not; maybe they see it but forget to act on it right away and it's lost.
After:
Bug is closed → A user can again/still reproduce it on a new version and
leaves a comment → The issue is added to a project board where it's
visible until someone makes a call about it (maybe the comment was “oh
my glob i'm so happy this was fixed” and no action is needed, or maybe
the issue must be reopened as a regression).
*Someone in this case means (1) not a bot, (2) not a member of staff.
Release Notes:
- N/A
- adjust wording for the upcoming simplified process
- upgrade to the github action version that has a fix for configuring issue types the bot should look at
- add two inputs for the manual runs of stalebot that help testing it in a safe and controlled manner
Release Notes:
- N/A
- shorten some phrases to (hopefully) retain attention better
- move the required field up to not bore people with scrolling
- call it a bug and not an issue to further emphasize we want feature
requests in Discussions where the product managers are
- remove the default from the WSL question since not everyone does
WSL or even Windows
Release Notes:
- N/A
---------
Co-authored-by: Miguel Raz Guzmán Macedo <miguel@zed.dev>
Co-authored-by: Kunall Banerjee <hey@kimchiii.space>
Delay the stalebot runs until the end of the year since it's currently
broken and leaves unhelpful comments on all the issues, including feature requests. Bad
bot. Allegedly this bug will soon be gone
https://github.com/actions/stale/issues/1302 but it's too much work
protecting issues from the bot until then.
Release Notes:
- N/A
- switch the bot from looking at the `bug/crash` labels which we don't
use anymore to the Bug/Crash issue types which we do use
- shorten the period of time after which a bug is suspected to be stale
(with our pace they can indeed be outdated in 60 days)
- extend the grace period for someone to come around and say nope, this
problem still exists (people might be away for a couple of weeks).
Release Notes:
- N/A
Lena