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
maintainer.
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
users.
- 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
developers.
- 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
for.
- 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
done.
- 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.
Ben
--
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: