On Mon, Sep 15, 2003 at 01:24:11PM -0500, Manoj Srivastava wrote: > 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) ??? These seem like very reasonable and helpful criteria. Perhaps they could be placed somewhere (developer's reference, policy footnote?) where they'll be generally visible to maintainers? -- Steve Langasek postmodern programmer
Attachment:
pgpL3Hiqp_6hC.pgp
Description: PGP signature