[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Outline for Author's Guide




I am going to vote for some of the tools first, especially the
conversion tools, or else we risk having the blind lead the blind.

Here is my rationale:

None of us have heaps of experience with the ways users of diverse tech
collections want to use information, or on how to catalog and manage
that information, yet this is the basis of an authoring guide.  My guess
is we will learn more by converting docs into an initial DocBook format,
running it past some stakeholders, and folding their comments back into
the auto-conversion process until people like it.

If we go with a half-cocked Author Guide, we will be faced with having
to re-format new documents to our eventual style guide, whereas if we
use existing docs to auto-generate what we *think* people will want,
if they don't like it, it is no big deal to re-generate a modified set
and to continue the iterations until everyone is happy (well, at least
content)  Then, with our final auto-generated editions, we can work on
the Author Guide but tell impatient authors "Take a look at the docs
we have converted and follow those examples"

This is all predicated on one of my favourite design principles:
People do not know what they want until they see what they do not
want.

-- 
Gary Lawrence Murphy <garym@linux.ca>: office voice/fax: 01 519 4222723
TCI - Business Innovations through Open Source : http://www.teledyn.com
Canadian Co-ordinators for Bynari International : http://ca.bynari.net/
Moderator, Linux Education Group: http://www.egroups.com/group/linux-ed


--  
To UNSUBSCRIBE, email to ldp-docbook-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org