Differences between revisions 9 and 10
Revision 9 as of 2009-11-04 19:39:44
Size: 4347
Comment: Remove the option which I don't understand.
Revision 10 as of 2009-11-13 01:11:56
Size: 4357
Comment: Grammar fixes
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
The Python Package Index currently provides a feature where users can comment on individual packages. Some package maintainers are opposed to such a feature, and would like to leave activation of the feature the maintainer. Along with comments, there is also support for rating the package with a number of 0..5. This page discusses arguments in favor and against per-package comments. The Python Package Index currently provides a feature where users can comment on individual packages. Some package maintainers are opposed to such a feature, and would like to leave activation of the feature up to the maintainer. Along with comments, there is also support for rating the package with a number from 0 to 5. This page discusses arguments in favor and against per-package comments.

The Python Package Index currently provides a feature where users can comment on individual packages. Some package maintainers are opposed to such a feature, and would like to leave activation of the feature up to the maintainer. Along with comments, there is also support for rating the package with a number from 0 to 5. This page discusses arguments in favor and against per-package comments.

There is also a discussion on Catalog-SIG starting with an email by Martin (who implemented the feature) and continuing in the November archive.

Pro comments

  • users posting a rating not only want to indicate whether they like or dislike the package, but also why they rated the package in the way they did.
  • restricting users (not allowing them comment on certain packages) can be considered as a form of censorship
  • spam is largely prevented by requiring user to login; if spam (i.e. completely unrelated comments) are made, they can be deleted.
  • if users use the facility to report bugs, the package author should have more clear directions to point users to the bug reporting channels
  • new comments will be emailed to the maintainers to notify them

Contra comments

  • maintainers need to check one more place for discussion of the package, in addition to mailing lists and fora that they already operate; people are too lazy to research what the proper comment reporting channel is.
  • if PyPI would allow individual packages to opt out of commenting, then comments would still be possible on packages that want them (or don't mind receiving them).
  • if comments get posted, the maintainer should have the ability to delete comments that are inappropriate.
  • preventing commenting isn't censorship; people are free to comment on as many other websites, blogs, forums, as they like... and if relevant to the package, they'll be found by Google
  • Requiring spam handling to go through a central authority makes two people (author + PyPI maintainer) do the work that could be done by one... or not at all.
  • "Completely unrelated" comments are only one form of spam; consider, for example the Twitter campaign urging people to post negative comments on setuptools to express a political viewpoint about its maintenance process, rather than commenting on the software itself
  • The feature itself does not encourage quality comments, due to the small space and lack of formatting/editing.
  • Early use of the comment feature suggests that low-quality comments are likely to be the norm: providing little useful information to users and poor feedback to package authors.
  • MvL notes that the comment feature was specifically requested as a way for people to leave public *negative* comments about packages - not to provide informative discussion or feedback.
  • Contra MvL's arguments, users do not have a "right" to display their gripes on a package's listing, any more than they have a "right" to scrawl grafitti on a restaurant wall to criticize the food. They have a right to comment and complain, but that can be equally served by simply sending their feedback directly to the package author, rather than permanently displaying one side of that conversation.

For more contra arguments, see also this Sourceforge issue with input from many package authors and community members.

Poll

At some point there will be a public poll to determine what users think of the rating and commenting features. Possible voting options may be:

  • keep the rating and commenting features
  • keep the rating and commenting features, and also allow package maintainers to select whether or not they wish to have commenting enabled for their package
  • keep the rating feature, and modify the commenting feature to only send comments to authors -- not publish them
  • keep the rating feature but remove the commenting feature
  • remove the rating and commenting features completely -- they may or may not belong in a separate web application, but they do *not* belong in a module distribution index

PyPIComments (last edited 2009-11-13 01:13:18 by AndrewKuchling)

Unable to edit the page? See the FrontPage for instructions.