<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 8:31 PM, Lorin Hochstein <span dir="ltr"><<a href="mailto:lorin@nimbisservices.com" target="_blank">lorin@nimbisservices.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Anne:<div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><br><br>5. Doc tools updates:<br>
<br>I love hearing that RedHat is testing their tools with our source. A year or so ago I learned about Publican at the Open Help Conference and wondered if we should just re-tool. Would love to hear discussions around that -- we need the maven plugin for the <a href="http://api.openstack.org/api-ref.html" target="_blank">api.openstack.org/api-ref.html</a> site, but there are certainly cases where it would be cool to completely share content and tooling. <br>




<br></div></blockquote><div><br></div></div><div>Could you say a little more about the benefits of using Publican over our existing tooling? In particular, I can imagine how sharing tooling with others would be a benefit (especially if, say, RedHat was using it for their own OpenStack-related docs), but how would it help us share content with others? </div>


<div><br></div></div></div></div></blockquote><div style><br>Hi Lorin, </div><div style>Great questions. I have to 'splain myself some more. </div><div style><br></div><div style>Early on when I just got started with OpenStack docs, the only existing docs were API specs. They were Docbook and built with ant. Then we hired someone at Rackspace to create a Maven plugin. At the time we didn't really know about Publican. I found out about Publican about a year ago, last summer at the Open Help Conference. </div>

<div style><br></div><div style>Content sharing only made sense for the APIs -- Rackspace, HP, others should just consume our API docs (and do to a point) so there's a single source of truth. There may be more use cases for content sharing in the operations/install space now that the distros are looking into it and I think there's some possibilities there with careful information architecture especially for install and configuration. If you think about it, we currently share about 80% of install content between ubuntu and fedora/rhel/centos with our conditionally-output install guides. </div>

<div style><br></div><div style>With Maven, we can do "fancier" API output like <a href="http://api.openstack.org/api-ref.html">api.openstack.org/api-ref.html</a>. So I think we need 2 toolchains, but I hate to duplicate effort and there are overlapping features especially around translation. So it might make sense in the future to use Publican for operations/configuration guides and Maven for API guides. Who knows what the future brings so it's always good to look for efficiencies in process and tooling. </div>

<div style><br></div><div style>Anne</div><div style><br></div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">

<div class="gmail_quote"><div></div><div>Take care,</div><div><br></div><div>Lorin</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- <br></div></font></span></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">

Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div>
<div><a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div></div>
</font></span></div></div>
</blockquote></div><br></div></div>