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

Re: Done



On Mon, 15 Sep 2003 10:37:48 -0500, Steve Langasek <vorlon@netexpress.net> said: 

> There is a distinct difference between recognizing what is missing
> from a description, and being able to fill in the gap.  The two acts
> are complementary.  What helps maintainers is to understand what the
> questions *are* that users are going to ask about their package
> description.  It's hard to know what questions are going to be asked
> when you already know the answer yourself; this is not something
> that can be changed through expressions of disdain.

	How about these criteria?
 a) What does the package do? If it is an add-on to another package,
    then the short description of the package we are an add on to
    should be put in here
 b) Why should I want this package?  This is related  to the above,
    but not the same (this is a mail user agent; this is cool, fast,
    interfaces with pgp and ldap and imap, has features X, Y, and Z)
 c) If this package should not be installed directly, but is pulled in
    by another package, this should be mentioned
 d) If the package is experimental, or there are other reasons it
    should not be used, if there are other packages that should be
    used instead, it should be here as well
 e) How is this package different from the competition? Is it a better
    implementation? more features? different features? Why should I
    chose this package (b should talk about the class of packages, and
    e about this particular package, if you have both b and e related
    information).
 f) ???


>> This is not about people not turning out perfect description for
>> people unfamiliar with the package; I understand how one can be too
>> close to a package to figure out exactly what areas need further
>> explanation. But if you can't expand the *LONG* description beyond
>> a measly 80ncharacters, you are not even trying.

> Perhaps not, but it's not obvious that a 5-line description will be
> better than a one-line description.  Indeed, the more useless text
> I'm forced to read, the more surly I become.  I definitely think the
> emphasis needs to be on quality, not quantity.

	Quite. But, in general, having the developer come up with a 5
 line description is likely to provide more data for the novice
 user. The more information I have, the more likely t is that I would
 know enough to make intelligent suggestions. 

	manoj
-- 
Happiness is twin floppies.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: