> 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 _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
