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

Re: RFC: Keywords - Aptitude has similar solution included

On Thu, Nov 15, 2001 at 11:47:18PM +0100, Erich Schubert wrote:
> That is why i don't want to categorize them myself. This should really
> be done by the package maintainers themselves, they know their software
> best. Until they updated their package, the package manager can of
> course use an override file (which could then be used for building the
> mirrors and get the data into the mirrors that way, as with Task: ;).

I'm not so certain about this.  The package maintainers may be narrowly
focused on their own use/packaging of the software and have little concept
of "big picture" issues like how people would go about finding it.  It
is often the case that the closer you are to a problem the harder it is
for you to remember what it was like to not know the answers.  Applied to
this situation, the closer you are to a package, the harder it is to
remember what it was like not knowing how to find it. :)

Saying "the package manager can override" finesses the problem.  Who would
be responsible for managing the overrides?

Everyone has their own take on how things should be classified.  A keyword
approach is nicer than a strict tree organization because it allows for
multiple, non-mutually-exclusive views of the same data set.  But choosing
good keywords is not a skill that everyone posseses.

That doesn't mean maintainers shouldn't at least try to hone this skill.
But they will definitely need clear guidelines and a ready-made set of
keywords to choose from.

Having made that initial choice, though, I think the task of maintaining
a good set of keywords per package then needs to be handed to a group
of people possessing in high degree the "good keyword choosing" skill
set.  They should be able to modify the package maintainers' choices
quickly, conveniently, and without having to bug the original package

Here are some thoughts on why we need such a team:

- Language:

  - What is a good keyword in english won't necessarily be a good
    keyword in other languages.

  - A strict one-to-one translation of each english keyword into a
    foreign language keyword may be awkward, leading translators to
    choose keywords with different shades of meaning, which may
    be broader or narrower than the english one.  So the translated
    keyword set may actually not have a one-to-one correspondence
    with the english.

  - It seems that the burden of providing sensible keywords in other
    languages therefore must rest entirely in the translators'
    hands.  We can't expect the developers to be responsible.

- Other groups with specialized needs:

  - Debian Jr. has long discussed how children may find adult
    categorization of programs to be foreign, and therefore may
    require a different view of the packages.

    - We were talking about the menus, not the package browser,
      but the concepts are similar, so my example holds.

  - In general, do we address the different classification needs
    of different subgroups of users?  It seems each subgroup,
    where it has representatives within Debian, needs to have
    its say.

- So, who manages the keyword select process, then?

  - In the very worst case, there are as many different points of
    view as to how things should be categorized as there are Debian

    - If every user submitted their own personal keywords to attach
      to each package they used, we would have a very rich set of
      keywords to choose from indeed.

    - I think it is clear, though, that the noise level would rise
      so high as to render such an effort useless without some
      filtering of submissions.

    - Some sort of "vote" system might be implemented for user-
      selection of "good" keywords, however, so this idea shouldn't
      be discarded immediately as preposterous and unmanageable.

  - Somewhere in between, there are as many different points of
    view as to how things should be categorized as there are Debian

    - If every developer submitted their own arbitrary keywords to
      attach to each package they packaged, again we would have a
      rich set of keywords, but not quite as large and unmanageable
      as the user-provided set.

    - The trouble is, you end up with potentially disjoint and
      incomplete classifications, as you only have one point of
      view per package.  The user model gives more points of view
      and therefore has a better chance at turning up keywords
      that will help new users find the package they are looking

    - This idea can't be totally discarded either, though, as
      the combination of a clear set of guidelines with a large
      set of pre-selected keywords to choose from (or maybe
      even a tool that suggests keywords from a pre-selected set
      based on grepping through the package for clues) might
      help the maintainer come up with a half-decent initial
      set of keywords.  (An incomplete set of keywords is better
      than no keywords.)  But then, who makes the policy?  Who
      makes & updates the pre-selected keyword list?

  - At the other extreme, a single person representing all of Debian
    decides on all possible categorizations and imposes his or her
    classification on the entire set of packages.

    - This person must possess god-like qualities, seeing all, knowing
      all, and having limitless time & energy to keep up with the daily
      influx of packages into Debian and emerging new subgroups of users
      with differing classification needs.

  - Finally, some happy medium, I think, is possible if a "crack
    team" of classifiers is assembled to manage the package
    classification process.  This team needs:

    - Strong leadership of one person who gives final arbitration
      on keyword classification disputes and generally ensures the
      team continues to function smoothly as a team to get the job

    - Some way of making use of and giving guidance to developers
      who select that initial keyword set for their packages.

    - Some way of collecting & making use of user submissions.

    - Coordination with translators to keep the classifications
      sensible/manageable for the translators.

    - Coordination with special interest groups within Debian
      (e.g. debian-hurd, debian-jr, etc.) to tag groups of
      packages with keywords that make sense to that group.

    nSLUG       http://www.nslug.ns.ca      synrg@sanctuary.nslug.ns.ca
    Debian      http://www.debian.org       synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Reply to: