Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• PackagesDes...tionsReview

Packages Descriptions review campaign

Many packages in Debian have low quality descriptions. This affects the general quality of the distribution by making searching difficult.

The idea (first mentioned by Lars Wirzenius in http://lists.debian.org/debian-devel/2005/07/msg01095.html) is to make a general package descriptions review campaign.

What needs to be done

All packages descriptions for packages in unstable (maybe only in main) should be reviewed. A large number of common "mistakes" can easily be spotted. Please have a look at the "Things to look for" section.

For descriptions which are identified as problematic, an updated proposal will be elaborated.

Also, it'd be useful to check ITP bug submissions. Let's prevent any further bad descriptions from entering the archive.

Email reports from the list

These packages have been identified as problematic on the list in the thread http://lists.debian.org/debian-devel/2005/07/thrd3.html#01074

• http://lists.debian.org/debian-devel/2005/07/msg01109.html (graphics/djview, libs/libaca0, libs/libsvncpp0, devel/libcml-smlnj, libs/libocc0c2, perl/libx500-dn-perl, sound/mdpconn.app, devel/netcdfg-dev, net/riece-lsdb, games/xjokes, libs/libast) -- added comments to the package pages for these

• http://lists.debian.org/debian-devel/2005/07/msg01113.html (devel/bnlib1, base/initscripts, admin/ld.so.preload-manager, games/trr19) -- added comments to the package pages for these

(Checked thread up through http://lists.debian.org/debian-devel/2005/07/msg01167.html)

Organization

To ensure maximal quality, all reviews and updates should be made by at least two people. Native English speakers are of course appreciated.

A Web-based interface has been developed to (hopefully) allow easy centralization of the current reviews, and easy generation of reports. It is available at http://zorglub.diwi.org/pkg-descriptions/

Here is how the work will be organized:

• Reviewers claim sections on this page to avoid conflicts
• Reviewers use the interface to spot descriptions that need to be fixed
• A proposal is elaborated.

When we have finished, a repository of the proposed descriptions with attached patches will be made available and an announcement will be sent out.

What we can hope is that maintainers will use this repository to fix their descriptions. After a few weeks, we'll start submitting bugs with suggested patches. (As it will represent a mass bug filing, we'll coordinate with qa).

Things to look for

In general, anything that does not help or confuses the user is probably worth fixing.

Obvious stuff

• Typos
• Speling air-oars. [Sorry!]
• Awkward punctuation
• Capitalization errors
• Incorrect English
  • Word order
  • Compounding
  • Japanese that with which also but. [Sorry!]
• Diction and style
  • Unclear referents (is it clear what "it", "this", "that", "there" refers to?)

  • Tautology (as in "This package also contains other stuff as well")

• Unexpanded acronyms

Policy violations

See http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions for full details, but in short:

• Descriptions which assume you already know about the program. (3.4)
• Descriptions which do not provide enough information to decide if you want to install the package. (3.4)
• Descriptions which aren't written in "reverse pyramid" form, with the important details up top. (3.4)
• Descriptions which do not explain the significant dependencies and conflicts the package declares. (3.4.)
• Descriptions which include instructions on using or configuring the package. (3.4)
• Descriptions which include copyright statements or "administrivia." (3.4)
• Short descriptions which are long, especially over 80 characters. (3.4.1)
• Short descriptions which include the package name. (3.4.1)
• Extended descriptions which are continuations of the short description. (3.4.2)
• Extended descriptions which fail to state what the package does. (3.4.2)
• Extended descriptions which fail to state how the package relates to the rest of the system. (3.4.2)
• Extended descriptions which only make sense if you already know about the things the package deals with. Extended descriptions must make sense even to people "who have no idea about any of the things the package deals with." (3.4.2)

The further requirements in http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description are, in short:

• Lines starting with a single space are paragraph wrapped.
• Lines starting with two (or more) spaces are verbatim, and are not wrapped to the extent possible.
• Lines consiting of space-period are rendered as blank lines.
• Tab is not allowed (but this is probably something best checked for by machine, so we shouldn't worry here).

Other

• Descriptions that do not really describe what the package does
  • The description must include enough details for the user to know what it is about. If the package is related to another one (foo-data, for example), the package does not have to repeat what foo is... but it has to explain how it relates to foo anyway. Also, when there are several versions of a package available, that should be explained. (Example that needs fixing: bash vs. bash-minimal)
• Hyperbole
  • Stuff like "this package is the best in the world"
• Stuff not interesting for the user
  • "foo was written by me "
  • "bar was written while its author had a broken leg"
  • generally speaking, anything irrelevant to the decision of installing or keeping the package installed.
• Inappropriate tone
  • Many package descriptions are "joking", or are even scornful. This should definitely be avoided.

• Kernel features: some packages use special features from the kernel. The description should state whether the stock kernels are correctly configured or which options/modules/patches have to be applied to get the features. ?URLs and pointers to module-assistant and kernel-package recommended.

Controversial stuff

• Technical details about the implementation of the program

A consensus might be that some details are OK/needed, but that should remain reasonable.

Generally speaking, these details should rather be at the end of the descriptions, after describing what the package is/does, or at least not be too intrusive.

• Worse: "Foo is a Python tool which uses libbar. It can frobnicate baz"
• Better: "Foo is a Python tool to frobnicate baz. It uses libbar."

Suggestions

• The package description could explain the main difference/advantage of the package from/over other packages serving the same purpose. Some package descriptions already do so.

Automatically discoverable mistakes

Please list here the most common mistakes you have seen, so their discovery can be automated. For these mistakes, do not mark the package as incorrect. Lintian checks will be added for them.

Rules which can never be broken are best for automated checking. Rules which may indicate that something is wrong, but which will sometimes misfire, are heuristic, and might in the end not be suitable for Lintian checks.

Rules

• Incorrect case for acronyms
  • GNOME
  • GTK
  • Qt for the Trolltech toolkit (correct), rather than QT (incorrect)

  • QT, rather than Qt for ?QuickTime

  • SSH
  • LILO
• Incorrect names of things

  • X server, not Xserver, ?XServer, or X-server

  • X Window ?System, not X Windows ?System. Branden has been known to bite people's heads off who get this wrong. Beware.

  • [list others]
• Possibly some of the spelling errors from below

Heuristics

• Short description starts with "This" or "It"
• Short description ends in full stop
• Short Description Uses Title Case
• Long descriptions beginning with "It"
• Short description starts with an upper case letter. (?)

  • There has been at least one flame war on debian-devel over this. Even if we were to agree to start short descriptions lowercase (which I ?anthony think is a good idea), ones starting with proper nouns need to be left uppercase.

• Long description starts with a lower case letter.
• Very common spelling errors
  • American un-English
    • "definate" pro "definite" (and derivations and inflections, i.e. definitely, definitive, definitively, definiteness ...)
    • "seperate" pro "separate"
    • "grammer" pro "grammar"
    • [list others]
  • Franglish
    • -nnal pro -nal, -nnal(l)y pro -nally
    • [list others]
• Use of assymetric ASCII quotes ` and ' ?
  • Sounds like a flamewar waiting to happen on debian-devel --- anthony.

  • Strictly speaking, you'd need to move to Unicode to get this right. // era

Volunteers

If you want to help, please register your name here and/or drop a mail to zorglub _a_t_ diwi _d_o_t_ org

• Clément Stenac (?zorglub)

• Anthony ?DeRobertis (anthony@derobert.net)

• Margarita Manterola (Marga)

• Christine Spang

• Alexander Schmehl (?Tolimar)

• David Riebenbauer (DavRieb)

• era eriksson

• JeremiahFoster

• Kevin Kubasik (kkubasik)

• Johannes Werner (?joewerner)

• Johannes Zarl (isilmendil)

• Benjamin Eastep (shifting)
• Peter vd Weijden (pWeijden)
• Mohammed Adnene Trojette (adn)

• David Schmitt (wiki:Self:DavidS)

• Justin B Rye (jbr)
• many others (hopefully)

An IRC channel has been created : #debian-descriptions on Freenode. I think it could be useful (and nice, too). Feel free to join

There is a mailing list

XXXXXXXX TODO: instructions for joining

The list is now carried (and archived) by the Gmane mailing-list-to-news-to-web gateway. You can read the list via your newsreader or in the web interface at http://dir.gmane.org/gmane.linux.debian.devel.package-descriptions but to post, you need to be subscribed to the list.

How to use the web interface

(Comments on the tool and ideas for how to improve it can be added to the PackagesDescriptionsReviewTool page.)

First of all, you need to pick a login ID. No authentication is provided, its only use is to know who made reviews.

Now, you can do a proper review, or you can just browse.

Review

Select a section to begin working on. Sections with many packages have been split up into smaller chunks.

• Remember to mark the section as taken in the table below.

You are then taken to the main review page. For each package, you can enter a status "Ok", or "Needs fixing" and a comment. (Two review fields are provided).

If the text needs fixing, please also indicate the severity of the problem. There is a legend near the start of the page with suggestions for how to assess the severity.

If you want to enter additional comments, work on a proposal, or comment on the current proposal, you need to go to the package details page by clicking the package name.

• Remember to update the section's status in the table below when you finish.

You can add non-review comments and work on proposed changes even if you're not actually reviewing. See below.

Browsing

As above, but don't sign up for reviewing, and don't put anything in the Review fields. If you find something to comment on, click on the package name to get to the details page for that package, where you can write free-form comments, etc.

The comments will show up as a "+ comments" flag in the status field on the index page; the reviewers will hopefully notice this, and may even read your comment already during the review stage.

Once the current texts have been assessed, the "additional comments" and proposal fields are where the actual action is going to take place, presumably, but we're still working on the process ...

Dividing up the work

Top priority should be given to desktop applications (gnome, kde, x11, ...) Lowest priority sections are libs, devel, ... and generally speaking stuff users don't often search for.

On the other hand, if you are unsure where to begin or what to do, perhaps starting out with a small, low-priority section would feel safer. (If you're not feeling ready for it, you don't have to be the first reviewer, though; feel free to just add comments via the "package details" page. See the "browsing" notes above.)

Large sections have been split up into four pieces. Pick one piece at a time. (Sorry, the tool doesn't tell exactly how large each piece is, so the listed number of packages is just exactly 1/4 of the total. Feel free to fix these approximate numbers if you're editing the entry for a particular section anyway.)