Open Stack

Hi Tom,

Thanks for your additions, I haven't considered the issue of what we call 'supported' and how to handle this from documentation point of view yet.

> Essentially: the documentation team needs to be more lenient in removing
> old versions than the software projects :) We don't need to update old
> versions, and would respond to any queries to do so with "sorry, it's not
> supported", but the stuff still needs to be online and accessible for some
> time.
>
> The reason for this is, for essentially no cost*, we have the unique ability to
> make a positive impact in the approximately one-third of users that are
> running an unsupported release.
> 
> Though they would no longer be able to get support upstream, have any
> feature requests or bug fixes, they should be able to still use the cloud they
> have to the best of their ability until such time as they can upgrade.
> 
> On a related note, I have re-opened the bug regarding the difficulty our
> readers have in terms of finding the correct version of the document for
> their cloud (https://bugs.launchpad.net/openstack-manuals/+bug/1191447
> ), since this issue is ongoing and continues to be reported.
> 
> Your views on how we can continue to best serve our community of users
> across all versions that they choose to use are appreciated!
> 

This is something, which also indicates to me that we could handle documentation similar to source code. From readability point of view to me it seems better to have a guide, which describes the stable states of OpenStack, just like how we have stable releases for the source code. This would also solve the what is still supported question as we would not need to deal with that in these documentations anymore. I don't know how much feedback we have for these documents from operators or users, maybe I have this old way of thinking regarding to documentation, which should be changed. :) To me it just seems confusing to have information about at least three releases in the same document. If it means that it is written in the way of providing a clean separate view for each release, then it just looks like too much content for one guide, but if it is written in an iterative way, then the reader has to build the view for the release that he/she is interested in, which does not seem to be that convenient.

What is your opinion?

Best Regards,
Ildikó