Categorization of packages (was Re: Aptitude, ARs)

[Enrico Zini]

--qtZFehHsKgwS5rPz
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Cc-ing to deb-usability-list]

On Fri, Mar 28, 2003 at 12:05:25AM -0800, Osamu Aoki wrote:

> > Before the wish list, I propose to do a step back and do some task
> > analysis.
> Also after this we need to prioritize them considering efforts needed to
> achieve them.

You mean efforts for doing the task analysis or efforts to implement the
outcoming proposals?


<brainstorm>

<note>
I'm maintaining an updated HTML version of this ongoing brainstorming in
the Debian Usability Research web pages at:

	http://deb-usability.alioth.debian.org/pkgman-brainstorm.html
</note>


> I think these "User" thing can be summarized in 3 coordinates
> User::Skill::Developer/Experienced/Intermediate/Newbie
[...]
> At this moment, I think this can be one "User".  Debian User :-)

Yes.  My intent was not to produce an exact taxonomy used to put a label
on our users, but instead to build a list so that we do not forget about
someone.  Kinda like the goal of the User Analysis proposal I've made
recently.


> Instead of addressing "User" factors,  we may be able to assign
> "Relevance" attribute of each package for the typical uses.

Maybe this is best addressed by subprojects/metadistros/flavours
altogether?  I see much potential in that direction.


> >  * Purpose of the application
> I guess you mean purpose of package management application.
> It is:
> 1. to reduce task by the System administrator of any skill level and
>    orientation, and
> 2. to provide information to the administrator and normal user for the
>    availability and usefulness of the package.

I like this description!


> >     - See what kind of problems or tasks have some package in Debian
> >       that address them (what can I do with all these packages?)
> I think "Topics" used by sourceforge is very good starting point for the
> choice of "Topic".  Also "Task" used by Debian is another.
> See http://people.debian.org/~osamu/pub/osamu-cat.txt for example of
> these Topics.

Yes, that's a great candidate for a starting task list.

The experience will probably show other tasks not covered in that list
(Web CMS and Wireless LAN already come to my mind), and they'll
probably come is as bug reports or other feedback.  We need to keep a
door open for the possibility to fit new tasks in.


> >     - Examine the different alternative implementations for a given
> >       feature (what choice of word processors do I have?)
> This is basically way to present equivalent packages as an alternatives
> under the menu entry for virtual package.

Yes.  Is the current virtual package system enough for such a feature?
I explain: afaik it's designed to cover the need of application
dependencies, not of user tasks.

For example, rcalc does not "Provides: calculator", since there is no
package that has a dependancy on a calculator application.  However, I
can imagine that some user would like to browse the different
alternatives of calculator applications.

</brainstorm>


> > At the LCA2003 BOF, in the limited time we had, we came out with these =
ideas
> > for improving package metadata:
> >  - More than one section (tag/category) per package
> Yes and no.

What do you mean?


> > I think, however, that the time has definitely come to start to
> > seriously address this kind of user-centered technical problems.
> In order to address these issues, I think most important parts is
> creating infrastructures and guide lines to generate compact data to
> address user needs.

What kind of data are you thinking about?  And in what sense "compact
data"?
=20

> After thinking more on this issue,I realized the issue in "volunteer"
> project like Debian is to create and maintain good database to address
> above concerns.  I think "popcon" like voting system which not only
> collects installed package and their objective usage records but
> collects more feedbacks from user how the user rate each program
> installed and how relevant each programs are, may be needed to produce
> these information.=20
> 1.  People sign up from web and receive key with e-mail
> 2.  People run simple voting program and assign some key words and
>     rating for each package which they installed on their system.
>     (Sourceforge like Topics entry)
> 3.  E-mail it to server with key. (Some signing involve here)
> 4.  Tally them to create a list which can be used by menu system.

Yes, that kind of infrastructure is definitely something we need.

However, the polls must be carefully designed in order not to restrict
the user base (in your case, to the ones that are able and want to sign
into a web page, then receive a key via mail and feed it to a voting
program), or we should at least be aware of those restrictions and
consider the data accordingly.

Do you already have some polling ideas?


Bye,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

--qtZFehHsKgwS5rPz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+lbUD9LSwzHl+v6sRAvu/AJ4jqnjblIB7l0zh5noOiCllXQAtFQCbB1SV
tLoC6Icq2/joNRA/UFmHY5s=
=tI5p
-----END PGP SIGNATURE-----

--qtZFehHsKgwS5rPz--