- To: firstname.lastname@example.org
- Subject: Re: Done
- From: Andreas Rottmann <email@example.com>
- Date: Wed, 08 Oct 2003 00:59:08 +0200
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <20030916165814.GW1917@tennyson.netexpress.net> (Steve Langasek's message of "Tue, 16 Sep 2003 11:58:14 -0500")
- References: <20030911011216.GD2431@thanes.org> <email@example.com> <20030913134040.GA10950@riva.ucam.org> <E19yPY4-0007tXfirstname.lastname@example.org> <20030914195351.GA3707@quetzlcoatl.dodds.net> <email@example.com> <20030915153745.GC27987@tennyson.netexpress.net> <firstname.lastname@example.org> <20030916165814.GW1917@tennyson.netexpress.net>
Steve Langasek <email@example.com> writes:
> On Mon, Sep 15, 2003 at 01:24:11PM -0500, Manoj Srivastava wrote:
>> On Mon, 15 Sep 2003 10:37:48 -0500, Steve Langasek <firstname.lastname@example.org> 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
>> 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?
I strongly second that.
Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | email@example.com
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Packages should build-depend on what they should build-depend.