I just changed branch settings on my GitHub repository, so that my [next] branch requires a passing CI build through a pull request.
A discussion followed with a number of team members, about failing tests.
For context's sake...
The repository has a [master] branch that's only PR'd into when there's a release, so [master] contains the code as of the last release, regardless of whether it's a major, a minor, a hotfix, a beta, alpha / pre-release build.
The [next] branch is the "default" one, where we intend to keep "release-ready" code; technically that branch could be PR'd into [master] any time, and released.
Individual forks have their own dev branches, and contributors PR to [next].
When I review a non-trivial PR, I'll merge the contributor's dev branch into my "review" branch, and if I see things I can fix quickly I'll commit/push changes and new (sometimes failing) tests, and PR back into the contributor's dev branch; when they merge my changes in, make the new failing tests pass, and then push, their PR synchronizes, and then I'll merge the PR into [next].
But this question isn't about passing tests, it's about the failing ones.
Failing tests document what needs to be fixed.
Known bugs should have tests written for, so that we know what's not working.
A failing build on [next] would mean that we're not release-ready... but then "being release-ready" is a bit like "being ready" to have kids - you're never quite ready for this, and something, somewhere (of variable importance) will inevitably go wrong with the release.
So we're only ever pushing passing tests to [next]. Where to push failing tests then? I mean, outside the PR/review process?
For example, a user reports a new bug in the issues list, and I'd like to write a failing test suite for it - so as to specify what needs to be done and where, which makes it easier for new contributors to pick up and eventually PR a fix.
Where should I be pushing these failing tests? Or is it even a good idea to push failing tests anywhere?