<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 31, 2014 at 3:09 PM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Thanks for the response Anne,<br>
<div class=""><br>
> > Which is fine, I just need to level-set the expectations here,<br>
> > since the ceilometer team is on the hook for a TC-mandated gap<br>
> > coverage task[2] and also has a bunch of other stuff on its<br>
> > plate.<br>
> ><br>
><br>
> I'd like to continue to enable the docs team to provide the additional<br>
> polish and editing. Is your concern the timeline? Or that the team's<br>
> efforts appears to be less than desired?<br>
<br>
</div>Actually it was more confusion on my part, due to the comments dating<br>
from yesterday on:<br>
<br>
<a href="https://review.openstack.org/#/c/108741/7/doc/admin-guide-cloud/ch_telemetry.xml" target="_blank">https://review.openstack.org/#/c/108741/7/doc/admin-guide-cloud/ch_telemetry.xml</a><br>
<br>
which referred to revisions, which I then assumed meant a *separate*<br>
patch, as the revised patchset wasn't pushed until today (I see now<br>
from the comments trail in gerrit that this was just a simple oversight).<br>
<div class=""><br>
> If your concern is the timeline, we can certainly push through what is<br>
> considered "good enough" by the project team. However we merged 20 patches<br>
> yesterday so I don't think that's what you're talking about.<br>
<br>
</div>I'm somewhat concerned with timelines, since we're on the hook to get<br>
this done by juno-3 (plus a lot of other things).<br>
<br>
However I'm mostly concerned with just clarifying and streamlining<br>
the workflow, so that as to minimize the friction involved in<br>
getting this over the line.<br>
<br>
Potential points of friction include:<br>
<br>
* our lack of clarity of the contribution model preferred by the<br>
documentation team<br>
<br>
* our unfamiliarity with the documentation tool-chain<br>
<div class=""><br>
> If your concern is that the writing is being rejected somewhat, let's talk<br>
> some more about that. For the most part the core-docs team have a really<br>
> good sense of the voice and style we aim to achieve.<br>
<br>
</div>Well, I'm perfectly happy for the "house style" to be applied,<br>
so no problem with that step in the workflow, now I understand it<br>
involves polishing the original patch and re-submitting that as<br>
opposed to a fresh proposal.<br>
<br>
In fact the other approach of content being re-proposed as fresh<br>
patches could alternatively work well ... but my point was simply<br>
that if extensive rewrites are applied as a matter of course then<br>
there doesn't seem to a pressing need for the content submitted by<br>
the project team to be *already* in the unfamiliar XML mark-up.<br>
<div class=""><br>
> > If the workflow is based on rough content being provided by the<br>
> > project team, which is then polished up by the docco team, then I<br>
> > think we really need to streamline this process to avoid burning<br>
> > time unnecessarily getting to grips with the XML-based markup and<br>
> > maven-based build system.<br>
> ><br>
> > For example, would it make more sense for the raw content to be<br>
> > submitted initially in a simple lightweight form, such as free-<br>
> > form text or .rst or wiki markup?<br>
> ><br>
><br>
> Really, what you describe is happening already. The lightweight docs tools<br>
> remain in the <project> repos. The heavyweight docs tools are the ones that<br>
> are integrated across projects. This separation is by design with the<br>
> following benefits in mind:<br>
> - docs team knows cross-project consistency<br>
> - translations are enabled for these deliverables<br>
> - docs team manages scope and priority for cross-project docs<br>
> - docs team understands operators, administrators, users deliverables<br>
<br>
</div>OK, but in this case the project team has strayed into the domain<br>
of the "heavyweight docs tools" - should we have stayed out of that<br>
domain and instead crafted the content in the first instance back in<br>
the project repo and have it fed into docs from there?<br>
<div class=""><br>
> > That would allow the domain expertise of the project team to be<br>
> > leveraged, without imposing an unnecessary burden, while at the<br>
> > same time getting the most RoI for the time spent by the docco<br>
> > team revising the formatting according to their own particular<br>
> > domain expertise.<br>
> ><br>
> ><br>
> Believe me, I'm working on getting the ROI calculation reversed a bit by<br>
> introducing new tools, but for now the system is working as designed. I'd<br>
> be happy to hear more tweaks.<br>
<br>
</div>Understood! :)<br>
<br>
I'm sure the RoI from this tooling is already strong on the docs<br>
team, I'm more questioning the return from the learning curve of<br>
the project-team to use this mark-up and toolchain for essentially<br>
a once-off task.<br></blockquote><div><br></div><div>Eoghan, I just can't let this go without saying something. The TC doesn't put these requirements in place as once-off tasks. We put them in place so that you can support the people who need to keep ceilometer running every day. Not as a barrier to entry, but to ensure OpenStack means that you can get consistent docs to help you run OpenStack.</div>
<div><br></div><div>We are working on ways to enable more simple markup in our toolchain. The most recent is the Heat Orchestration Template (HOT) Guide. Stay tuned for more as we keep onboarding more integrated projects. </div>
<div>Thanks,</div><div>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Eoghan<br>
</blockquote></div><br></div></div>