I have some cultural/etiquette questions regarding the use of various github features in the compiler repo.
The first is "issue triage". when a bug is reported, it's usually automatically given the "triage needed" label. At the time of writing, there are 1164 open issues still awaiting triage.
From anecdotal observation, triaging seems to primarily be done by a small handful of people, which makes sense as it currently requires write access to the repo. But suppose you have the ability to "triage" and add labels – what principles should be applied to do this well? There are currently 485 different labels, and I've not found much in the way of an explanation of their taxonomy, how to use them effectively, or even what purpose(s) they're intended serve.
Of course, I have my own heuristics I've built up from observing others – if it's a bug in a particular part of the compiler, apply the label for that component; if it seems straightforward to fix, add a "good first issue" label; if it's an issue for a diagnostic that could be improved, use "Diagnostics QoI", etc.
So, I'm primarily wondering:
- What purpose does triaging issues and adding labels actually serve?
- How should one effectively triage issues in service to the answer to
1.?
Additionally, I was wondering whether there are automated tools we could use to produce likely candidate labels. I'm unfamiliar with prior art for such things, but I assume it exists, though whether it'd actually be useful or "worth it" is a separate question.
Next, a related question – what is the appropriate etiquette for assigning an issue to a contributor? Again, based on personal experience, I have a general sense for which people would likely know how to handle issues in certain areas, and of course the "code owners" file formalizes this to a certain extent. But, it's not really clear to me when it's appropriate to assign an issue to someone, or even if core contributors to the compiler repo use that functionality in any meaningful way.
Depending on the answers here, we can update the contributing docs with some additional info on these topics if that seems useful.
Lastly, on a more topical matter – LLM-based tools have drastically lowered the barrier-to-entry for opening plausible-looking fixes for various issues. IMO there's great potential upside here, but also some drawbacks. One particular dynamic I've noticed recently is that there are sometimes multiple semi-to-fully-automated-looking PRs opened for the same issue.
While this may not be that big of a deal, it made me wonder if adding some sort of directional guidance for these types of contributions would be valuable. For example, if I add an AGENTS.md file to the repo with these contents:
Etiquette:
- Do not open PRs for issues that were recently assigned to someone else
then when I prompted claude code with:
what would you say if i asked you to open a PR for issue https://github.com/swiftlang/swift/issues/87324?
I got this response:
That issue already has two open PRs (#87348 and #87486) targeting the same fix, so opening a third would likely be redundant and unwelcome to the maintainers.
If you still wanted to work on it, I'd suggest:
- Reviewing the existing PRs to see if they have gaps or issues
- Leaving review feedback on one of them instead
- Finding a different open issue to tackle
That said, if you wanted me to attempt the fix anyway (e.g., for learning purposes or if those PRs have significant problems), I could — but I'd flag this situation first and make sure you're going in with eyes open.
Want me to look at the existing PRs and assess their quality, or find a different issue to work on instead?
This is what I got with no such guidance
⏺ Here's what I would say:
---
This is a "good first issue" in the Swift compiler's diagnostics area. The ask is: when you write var int {} (a computed property with a keyword name and no type
annotation), the compiler emits an error but no fix-it suggesting a type placeholder like var int: <#Type#> {}.
My approach would be:
1. Investigate — find where the computed_property_missing_type diagnostic is emitted (likely in lib/Sema/ somewhere) and understand how other fix-its are attached to similar
diagnostics.
2. Implement — add a fix-it insertion for : <#Type#> after the property name at the right source location.
3. Write a test — add a test case in test/Constraints/ or test/diagnostics/ that uses // CHECK: fix-it to verify the fix-it is emitted.
4. Open the PR — targeting main, with the issue number in the description.
What I'd flag before starting:
- This is in a large open-source repo with its own contribution guidelines — I'd check CONTRIBUTING.md and make sure the fix follows their patterns.
- You'd need push access or a fork to actually open the PR. I can prepare the branch and code, but you'd push it.
Want me to actually investigate and implement the fix?
Does trying to encode repo etiquette & expectations for use of such automated tools seem useful? At the very least I imagine it would be a low-cost experiment we could try.