<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 08/26/2014 09:43 AM, Eric H. Christensen wrote:<br>
<blockquote type="cite">On Mon, Aug 25, 2014 at 03:40:10PM -0600,
Pete Travis wrote:<br>
> On 08/25/2014 02:17 PM, Eric H. Christensen wrote:<br>
>> On Mon, Aug 25, 2014 at 01:13:46PM -0600, Pete Travis
wrote:<br>
>>> Here's my idea: In the security guide, give an
overview, instructions<br>
>>> on how to lock down to deny-all, general instructions
on adding back,<br>
>>> and link out to the Networking Guide. In the NG, give
a full overview -<br>
>>> network security should be an inherent part of
network configuration.<br>
>>> In others, include the command to open a port for the
service being<br>
>>> documented where appropriate.<br>
>><br>
>> I really dislike the idea of spreading information out
into different<br>
>> guides. Users think they've got the entire story only to
miss another<br>
>> aspect elsewhere.<br>
>><br>
> Right, it's the spreading out that bothers me too. Service
config here,<br>
> network config here, firewall config there. I *don't* like
the idea of<br>
> managing similar content in different places, though. The
wiki doesn't<br>
> really fix that problem; includes work there just as well as
in docbook,<br>
> there's just a broader scope. There are valid concerns about
the<br>
> administrative overhead of our publishing stack, vs the 'just
write'<br>
> ethos of a wiki - but I think that even with a wiki we would
need to<br>
> have discussions about structure and scope.<br>
<br>
So how about this... Instead of having these big, fat guides that
contain a lot of information on a lot of different topics, we
start breaking down these guides into smaller chunks. Think
"Firewall Guide" which would talk specifically about iptables and
firewalld. They likely would be less work to maintain (although
there would be more of them) since, potentially, it would have
less stuff to deal with.<br>
<br>
-- Eric<br>
<br>
--------------------------------------------------<br>
Eric "Sparks" Christensen<br>
Fedora Project<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:sparks@fedoraproject.org">sparks@fedoraproject.org</a> - <a class="moz-txt-link-abbreviated" href="mailto:sparks@redhat.com">sparks@redhat.com</a><br>
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1<br>
--------------------------------------------------<br>
</blockquote>
<br>
<pre wrap="">I like it. More manageable chunks sounds.. more manageable. Until we get
to the part where you have to read the httpd guide to set up a web
server, then the SELinux guide for file contexts for a web server, then
the firewall guide for firewall rules for a webserver - or we maintain
the same content in different guides and try to keep track of it all.
Yeah, I know you're saying "start here", but I think we've come back
around to the question about most suitable formats.
The idea of modularized documentation is <b class="moz-txt-star"><span class="moz-txt-tag">*</span>really<span class="moz-txt-tag">*</span></b> appealing, but the
actual implementation isn't going to come for free. Will
publican/docbook work? What formats would enable the built-for-purpose
articles that Dylan is envisioning? We should explore some
possibilities before putting in the work to migrate the copy into new books.
( He says, hoping the conversation doesn't die there )
</pre>
-- <br>
-- Pete Travis<br>
- Fedora Docs Project Leader<br>
- 'randomuser' on freenode<br>
- <a class="moz-txt-link-abbreviated" href="mailto:immanetize@fedoraproject.org">immanetize@fedoraproject.org</a><br>
<br>
</body>
</html>