Publishing old guides

[Pete Travis]

On 04/14/2015 03:03 PM, Paul W. Frields wrote:
> On Sat, Apr 11, 2015 at 09:04:14PM -0600, Pete Travis wrote:
>> I'm thinking about how stale we want to let a book get before we stop
>> publishing it.  Right now, the de-facto policy is to stop maintaining a
>> guide for a release when the release goes EOL, but on migrating to a new
>> publishing system, we'll have to decide if we want to republish
>> _everything_.
> Since I'm a little out of touch with Docs myself these days... What
> are the group members' opinions on publishing whole books, vs. looking
> at innovative ways to publish and maintain smaller content chunks?
>
> This latter is a goal FPL Matthew Miller has been talking about of
> late.  Is the Docs team large enough to do both well?
>
>> It seems like publishing the currently maintained versions, plus the
>> release under development, plus the most recently EOL'd release, should
>> be enough.   Early adopters are covered, stragglers are covered for
>> their upgrade, stubborn EOL users get the appropriate amount of support,
>> and nobody gets really stale, potentially incorrect or harmful
>> instructions.   I'm throwing this on the agenda to discuss at the next
>> meeting, if you can't make it, please reply here. 
>
We've talked about it a lot lately, and there's a general consensus that
making room for those smaller chunks would both enable more contributors
and better target Fedora's user base.  The active contributors at this
point are those dedicated enough to maintain entire books, but I
definitely think the potential is strong enough to merit alternative
publishing solutions.  I've talked to lots of people that would write
more, if we could only accommodate them better.  Speaking for myself,
there are probably 20-30 small articles worth of content spread across
notes, gists, uncompleted guides, and wiki pages that I've written.

The idea has been discussed enough that I have a relatively clear idea
of many requirements and design goals I'd like in a hypothetical, ideal
publishing system:
- Using CI so that writers and translators don't have to care about
publishing
- using git for workflow continuity, auditing, change review
- building from multiple source formats to (at least) HTML with a
uniform appearance
- predictable categorization of content for easy browsing
- potential for test/validation automation[0]

Afaik, such a beast does not exist, so I'm building one[1].  A lot of
the questions I've been asking on the list and in meetings lately are
centered around working out design and implementation details for the
project.    The general idea is that you feed the thing a bunch of git
repos full of docs of various formats, and it builds each doc as it
changes,  then will trigger a [re]assembly of the site frontend.  Right
now, I'm working on support for building publican books and prepping
them for the assembly stage.

[0] https://github.com/emender/emender
[1] https://github.com/immanetize/anerist

-- 
-- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanetize at fedoraproject.org