chorman0773
commented
8 months ago For the specific set of labels, I recommend adopting the same top-level set set that rust-lang/rust has with a few exceptions:
- Whether we need the O- labels is not clear to me - these can likely be omitted unless we get target-specific spec chapters.
- On my own repository for an ISA spec, I've used a trio of labels (I-unclear, I-spec-hole, and I-defect) to identify issues in the spec itself - I'd recommend adopting those labels
- I-unclear indicates wording in the spec that is unclear or can be interpreted (in context) in multiple ways - stuff that probably says the correct thing, but could also say something else
- I-spec-hole is for places in the spec that lack a rule (a Spec Hole). We wouldn't use this for entire missing chapters, otherwise we'd have a lot of I-spec-hole issues, but if a particular chapter is missing some rule, that would be a spec hole
- I-defect is for places that the spec is known to be incorrect or faulty in some way. This can be a case where the prescribed rule is not possible to implement, or it does not actually match what the language rule is.
It may be reasonable to automate these labels - for the lccc project, I wrote a tool that creates labels in this style, though the template repo would need to be forked to the rust-lang org (the tool updates repo labels via GHA CI), and then the data for it would need to be created. I am hesitant to recommend we use the tool over manual label creation for now, but it is an option for keeping the label list up to date.
JoelMarcey
I'd like to formally recommend that we adopt the semantic issue labels format used by the rest of the rust-lang org for labelling issues. It will probably be easier to migrate both labels and issues now while we have a limited set (vs. later when we have a few hundred), and the labels are fairly helpful in filtering things.
It would also make it easier to set up labeling from triagebot (I did that set up a bit ago for the unsafe-code-guidelines repo used by T-opsem), and allow contributors to more immediately identify information about the issue/PR. This can be useful particularily for PRs that touch the spec chapters, as making it easy for contributors to identify stylistic/maintenance changes vs. salient textual changes. With some work, it can also be useful to interface with the rest of the project, by raising potential issues in spec PRs to the relevant teams when something may be unclear (using standard labels like I-lang-nominated).