[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Documentation Metrics
Jorge Godoy wrote:
> >>>>> On Mon, 16 Oct 2000 15:55:47 -0400, "David C. Merrill, Ph.D." <firstname.lastname@example.org> said:
> DCMPD> From: "Craig M. Buchek" <email@example.com>
> >> From: David C. Merrill, Ph.D. [mailto:firstname.lastname@example.org]
> >> > 1. Audience Type
> >> > - application user
> >> > - programmer
> >> > - system administrator
> >> One document may apply to some or all.
> DCMPD> Indicate all that apply.
> It could be based on the catalog that Kevin is building... Or it could
> be used by Kevin. There are overlapping tasks here. I suggest that you
> get in touch and divide them to make the process faster.
I think the tasks are somewhat overlapping, but Kevin and I are in
contact and are sharing ideas through the list, where everyone can
> DCMPD> Most documents only apply to one of these audiences, however. And a good
> DCMPD> argument can be made that a HOWTO that doesn't target one of these three
> DCMPD> should be split into two.
> Sorry, could you explain it better? If one HOWTO applies to more than
> one of these it should be split to match only one? (sorry... I'm
> almost sleeping and trying to put LDP messages up to date)
I said only that you can make such an argument. You can also make a good
argument for keeping it together.
My goal is to identify areas where we provide advanced information, but
nothing suitable for beginners, or helpful to them. And vice versa. I'm
not saying we should split them. The comment about an argument for
splitting was just a side comment.
> DCMPD> Seriously, though, this information is not going to be publicized. It is for
> DCMPD> my personal use, and perhaps for a few others that help me. And, if the
> DCMPD> document is really awful, I have no problem saying so. One thing you can
> DCMPD> count on me for is being honest about our shortcomings. How else can we
> DCMPD> address them?
> If you don't mind, it would be interesting for an author to have
> access to this information on her/his HOWTO/document. This way people
> might know where they need to improve their document (besides
I'll be getting in contact with authors whose work needs updating or
improving. I won't write them to say that their HOWTO sucks, though. I
will try to be just a bit more diplomatic than that. ;-)
David C. Merrill, Ph.D.
Linux Documentation Project
Collection Editor & Coordinator
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org