CMS discussions yet again

Christopher Curran ccurran at redhat.com
Wed Jan 28 01:49:46 UTC 2009


Karsten Wade wrote:
> On Tue, Jan 27, 2009 at 11:51:29AM -0500, David Nalley wrote:
>   
>> Sparks, jsmith and I were talking in IRC and I thought the
>> conversation should have a bit wider audience.
>>
>> I think that while kbase and housing documentation for packaging
>> guidelines and legal are excellent use cases for a CMS, I wonder if by
>> trying to use it for everything we are not trying to use a hammer to
>> drive a screw. My reason for saying that is that it seems like we are
>> trying to push all of our non-wiki documentation into the CMS, which
>> at least from my perspectives means we, to one degree or another, are
>> abandoning DocBook.
>>
>> For our 'heavy' documents, such as Release Notes, User Guide, and
>> Security Guide, I don't see an escape from DocBook - it provides a lot
>> of advantages that just don't exist in a CMS.  It does have
>> disadvantages to be sure, but I guess the question in my mind is with
>> all of the talk of moving to a CMS are we really prepared to ditch
>> DocBook and it's benefits? Or is the CMS a solution for things like
>> Legal and Packaging Guidelines, and potentially a knowledgebase, and
>> not more?
>>
>> Thoughts, Comments, Flames?
>>     
>
> I think all of this was answered in my responses to other threads.
>
> We have to consider a document as coming from an upstream.  The team
> working on the document can choose from a wide variety of content
> solutions -- 
>   
What upstream? We are just going to loot other distros docs now because 
they manage to get stuff published?

> * fp.org/wiki
> * fhosted.org/$foo/wiki
> * fhosted.org/$foo/$xml
> * docs.fp.org/$cms (they will, you know they will)
So four solutions is how to ensure consistency...



> To some degree, this Docs Project team needs to think of itself as
> packagers.  Some content we package we produce ourselves; some we get
> from upstreams.  Where we control the full lifecycle, we make certain
> choices.  Where we cannot control the full lifecycle, we take what we
> get and do what we need to it.
>
>   
What lifecycle? Most docs projects are stagnant wiki pages? Models are 
great when there is real development going on but a hindrance when there 
isn't.

> We 100% should have a consistent, best-practice, preferred, and
> documented set of tools and process to take ideas to published.
>
>   
Absolutely. That means one(1) solution. The kernel is almost entirely 
written in C and managed with git repositories. They don't have 14 
repository types and 10 different languages. Consistency is one size 
fits all. Only git and DocBook would be a consistent fedora docs 
project. Any other system is inconsistent by definition.

> We also need to accomodate the many places content is coming from and
> not expect that we can enforce (all of) our styles on them.
>
>   
You keep talking about content coming from places as if it actually is 
coming in. Last I looked there were two(2) documents actually being 
produced: the security guide and the release notes. Perhaps two is many 
in your world but most people's definition of many is more than that.

> There is a balance in here; from experience we can know "All
> DocBook XML following this specific standard in our single version
> control system" does not scale to support something the size of the
> Fedora Project, much less just Fedora Linux.
>
>   
Bull. It scales well with other projects. Referencing gentoo again 
because it is where I used to do a lot of documentation. Single SVN repo 
and GuideXML. They have several orders of magnitude more content than 
fedora project.

It simply doesn't scale with your desire to have fingers in every pie.

Chris




More information about the docs mailing list