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@xxxxxxxxxxxxxxxxx -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
