RFC: fix summary text for lots of packages

[Michael Schwendt]

On Sun, 23 Nov 2008 11:04:13 +0100, Andrea Musuruane wrote:

> > Many, *many* people (except for fan-boys and people who are told to search
> > for a specific brand) don't care at all about the name of a program when
> > searching for a program. When they see the word "Thunar" it doesn't ring
> > any bell. Instead, it makes them nervous as they don't know whether it
> > matters to know what "Thunar". It could also be a special environment
> > which they don't know and don't want. Adding the program name makes such a
> > summary (and in turn the package) less attractive to these people. With
> > the shorter summary "File manager" they are more willing to try out the
> > software they don't know yet.
> 
> If what you say was true nobody would search and use Microsoft Office,
> Adobe Photoshop, Internet Explorer, Oracle and even Coca Cola.
> 
> Sorry, you are plain wrong about this. We live in a world of branding,
> where branding recognition is important and it starts from the name.
> 
> Many Open Source organization do branding too! Firefox, Samba, Fedora
> and MySQL and brands and their controlling organizations promote these
> brands.

You're missing the point, however. I don't say branding isn't done.
I don't say that brand recognition is unimportant to some vendors.
I don't say that users never learn all the different names and brands.

I'm talking about beginners, the newbie-friendliness of Fedora, and
the interface to the growing number of packages in the repositories.
About [Fedora] Linux newbies, who are confronted with (1) the task of
finding the counter-piece for every program they are familiar with on the
platform they've used before and (2) the task of finding new programs in
an overwhelming collection of several thousand packages or in a default
installation.

Give them a task, such as resizing an image. They won't search for a
specific program name, but for generic terms and phrases. "Image viewer",
"resize images", "image manipulation". They won't find "Photoshop" or
"IrfanView" anyway. "AbiWord" (which is a trademark) is advertised
upstream as "a free word processing program similar to Microsoft® Word".
They won't find it with a %summary that doesn't mention "Microsoft Word",
but they find it when searching for "word processing". For many types of
programs, the Open Source solution has a different name than what users,
who come from other platforms, are used to. Don't hide in the small world,
where you know all the sometimes weird names and acronyms for lots of
packages.

Samba -- a great example. Its summary says "The Samba Suite of programs",
which won't be found by any user who wants to set up "a network share" or
"share a printer". Only by searching and reading the package description,
which expands on what the Samba suite does, they would recognise this
package as one they might want.

It's all different the more experienced [and or knowledgeable] a user is.
Indeed, an experienced user would search for specific database suites,
such as PostgreSQL or MySQL. These users would be satisfied with a simple
mapping of package names to program names/acronyms:

  firefox : Mozilla Firefox
  gcc : GCC
  gedit : gedit
  gthumb : gThumb
  mysql : MySQL
  postgresql : PostgreSQL

:) 

It isn't trivial to come up with good one-line summaries that do more than
repeating the program name. It's nothing packagers like to spend time on.
Reducing a packager's freedom even further won't be a good thing. The
size limit is hard enough already for some packages and sub-packages.
Why is 

  gedit : gEdit is a small but powerful text editor for GNOME

better than
  
  gedit : Small but powerful text editor for the GNOME desktop

? (btw, upstream calls it "gedit" not "gEdit")

I think with some people one could argue endlessly about pkg summaries.
And during pkg reviews that's wasted time. Still, with very old repositories
it has been noticed [and agreed on, mostly] that some types of summaries
simply look poor in Anaconda and package management tools. That was the
rationale for some of the recommendations.