Open Stack

On Fri, Jul 12, 2013 at 8:17 AM, Steve Gordon <sgordon at redhat.com> wrote:

> ----- Original Message -----
> > From: "Anne Gentle" <annegentle at justwriteclick.com>
>
> >8-------->8-------->8-------->8-------->8-------->8
> > On Jul 11, 2013, at 9:16 AM, Shaun McCance <shaunm at gnome.org> wrote:
> >
> > > On Wed, 2013-07-10 at 15:46 +1000, Tom Fifield wrote:
> > >> On 10/07/13 15:40, Andreas Jaeger wrote:
> > >>> On 07/10/2013 02:34 AM, Tom Fifield wrote:
> > >>>> I'll take a bullish line, which may not necessarily be achievable:
> > >>>>
> > >>>> """
> > >>>> On the day that the press release for Havana is sent out, we need
> -by
> > >>>> hook or by crook!- to have installation instructions for RHEL and
> > >>>> Ubuntu, and ideally SUSE and Debian too.
> > >>>> """
> > >>>
> >
> > I'd like as many helpers on this as possible and focus on this effort.
> > Andreas it sounds like you want to make this happen for SUSE.
> >
> > Do we stop single sourcing with conditions for each op sys?
>
> I think that single sourcing using conditionals is working OK and I'd
> prefer to see it stay, albeit with the installation materials consolidated
> into one source guide instead of conditionalizing two source guides. That
> said what alternative would you propose?
>
> > >>> What kind of instructions are you looking at? The "Basic
> installation"
> > >>> ones, the current "installation guides" - or both?
> > >>>
> >
> > I think we want one guide that starts simple and goes to complex with
> > multiple example architectures. Note this is the opposite of what we have
> > been doing so far.
>
> +1, I think this approach makes a lot of sense even with the core projects
> where users may wish to pick and choose some of them let alone if it ever
> becomes possible/necessary to add the integrated projects.
>
> > >>> Andreas
> > >>
> > >> Thanks for the reply!!
> > >>
> > >> I think the answer is: "something" ;)
> > >>
> > >> My personal impression is:
> > >> * the basic install guide is too basic right now
> > >> * the install guides are too heavy
> > >>
> >
> > Heh. I think the basic is too complex because of the networking. But your
> > eyes are fresh.
>
> Networking setup, while complicated, is also pretty core to user
> expectations of a working environment. I guess the network node could be
> collapsed onto the controller for a basic setup (I suspect that argument
> has probably been had before  :)) but I'm not sure that significantly
> simplifies things.
>
> >8-------->8-------->8-------->8-------->8-------->8
> > > And I believe very strongly that your docs should be ready on release
> > > day. They're part of your fanfare, and should be linked to from your
> > > marketing materials.
> > >
> >
> > I'm scared of this but we have to scope it for install docs at least, the
> > board, technical committee, and especially the users expect it.
> >
> > I don't think all docs can be ready at release, the scope is too wide.
> There
> > are 30+  docs on an Openstack.org domains. My current thinking is that we
> > will have a set of release docs (install and config only) and a set of
> > library books that are not manuals tied to a release but merely guides.
> We
> > may need to publish elsewhere to make this line strongly drawn, but I'm
> not
> > sure we are ready to do that type of curation.
> >
> > This distinction is especially important as we must prove we can deliver
> docs
> > at release time.
>
> So here's a related question, what determines whether a given document is
> ready for the release? Both in terms of what has been done in the past and
> whether or not we need/want to define a criteria that we're aiming for?
>
>
In past releases we released all books from the repo. I think this is going
to change and only a selected set will release on release date.

The criteria for release was the number of bugs in the backlog, a judgement
call I made with the backing of the docs list.

I'd like to release on release date the selected documents we choose and
dig into the Design Summit for once rather than continuing to have stress
about the high number of bugs in the backlog and the as-yet-unreleased doc
site. This means we need:
- to choose which docs are released
-to redesign a docs landing page for a release site
-to redesign a "library" landing page for a set of docs that are useful but
not tied directly to a release. The OpenStack Security Guide is written in
this way.
-to continue to track bugs and have a good judgement call for whether the
selected docs are ready for release


> Thanks,
>
> Steve
>



-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130712/83ea024b/attachment.html>