[openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

Alexandra Settle a.settle at outlook.com
Thu Mar 2 14:29:07 UTC 2017

From: Anne Gentle <annegentle at justwriteclick.com>
Date: Thursday, March 2, 2017 at 2:16 PM
To: Alexandra Settle <a.settle at outlook.com>
Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>, "openstack-docs at lists.openstack.org" <openstack-docs at lists.openstack.org>
Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle <a.settle at outlook.com<mailto:a.settle at outlook.com>> wrote:
Hi everyone,

I would like to propose that we introduce a “Review documentation” period on the release schedule.

We would formulate it as a deadline, so that it fits in the schedule and making it coincide with the RC1 deadline.

For projects that are not following the milestones, we would translate this new inclusion literally, so if you would like your project to be documented at docs.o.o, then doc must be introduced and reviewed one month before the branch is cut.

I like this idea, and it can align certain docs with string freeze logically.

I think the docs that are governed with this set of rules should be scoped only to those that are synched with a release, namely the Configuration Reference, Networking Guide, and Install Guides. [1]

For reference, those are the guides that would best align with "common cycle with development milestones." [2]

Scope this proposal to the released guides, clarify which repo those will be in, who can review and merge, and precisely when the cutoff is, and you're onto something here. Plus, I can hear the translation teams cheering. :)

I completely agree with everything here :) my only question is, what do you mean by “clarify which repo those will be in”? I had no intention of moving documentation with this suggestion Install guides either in openstack-manuals or their own $project repos :)

Next question – since there doesn’t appear to be a huge ‘no don’t do the thing’ coming from the dev list at this point, how and where do we include this new release information? Here? https://docs.openstack.org/project-team-guide/release-management.html#release-1


1. https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation

2. https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones

In the last week since we released Ocata, it has become increasingly apparent that the documentation was not updated from the development side. We were not aware of a lot of new enhancements, features, or major bug fixes for certain projects. This means we have released with incorrect/out-of-date documentation. This is not only an unfortunately bad reflection on our team, but on the project teams themselves.

The new inclusion to the schedule may seem unnecessary, but a lot of people rely on this and the PTL drives milestones from this schedule.

From our side, I endeavor to ensure our release managers are working harder to ping and remind doc liaisons and PTLs to ensure the documentation is appropriately updated and working to ensure this does not happen in the future.



OpenStack-docs mailing list
OpenStack-docs at lists.openstack.org<mailto:OpenStack-docs at lists.openstack.org>


Read my blog: justwrite.click<https://justwriteclick.com>
Subscribe to Docs|Code: docslikecode.com<http://docslikecode.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170302/411665cc/attachment.html>

More information about the OpenStack-dev mailing list