@fjmolinas, @aabadie what is the consensus of your discussion in #13040 about backporting documentation PRs? Personally, I think it doesn't hurt and it even improves the case that a user builds the doc on his own.

it even improves the case that a user builds the doc on his own.

which is very unlikely to happen...

which is very unlikely to happen...

Not really, a lot of documentation is markdown. I never check that online. And it is the case here.

Not really, a lot of documentation is markdown. I never check that online. And it is the case here.

I do not build it, but I do not check it online either.

@fjmolinas, as a core maintainer, are you that often reading documentation on the release branch instead of master ? Because this is what backporting is about.

backporting documentation PRs

The idea is to backport "fixes", not "missing features". We did backport fixes to mistakes in docs (during hard freeze). We did not so far backport PRs adding missing documentation.

But IMO, this is @fjmolinas's call, he's managing the release, and this is not something outrageously against our conventions. It just means more work within the release process.

In this release we started the process of this new feature, but the release itself would not contain any explanation nor usage guides without this backport. I totally understand what @aabadie points out, that the latest docs are always online. But the release should be self-contained in this matter, take for instance someone who gets the .zip version of the release.

It just means more work within the release process.

What's the extra work for adding this docs?

In any case, I'm OK with whatever @fjmolinas thinks is best here.

Finally, it was decided to not backport this one, so closing it.