Adding a 'notable' tag to rust-lang/rust for PRs


@bstrie made this suggestion earlier to solve a few problems: creating both release notes and twir requires trawling pull requests (among other things) for notable events. This work is tedious. If we added a ‘notable’ tag that people could use to tag PR’s it might ease the process. Thoughts?


Who would have final say over whether a PR is “notable”? I can foresee over- and under-use. Apart from that, it seems like a good idea.


Anything that constitutes a change or addition that would be marked in TWiR, I guess.

Theres a lot of PRs that are just ‘fix one single typo’, which can be really tedious to trawl through (as Brson mentions) so this could be nice.

+1 Sounds like a good idea.


So the PR author or core team members add the mark. Yes, that does sound like it will reduce the search space considerably. If this leaves you more time to hack on Rust, I’m all for it :smile:


We’d also talked about asking such PRs to actually include an update to the release notes. (By and large, this would be for stabilization PRs and perhaps perf improvements). That would be more direct but needs more work from the author.

If we do go with a tag, I’d suggest relnotes rather than notable, to make the intent more clear.

In any case, collecting this info in some more incremental way sounds great to me.


I think we can be pretty liberal about the tag since it’s just advisory. Also, yes, if we can further ask PR authors to write relnotes themselves that is great, but the simple tag has the lowest barrier to entry and still helps.


I went ahead and added a ‘relnotes’ tag and tagged a PR.


Quick thought: consider something in the repo itself in case the project migrates away from GitHub. A standard relnotes line in the commit message, or something with git-notes.


@kamalmarhubi That’s a good point. It’s harder to get the note into the commit though since it requires asking the author for an update. The tag can be applied in a drive-by, even after the patch has landed.


Makes sense. Comes down to how much structure you want to impose on contributions. The git-notes approach would allow adding the flag after the fact. Of course, if you are going with the GH tag now, you could always have a script use the API to add it later.