[Catalog-sig] Rating feature
"Martin v. Löwis"
martin at v.loewis.de
Sat Oct 3 19:57:47 CEST 2009
> 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(
user_name TEXT REFERENCES users ON DELETE CASCADE,
PRIMARY KEY (name, version, user_name),
FOREIGN KEY (name, version) REFERENCES releases ON UPDATE CASCADE ON
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
> 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
> * 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> -- 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
> * 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.
More information about the Catalog-SIG