The suggestion is for the Release Management team is the "least worst" (thanks, tonyb) place for the website manaagement to land. As Tony points out, this requires learning new tools and processes but the individuals working on the docs team currently have no intention to leave, and are around to help manage this from the SIG.
I'm personally fine with the release team taking this on, but it does seem like an odd fit. I think it would make a lot more sense for the Docs SIG to own the docs site than the release team.
Thierry has always drawn (one of) the distinction(s) between teams and SIGs as being that teams own tasks that are “part of” the thing we produce that we call OpenStack, while SIGs are less formally part of that input to that production process.
Updating the docs site every time we have a new release felt like it should be part of the formal process, and definitely not something we should leave to chance. The cadence made me think the release team could be a good home.
It’s 95% automated now, for what that’s worth. I imagine someone could automate the step of adding the new series pages, although I’m not sure what the trigger would be.
We could also look at other ways to build the site that don’t require any action each cycle, of course, including not updating it at all and only publishing docs out of master. That’s especially appealing if we don’t have anyone in the community willing and able to pick up the work.
This is a little different scope though, isn't it? Maybe I misunderstood the original proposal, but to me there seems to be a big difference between owning the task of configuring the site for the next release (which totally makes sense as a release team task) and owning the entire docs.openstack.org site.