Re: The transition from dgo

[Curtis Hovey <sinzui is verizon net>]

On Wed, 2005-12-21 at 12:48 +0100, Claus Schwarm wrote:
> On Wed, 21 Dec 2005 10:29:43 +0100
> Quim Gil <qgil desdeamericaconamor org> wrote:
> 
> > How is this move from dgo to the wiki going to work? Something like
> > warning officially the developers and documentation team, weels later
> > de-link dgo, weeks later making it accessible through htaccess or
> > switching it off?
> > 
> 
> Some teams (packageing, for instance) already moved their content to
> live.go and say so on dgo. Others, such as the usability team, still
> need to do that.
> 
> Check: http://developer.gnome.org/projects/ for their status, but
> that's not urgent, anyway.

Usability and Accessability have a challenge moving away from dgo
because they are generating PDFs and HTML from their DocBook.  They
cannot move until someone provides a means to publish to the new
location where the content must live.

We need a solid PDF generation mechanism. Both U and A groups use local
installation of FOP (a Java implementation). I used FOP to make the last
round of user and admin docs that appear on w.g.o. PassiveTex is below
average, but is easier to get via your distros packaging system than
FOP. Creating a preprocessor to calculate column widths may do the trick
for PassiveTex. I want to switch from Norman Walsh's XSLT to
gnome-doc-utils

> Pieces of the other information on dgo -- architecture, for instance --
> looks usable for wgo/technology/. wgo/documentation looks usable for new
> library.go.
> 
> The rest of dgo is more or less rubbish.

Older docs have historic value for developers and admins with old setups
that need maintenance or a plan to upgrade.  We need to preserve the old
docs, and we need to clearly mark their status as current, deprecated,
or obsolete.

I do not have a solution to change the status of a group of documents
that doesn't involve editing.  We could use a local css file that
represents the status, but I believe the text of the document, and the
metadata must indicate the status of the document for spiders, and where
current documentation can be located.

> I'd like to suggest that we simply remove the link from the header when
> wgo/technology/ is ready. I'm trying to write the first draft right now
> but this is a PITA because I know nothing about GNOME's technology.
> 
> This way, newcomers won't run into dgo, and for people following old
> links we can simply edit the header image with a big red sign saying:
> "Depreciated. Visit lgo." or so.
> 
> An automatic redirect is not always the best solution: Some people may
> like to read the exact old content.

I'd like to postpone this until I get the content upgraded for
portability. I have been QAing a revision to dgo that has full HTML
pages instead of fragments and an updated page generation mechanism
(along the lines of evilsedhack). These pages are more portable, easier
to toss into a library.  I started this three weeks ago, but I haven't
had time in the past two weeks to to commit it since my wife has had me
altering some GNOME apps to do printing her way.

My next round of changes was to move the high-value docs to XHTML.
PyBlosxom will serve XHTML as well as wiki source.

> 
> > What has been planned about the library? Sorry, I missed this.
> > 
> 
> I'd be interested in the answer, too.
> 
> According to google, there was a google SOC bounty for library.go but I
> found no results. Everybody seems to think documents will go there but
> nobody has an idea how this should *really* look like.
> 
> Maybe we should start a wiki page to collect everybody's thoughts, and
> potential solutions? I'm sure the documentation team likes to be part
> of the library.go decision. It's them who will need to keep the content
> up to date, isn't it?

-- 

__C U R T I S  C.  H O V E Y____________________
sinzui is verizon net
Guilty of stealing everything I am.