<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 8:27 PM, Scott McBrien <span dir="ltr">&lt;<a href="mailto:smcbrien@gmail.com" target="_blank">smcbrien@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>There&#39;s a reason why RH sales recommends a professional services engagement to go with the product. To be fair, they also do the same for Sat 5, but my impression is its more worth it right now for a sat6 implementation.</div><div><br></div><div>In a perfect world, yeah docs would be 100%.  But if you&#39;ve worked on a big software project, what happens is that the docs team is reliant on the engineering team to provide accurate, timely information.  Also, it&#39;d be nice if they also reviewed what the docs writers are writing.  Sadly, when you&#39;re up against a deadline, that nice process is chucked out the window and docs writers requests are ignored and review turns into a quick glance and &#39;Yeah, that looks right.&#39;</div><div><br></div><div>They&#39;re currently working on 6.1 which, from what I understand, is mostly UI and workflow improvements.</div><span class=""><font color="#888888"><div><br></div><div>-Scott<br></div></font></span></div></blockquote><div><br></div><div>I understand you&#39;re defending your coworkers. And I understand that it&#39;s no small undertaking to put out product like Satellite. But I&#39;m not going to hold back when something is being touted so prettily on the &quot;please buy it page&quot; and is as expensive as it is. I don&#39;t mean any malice, I&#39;m just stating my experience and opinion bluntly.</div><div><br></div><div>Adequate documentation does not necessarily mean 100% documentation. What is currently offered, though, is not what I consider adequate (and Ramesh seems to be agreeing with me). Here, I&#39;ll cite an example:</div><div><br></div><div>The first mention of the &quot;Products&quot; concept is 4 chapters into the User Guide -- <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html/User_Guide/sect-Using_Products.html">https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html/User_Guide/sect-Using_Products.html</a></div><div><br></div><div>Do you see a description of what a &quot;Product&quot; is? Clearly this one that can figured out by poking around the UI, but it&#39;s a clear and easy example of what I mean when I say the documentation, in its current state, is unacceptable. It gets worse when you start looking at  the configuration management stuff. The configuration management has a &quot;repositories&quot; concept and there is no explanation about how it differs, if it even does, to a yum repository (although, I can&#39;t even find where I was reading about those now).</div><div><br></div><div>The short of it is this: documentation is not an add-on, it&#39;s a major part of the product. In fact, it&#39;s probably the most important part of the product. Sure, I have a support subscription. But I have my own deadlines and can&#39;t sit around waiting on support to read through an SOS report (or whatever) for however long it will take them just to get past something that should already be documented. An actual problem, &quot;it be broke&quot;, is a different story. That&#39;s what support is for.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James Sumners<br><a href="http://james.sumners.info/" target="_blank">http://james.sumners.info/</a> (technical profile)</div><div><a href="http://jrfom.com/" target="_blank">http://jrfom.com/</a> (personal site)</div><div><a href="http://haplo.bandcamp.com/" target="_blank">http://haplo.bandcamp.com/</a> (band page)</div></div></div></div></div>
</div></div>