On Thu, 2004-09-16 at 04:17, Karsten Wade wrote:
On Wed, 2004-09-15 at 15:12, Paul W. Frields wrote:
> I see your point, Tammy, but my feeling would be to opt for only two (or
> three) subheadings under the current "Docs" nav bar entry:
> by Title
> by FC Release
> *This would be that extra structure I mentioned; not really a FAQ, but
> an organization of questions that would link to the Title index.
I.e., "by Title" expands to have a list of all documents by title in
alpha order, and "by FC Release" expands to a short list of release
numbers, which then expand to a set of document titles that are just
part of that release?
Yes, exactly, although by "expand" I am guessing you mean when one
clicks "By Title" in the nav bar, the body of the HTML page fills with
the content. I certainly wouldn't want all that in the nav bar too. I'm
not sure I made that clear.
One immediate problem I see is a maintenance nightmare. As much as
would like to have a CMS, this is currently a manual process. We need
to focus on a simple structure that works, and let Google do the
indexing for us. :)
Ah. If Tammy has to change three or four pages manually, plus the nav
bar source, every time a document is posted, that would indeed be
prohibitive. I wasn't sure of the internal process. If she had scripts
doing it for her, now.... :-) Would you say that a simple listing by
alphabetical title should be enough -- in other words, not much
different from the current page?
> With the very aggressive release schedule of Fedora Core, it
> long before the nav bar became very crowded (FC2 through FC6, anyone?).
> The Docs Project doesn't currently have a policy for when we won't
> publish documentation anymore for a release, and I'm not sure we should
> have one. There may be people as comfortable staying with certain
> releases as they were staying with, say, Red Hat Linux 7.3. I would try
> and leave the nav bar as generic as possible while still being useful.
It seems reasonable to hand-off maintenance on version-specific docs to
the Fedora Legacy project, when the matching version of FC is
An author could choose to continue to work on the document, but it is
now under the aegis of the Legacy group, who are presumably just
following the examples and rules we have set.
Just like supporting the software, we have to draw the line on how far
back this project is going to support documents. We don't have the
resources to support a version of FC for several years. Tying the
lifecycle of our documents into the entire distro lifecycle seems like a
OK, I can live with this as well. I figured that having old versions on
the shelf somewhere would be a good idea. If we obsolete our documents
at roughly the same rate as other handoffs to the FLP, then we should at
least have a link on &FDPDOCS-URL; that points to their document
It probably bears mentioning, with absolutely no ill will or offense
intended, that the FLP is currently undergoing some pain trying to
recruit and maintain participation. I'm sure that's no different than
many other projects, and I hope they get everything sorted out
satisfactorily. We might want to be prepared for the small chance that
FLP is not prepared to handle maintaining any such repository. The task
of storage won't be overwhelming in that case, but the task of
maintenance will, of necessity, likely drop off the scope.
Paul W. Frields, RHCE