In the jupyterhub organization I've often ended up labelling PRs with a ci label and/or prefixed the title with ci, to then list such PRs under Continuous integration improvements.
I think there is a point of distinguishing this category from the maintenance category, because we quite often need to make changes to .github/workflows/test.yaml or similar, but they are often not relevant to think about like another maintenance PR touching the actual code of the project.
I often find myself reading changelogs list of PRs to find what could possibly have caused a bug I'm observing, but the bugs shouldn't have been caused by a CI change typically, so if they are listed separately that is helpful for example.
In the jupyterhub organization I've often ended up labelling PRs with a
ci
label and/or prefixed the title withci
, to then list such PRs underContinuous integration improvements
.I think there is a point of distinguishing this category from the maintenance category, because we quite often need to make changes to .github/workflows/test.yaml or similar, but they are often not relevant to think about like another maintenance PR touching the actual code of the project.
I often find myself reading changelogs list of PRs to find what could possibly have caused a bug I'm observing, but the bugs shouldn't have been caused by a CI change typically, so if they are listed separately that is helpful for example.