Ratings and reviews in software-center
To make software easier to choose in the Ubuntu Software Center, Launchpad should record ratings and reviews for applications and binary packages, submitted to it by users with an Ubuntu Single Sign-on account via the Launchpad API. There should also be a moderation system for speedy removal of inappropriate reviews.
Ubuntu Software Center specification: https:/
Launchpad specification: https:/
Blueprint information
- Status:
- Started
- Approver:
- Robbie Williamson
- Priority:
- Essential
- Drafter:
- Michael Vogt
- Direction:
- Needs approval
- Assignee:
- Michael Vogt
- Definition:
- Approved
- Series goal:
- Accepted for natty
- Implementation:
-
Deployment
- Milestone target:
- None
- Started by
- Robbie Williamson
- Completed by
Whiteboard
Actual specification: https:/
Work items (natty-alpha-2):
[mpt] (design) finalize ratings+reviews wireframes: DONE
(client) add star summary to applist: DONE
(client) add nr-reviews to applist: DONE
(client) add ratings&reviews to details view: DONE
(client) download review summary and cache properly (including review stats deltas): DONE
(client) implement protocol for submit review: DONE
(client) implement protocol for report inappropriate: DONE
(client) ensure that the i18n is done correctly: DONE
(client) add spellchecking to submit review and report abuse: DONE
(client) add gwibber/twitter support: DONE
[isd] (server) define datamodel for reviews (pkg/app, version, distro, origin, etc): DONE
[isd] (server) define datamodel for "this review was helpful" (even if not exposed in the UI/API initially) - done and exposed (rnrclient has a report_abuse() method): DONE
[isd] (server) define API that allows getting reviews strict (only for matching lang, version, distro) and fuzzy (rnrclient has get_reviews(
[isd] (server) define API that gets stats about all available reviews locally. Although rnrclient hasn't yet been updated - created bug 688114: DONE
(policy) define process for moderation of inappropriate reviews (like how many reports does it need before a review vanishes, who moderates, what about spam): DONE
(design/policy) define guidelines for good reviews https:/
(design/policy) define guidelines/CoC for moderators (what is inappropriate) https:/
[mpt] (policy) Do we need licensing of the reviews? Using a default CC license?: DONE
Work items (natty-beta):
(client) ensure reported reviews do not show up on the client any longer: TODO
[mpt] (design) get approval from Otto for the pixel design: TODO
(client) cache downloaded reviews and ensure proper etag is used: DONE
[isd] (server) add spam filtering hooks and not linkify reviews: TODO
(server/client) support edit/update a review (for a certain time?): POSTPONED
(server/client) support special reviewers (OMG! Ubuntu!, ars technica): POSTPONED
[isd] (server) API to show top reviews/top reviewed apps (I think top-reviewed apps will be done on the client?, and the reviews for an app are returned in batches (using pagination), currently with the most helpful ones first. But rnrclient doesn't yet support pagination - updated bug 688114 with this info: DONE
[isd] (server) initial limit the scope to archive.
(client) hook into launchpad-
(design/policy) Update the SRU policy to allow USC updates: TODO
(client) Release USC 3.2 in Ubuntu 10.10: TODO
----
[Copied from Gobby document: packageselectio
Demo of Software Center client work by mvo.
- Star ratings,
- Writing reviews (summary, detail and rating).
- Reporting of reviews as innappropriate.
On the server-side, a review will need to be for:
- an application
- a version
- a distroseries (as even the same version in different series).
Questions
=========
* How to avoid bad data - can we allow reviewers to create/contribute meta-data (categories, etc.). mpt: that's separate.
* Can we add a 'This was a helpful review'? Yes - needed.
* Can the reporting of innappropriate reviews not be abused? Yes, need thought as to, for example, requiring 2 reports before it is hidden and added to the moderation queue.
* Will reviews persist between application versions? Show reviews for the current version, but with access to reviews from previous versions.
* A downside here is that we may lose (hide) a "valuable" review that may actually still be perfectly relevant, just because of a version bump
* Reviews should also be sensitive to origin of the package, in case one "version" might come from different source (e.g. PPAs)
* Languages - we need to support multiple languages. What should our defaults be? Should the server serve English reviews if there are no native language reviews? (Proposal: if there are no localized reviews yet, show a note: "Be the first to add a <language> review!")
+ If we default to English when no native-language reviews, maybe show a button to "See all language reviews"
* Spam filtering on the server-side? Yes - we may need something. We will not linkify in comments (and may disallow links entirely).
* Will we be able to edit/update a review after adding it. Yes, for 10mins or so (otherwise the 'Was this review helpful' is incompatible).
* Would we be able to have special reviewers (OMG! Ubuntu!, arts technica)
* Using Karma or CoC for moderators? Proposal: not unless we have a simplified/
* API for other websites to show top reviews etc.
* Do we need licensing of the reviews? Using a default CC license?
* Evan would like to see metrics like bug-count, crashes, install count, delta between when a bug is reported to when it is fixed (help?)
* Initially mvo would like to limit reviews to commercial apps and distro apps, not random PPAs, but the infrastructure needs to support PPAs in the future.
* Should vendors be able to opt-out of reviews? (perhaps restricted to commercial apps/apps where we can know who the vendor is).
* Can we do something similar to the 'launchpad-
* Can Vendors/authors respond to reviews?
* Hooks to allow an application to provide in-app review ability? Maybe from an About dialog?
* If a user uses an application a lot, maybe pop up an invitation to review it
+ If we do this, would we end up with tens of thousands of reviews for a single app, which is not so useful?
+ What about command-line apps, such as "ls"? :)
+ Pop-ups should not interrupt the user's workflow
