Open Stack

I'd normally be okay with the incubation subdir, but we have been communicating the current docs.openstack.org/training-guides<http://docs.openstack.org/training-guides> for a while. I think it would be confusing to move it at this point.

We three are on the review https://review.openstack.org/#/c/96334/
I need your stackforge comment so fungi and jeblair will release the infra patch.

I'll make sure these are part of the goals
- increase the quality of the training manuals
- set reader's expectations about the training manuals being community-based
- increase the contributor base and core reviewers
- ensure reuse of tools and content to avoid duplication of effort while still providing unique deliverables for training purposes

Noted
note that your builds use tox and keep updated with the global-requirements list.

Thanks

~sean

On Jun 9, 2014, at 6:18 AM, "Anne Gentle" <anne at openstack.org<mailto:anne at openstack.org>> wrote:

Inserting Sean's question set (sorry for the copy/paste).

We are starting to hit some questions that I do not have ready answers to.?
        * where to store the data: Tom and I were initially thinking stackforge before incubation. move under the openstack repo org after incubation as training-guides. fungi and jeblair are questioning a stackforge project publishing todocs.openstack.org<http://docs.openstack.org/> rather than just openstack-manuals. I do not have a great answer other than I believe Anne is good with that for now. If the docs PTL and team is okay with this, do I need to ask the TC as well?

Yes, stackforge is the right placement. I'm fine with publishing to docs.openstack.org/<http://docs.openstack.org/> -- we used to have docs.openstack.org/incubation/<http://docs.openstack.org/incubation/> -- perhaps that URL is a good place?

I want to back up a bit and make sure we all understand the goals here (many of these are listed in the Incubation Plan also):
- increase the quality of the training manuals
- set reader's expectations about the training manuals being community-based
- increase the contributor base and core reviewers
- ensure reuse of tools and content to avoid duplication of effort while still providing unique deliverables for training purposes

        * where to house the project: I would like it to stay under the documentation program. Any other ideas?

I think that's the idea, that you'll fit within the Docs program, and your incubation plan below is a great start.

Find here the all the incubation plan Q&A using the latest TC requirements
https://wiki.openstack.org/wiki/Training-guides#Incubation_Plan

Looks good, you might note that your builds use tox and keep updated with the global-requirements list.

Thanks for asking Sean -- let's get this ramped up.
Anne


On Thu, May 29, 2014 at 8:14 PM, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:
On 30/05/14 01:40, Anne Gentle wrote:



On Wed, May 28, 2014 at 9:56 PM, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>
<mailto:tom at openstack.org<mailto:tom at openstack.org>>> wrote:

    Hi,

    Sean Roberts, Stefano and I just had a very fruitful discussion
    regarding the training manuals project.


Thanks you all for discussing.


    We think that it's time to allow the the training guides to become a
    free-standing project of its own accord, and start attracting
    significantly more people around it.


    This will make it easier for contributors who just want to work on
    training to find the project, see lists of bugs and tasks relevant
    to them*, and also provide a clearer pathway toward becoming
    contributors, and eventually core reviewers.

    It will also enable the training guides project to have its own
    policies, and allow the repository to be used for investigation of
    training infrastructure, such as the recent forays into moodle for
    example.

    However, with every change such as this, there are drawbacks, and so
    we feel it's important to discuss these as well - and most
    importantly get your input.

    For example, while we can continue to re-use tools and content, this
    would mean a different review queue and repository - which could
    frustrate if you are working across both projects.


I hope the intention is to continue to use inclusion of known tested
content from the various other OpenStack repos as needed.

Yup, that's the case.


    What are your thoughts?


Sounds great to me. Thanks all!
Anne



    Regards,



    Tom


    * as opposed to the 400 odd in the openstack-manuals tracker!

    _________________________________________________
    Openstack-docs mailing list
    Openstack-docs at lists.__openstack.org<http://openstack.org>
    <mailto:Openstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>>
    http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-docs
    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140609/a47809da/attachment-0001.html>