Improve schedule instructions in the Foreman branching procedure

[ekohl]

We should provide the exact command to generate the initial schedule at the end of the branching procedure. We already have the date of branching there, so we can easily provide it. The dev start date should be BRANCHING + 1 day.

From there the instructions become a bit more fuzzy: you should look at the dates and see if there are conflicts. Conflicts can be February conferences (FOSDEM and cfgmgmtcamp) (if people involved will attend there). Red Hat timing may also be relevant. While Red Hat shouldn't drive the schedule, the current release team is entirely staffed by Red Hatters. The Red Hat company wide shutdown at the end of the year (between Christmas and New Year) does impact availability of people. Red Hat may also care about Red Hat Summit. It may be good to shift it a week earlier or later. This will never be a hard science.

[ianballou]

I think a comment that reminds the release owner to check that the date works would be enough to settle the conflict issue. We shouldn't have conflicts too often.

[Griffin-Sullivan]

I think this step in branching process should explicitly say BRANCHING + 1 day. Without that we are requiring new release owners to know how scheduling works.

Create a Foreman 3.9 Schedule and Planning post on Development/Releases using schedule with the dev start set to the 3.8 branching date + 1 day