discuss: Dealing with poor maintenance by maintainers
Subject:
Re: Dealing with poor maintenance by maintainers
From:
Tabatha Persad ####@####.####
Date:
14 May 2002 19:29:07 -0000
Message-Id: <20020514191502.IMVE25294.rwcrmhc52.attbi.com@there>
David,
Thanks for the grins. I'd absolutely be glad to help develop something like
that.
As I have been travelling the web in search of really great resources for
writers, I've noticed that Open Source documentation guides often cover style
and submission, while traditional publishers of print and "closed source"
guides often have separate guides for style and submission.
When I consider submitting my work there are things I want to be prepared
for. Of course there's the obvious, "What format do I use?" Then the
questions get deeper, such as who will be my backup contact if I'm not
available to answer questions about my HOWTO (I'm sure that authors don't
initially plan to abandon their docs!)? What types of documentation should I
submit/not submit (case in point - Russian Tea HOWTO)? What type of META
information should my document have? What information should be contained in
the <bookinfo> or <articleinfo> tags? What are some of the required sections
(such as copyright, resources, credits) that will be common to most
documents? Why do I need an FDL license? Many of these ideas create
consistency. Then there are other questions, such as, After my document is
reviewed and included as new in the LDP, how much time passes before the LDP
performs language and technical reviews? This could also cover timelines for
how long certain processes take.
Do you think any of these ideas bleed into the style/author guide too much?
So far my list is fairly short - these are things that could definitely be
addressed by a process/policy manual:
- Process for unmaintained or abandoned documentation
- Licensing Requirements
- Process for submission and review of documentation
Shoot your ideas my way - I still get the feeling this could all be included
in the Author's Guide since the information is related, but the reasons for
keeping it separate are simple. Author's Guidelines and LDP Policies don't
have to necessarily be the same thing. I suppose it doesn't hurt to add that
the policies should be there to PROTECT the author, and encourage them to
maintain their work. If we publish requirements or policies, these serve to
demonstrate that the LDP contains a certain calibur of documentation that can
be relied upon.
That's a good thing!
Let me know if I'm on target or if I'm missing something! I'm sure there's
plenty that we can add to this! If I can get a little input I'd be happy to
start drafting an outline for everyone to give some feedback on!
Tab
> We really should develop a policy manual on how to handle all of these
> things. We have traditions and conventions we follow, but not all of
> them are written down.
>
> Anybody want to try collecting that stuff into a document? Hint, hint,
> Tab!
>
> You could start with an outline of what policies we should have in it,
> then we'll lay out the noncontroversial stuff, and see what
> controversies we uncover. Probably not too many, we have worked
> through most of those types of issues. They just need to be documented
> so we have it in print and it can easily be communicated to authors
> and volunteers.
--
Tabatha Persad
Web: http://www.merlinmonroe.com
The Linux Counter Project Area Manager US:wa (http://counter.li.org)
Linux Documentation Project Editor (http://www.tldp.org)
Gnu Writing Movement Project Developer (http://savannah.gnu.org/projects/gwm)
