[Catalog-sig] Rating feature

["Martin v. Löwis"]

> A few thoughts:

Thanks! that's a lot of feature requests. If any of them are
particularly important to you, please add them to the tracker.

> * On hgsvn I see some points, but no indication on the scale.  That is,
> there's 1 and 2 points, but out of... 5?  Once I'm logged in I can see
> the scale, but not until then.

This is now fixed.

> * There's a bunch of different ideas on how to average scores.  I don't
> have an opinions at the moment, except that we keep enough data to
> change the algorithm in the future.  Specifically the score, user, date
> (i.e., not just aggregate information).

Most certainly. Currently, I have

CREATE TABLE ratings(
   name TEXT,
   version TEXT,
   user_name TEXT REFERENCES users ON DELETE CASCADE,
   date TIMESTAMP,
   rating INTEGER,
   message TEXT,
   PRIMARY KEY (name, version, user_name),
   FOREIGN KEY (name, version) REFERENCES releases ON UPDATE CASCADE ON
DELETE CASCADE
);

Keeping individual ratings is already necessary because users can also
withdraw their rating.

> * I expect the comment/rating activity to be relatively low, so throwing
> everything away on every release seems problematic.  For comments
> specifically it would be nice if they remained, though maybe old
> comments could be hid by the maintainer (or by anyone?)  Hiding might
> just put them in a place where they were hidden (visible with a
> Javascript control).  Scoring I'm less sure about; you could weight
> scores according to their distance from the current release.  Or throw
> them away as you are doing now; I'm generally less concerned with
> scoring than comments.

Users have a fairly easy user interface to forward their comments from
a previous release. So if the comment still applies, and they care, they
can repost it.

Again, people proposing the feature made a point that per-release
comments may become invalid with newer releases, so I think they do
need to get reevaluated by the authors. One option could be to have
a checkbox to post an "eternal" comment; I'd postpone that until
users actually request it.

> * Since people can and will report problems (like with hgsvn), it would
> be nice if the comments were threaded so that problems could be
> responded to.

How does that work? Would each comment have an "in-reply-to" field?

In any case, this sounds complicated to implement.

> * Because people report problems anyplace they can, this is going to be
> hard for some maintainers, because there will be unanswered questions
> the maintainer won't be aware of.  Emailing new comments would be really
> helpful (maybe as a user preference).

This is now fixed; they get emailed unconditionally, to all Maintainers
and Owners.

> * Comments on Trove classifiers would be nice.  Though right now the
> classifiers are too hard to find and the actual categories not well used
> or complete enough.  But if they *were* well used, this would be a place
> for people to put comparative comments (e.g., on this page for XML:
> http://pypi.python.org/pypi?:action=browse&show=all&c=500
> <http://pypi.python.org/pypi?:action=browse&show=all&c=500> -- but
> getting to that page was really hard).

I don't quite understand. You want to comment on a trove classifier?
Like commenting on "Topic :: Text Processing :: Markup :: HTML"
"This is way better than XML"???

I don't understand why you say they are hard to find: the list of
classifiers is linked on each and every PyPI page, as
"List trove classifiers". What do you mean?

> * Generally I think it would be a lot more useful to people finding
> packages if there were topic guides, which would have a description of a
> class of tasks (like parsing XML) and a user-curated list of packages
> that apply.  In theory the wiki could be used for this, and people try
> to use it for this, but it's not very successful
> (e.g., http://wiki.python.org/moin/WebFrameworks -- which is a lot
> better than it has been at many points in the past).  Having a list of
> packages with the age of the last release, the score of the package,
> Development Status trove classifier, the short description from PyPI,
> etc. would make a much nicer list.  But it has to be curated -- package
> maintainers don't consistently use package metadata well enough to make
> this work.

I don't think this can possibly work. Each and every directory that
was user-maintained has failed, AFAICT; wikipedia is the only exception
(and only because it isn't *just* a directory).

So I would leave this in the realm of the wikis indeed. If users care
to contribute - fine. If nobody cares, then users will have to find
relevant information themselves.

> * Can you not comment on your own packages?  Not scoring is fine, but
> comments should be available.

I guess this goes along with the threading. For plain comments, I
wonder why you couldn't put what you want to say into the
long_description (which also makes it part of subsequent releases).

> * It would be nice to have a field that links to an issue tracker or
> forum of some sorts, and display that right next to the comment box,
> like "If you have an issue use <project's issue tracker>".

For the package, or per release? If it is per release, you need to
get this into distutils also, and it would be subject to distutils-sig.

In any case, this is out of scope and independent of the rating feature.

>  hgsvn is an
> example of when that isn't used.  Alternately a field that would render
> right next to the comment box (ReST) where the project can give
> instructions (like: if you need help, jump on #project on
> irc.freenode.net <http://irc.freenode.net>, or `submit a bug <...>`_ or
> `search our mailing list <...>`_).  Free text would probably be better,
> as it gives full flexibility.

That sounds like overkill - people can already put that into
long_description (and typically do). Just make a ReST section
Reporting Bugs.

> 
> * Less flexibly, a default message about what should go in comments
> would be helpful.  I'm not sure what the description should be, but just
> "comment" isn't enough IMHO.

If you propose a text, I'll likely copy it literally.

Regards,
Martin