Sue Chaplain

FWIW I agree that we need to be sure the release branch has the appropriate changes. We tend to create the release branch just before we publish, so at that...

Yeah, I like (1) best. (2) is risky (3) will be a lot more. work because user doc changes typically come late so we'd be doing a lot of double...

>We should be creating PRs from the OpenJ9/extensions master/openj9 branches until we split a release branch. Then the doc updates should come from the release branches until the release is...

I think the idea of running it per change was that the developer could go check the docs to make sure the update was as expected. I don't have a...

We only create a release branch shortly before GA as there are usually last minute things to update. So if it is easier, we'd want PRs that apply to future...

In reality, Javadoc updates are few and far between, so in most cases, I think this will be fine.

@bharathappali - this issue is very old now and presumably you would need to rebase and resubmit your openj9 changes that relate to this doc item. I propose to close...

Hi @AlenBadel - please can you confirm whether any work is expected for this issue please. There is an open PR that I propose to close on the basis that...

Adam B has offered to set this up for us if we raise an issue in their queue. We should collect together all the specific strings we want to report...

Guess we would add this last one: ``` # Warn if MkDocs finds files in the nav that aren't in the docs dir warning /WARNING - Documentation file/ ```