This is a living specification for ratings and reviews in Ubuntu Software Center.

Ratings and reviews are a way for Ubuntu users to communicate with other Ubuntu users about software. They are not specifically a means of communication with Ubuntu developers or application developers.

Rating and reviewing software involves three software components:

  1. (1) Ubuntu Software Center itself

  2. (2) the review service, an Internet server that receives, stores, and publishes reviews

  3. (3) the Ubuntu Single Sign-On service.

Use cases not specified yet

  • Displaying reviews
    • on an Ubuntu Web site
    • on the software vendor’s Web site
  • Removing a review
    • because of its content

Which packages have ratings and reviews

(bug 858092)

Any item in an official Ubuntu or Canonical archive — for example, Main, Universe, Partner, Independent, or For Purchase — should be able to have ratings and reviews.

Items in third-party archives, including other PPAs, should not have ratings and reviews.

Submitting a review

This process begins when you activate the “Review…” button on an “Installed Software” item screen.

Ubuntu Software Center should first ask the (3) Ubuntu Single Sign-On service to ensure you are signed on, using the summary text “To review software, you need an Ubuntu Single Sign-On account.”.

Once you are signed in, a dialog should appear for submitting the review. This dialog should not have a parent window, so that you can refer to other reviews and other items while writing your review. This needs testing against focus stealing prevention in Metacity and Compiz.


This dialog should be resizable; resizing it should resize only the review text field. That field should be focused by default.

The dialog’s title should be of the form “Review {Item Title}”.

Within the dialog, first should be displayed the icon, title, and version number of the software.

Next should be a “Review by:” item showing your name as registered with the Single Sign-On service (as a subtle hint that you are accountable for your words). This label should act as the accessible label for the review text field, though visually it should be far enough away from the field to look like a separate element.

The review text field should accept multiple paragraphs, and should use automatic spell-checking.

The “Summary:” field should accept a single line of text.

The “Rating:” field should consist of five stars plus a caption. By default, no stars should be filled. Whenever the field is focused, the Left and Right keys should increase or decrease the rating in one-star increments, and the 1 through 5 keys should change the rating to that many stars. The caption should reflect the star you are mousing over, if you are, or otherwise the rating you have currently set: “” (no rating yet), “Awful” (1), “Poor” (2), “Adequate” (3), “Good” (4), or “Excellent” (5). Setting a rating level, whether using a pointing device or a key equivalent, should highlight the new rating in a similar visual style as when clicking a checkbox or radio button.

Above the commit buttons should be legal small print: “By submitting this review, you agree not to include anything defamatory, infringing, or illegal. Canonical may, at its discretion, publish your name and review in Ubuntu Software Center and elsewhere, and allow the software or content author to publish it too.” In the code, this string should have a comment that it should not be revised without approval from a lawyer.

While the review service is in beta, this should be followed by a second paragraph stating: “Thanks for helping us test the review service. While it is in beta, we can’t guarantee that all reviews will be retained.”

The “Cancel” button should have Esc as its keyboard equivalent.

The “Publish” button should have Enter as its keyboard equivalent. Choosing “Publish” should:

  1. make all controls except “Cancel” insensitive (they should stay insensitive until an error occurs or you choose “Cancel”)
  2. display progress with a spinner and the text “Submitting review…” in the bottom leading corner
  3. submit the review
  4. replace the spinner and text with a checkmark graphic and the text “Review submitted.”
  5. wait two seconds
  6. close the dialog.


If the submission is unsuccessful because of an error, then:

  1. All controls should become sensitive again.
  2. “Publish” should change to “Try Again”.
  3. The dialog should lengthen to make room for a mini error icon and error message just above the “Cancel” and “Try Again” buttons.

Submitting a review should send this information to the review service:

  • via URL, the name of the repository, package, and version number
  • your Single Sign-On credentials
  • the language of your locale.

The review service should return whether the review has been accepted, held for approval, or rejected.

If the review is accepted or held for approval, the review dialog should close, USC should automatically navigate to display the relevant software item screen (if it was not being shown already), that screen should scroll smoothly to reveal all of your review, and the background color of the review should fade from a “new” color to the standard color.

to Twitter and/or other sites too

If the available version of libgwibber is at least 0.1.0, and libgwibber reports that you have any broadcast accounts that can post text (e.g. Twitter or StatusNet, not Digg or Flickr), the review dialog should have a checkbox — between the legal text and the “Cancel” and “Publish” buttons — for posting the review to any one of those accounts. The checkbox should be off by default, but its state should persist across USC sessions.


  • If there is only one applicable account, the checkbox label should be of the form “Also post this review to {service name} ({user ID})”, for example “Also post this review to Twitter (@mpt)”.
  • If there is more than one applicable account, the checkbox label should be of the form “Also post this review to:” followed by a radio menu with items of the form “{service name} ({user ID})” for choosing which account to post to. The menu selection should persist across USC sessions.

Until libgwibber provides a way to determine the character limit for every account, USC should assume a 140-character limit for every account.

The end of the post should be a space character followed by the apt.ubuntu.com URL for the item. The remainder of the post should consist of as many characters of these elements as will fit into any character limit, starting from the beginning:

  1. the string “reviewed ” (which includes a trailing space), if it will all fit;

  2. the title of the item, regardless of whether it will all fit;

  3. the string “” (which includes a trailing space), if it will all fit;

  4. your rating, shown as five U+2605 and/or U+2606 star characters, followed by a space, if all of that will fit;

  5. your review summary, regardless of whether it will all fit.

If not all these elements will fit in the character limit, the post should consist of as much as will fit into one less than the character limit, with the extra character being used for an ellipsis (U+2026) immediately before the space and URL.

For example:

If you chose to post the review to one or more broadcast accounts, USC should not attempt to do that until it has posted successfully to the review service (otherwise it would be posting a link to a review that wasn’t there). While USC is posting to the broadcast accounts, the progress text in the review dialog should be “Posting to {Name of Service}…”, and the review dialog should not disappear until the review has been posted successfully to all of them.


If posting to the review service succeeds, but posting to one or more of the broadcast accounts fails, an alert should appear with the review dialog as its parent, no title, primary text “There was a problem posting this review to {comma-separated names of services that failed}.”, secondary text explaining the error if possible, and buttons “Cancel” and ”Try Again”. If you choose “Try Again”, the alert should close, and USC should try to post the review to all services which failed last time. If you choose “Cancel”, both the alert and the review dialog should close.

in another language

(1) For now, Ubuntu Software Center should assume that you are writing the review in the same language Ubuntu is using in its interface, and it should specify that language when submitting the review.

(2) The review service should store the language specified for every review.

Can we auto-detect the language on the server side, like Google Translate does?

with empty review text or summary, or no rating

(1) The “Publish” button in should be sensitive only when there is text in both the review field and the Summary field and you have set a rating.

(2) The review service should reject with an error any review that does not have all of review text, summary, and a rating.

containing too much text

Review text should have at most 5000 characters, and summaries should have at most 80 characters.

(1) In Ubuntu Software Center:

  • Whenever the number of characters in the review field is 4900 or more, the maximum number of characters remaining should appear as a caption aligned with the trailing side of the field. Numbers from 100 to 50 should use the default text color; 0 or less should use the alert text color; and 50 to 0 should be a proportionate mixture of the two colors.
  • Whenever the number of characters in the review field is 60 or more, the maximum number of characters remaining should appear as a caption aligned with the trailing side of the field. Numbers from 20 to 10 should use the default text color; 0 or less should use the alert text color; and 10 to 0 should be a proportionate mixture of the two colors.


    Test case: Paste 5027 characters into the review text field. The number “-27” should appear in red. Hold down Backspace. The number should steadily increase. After it passes zero, it should steadily get blacker.

(2) On the server side, the review service should reject with an error any review that has too many characters in either field.

containing a very long word

There should be no limits on the length of the words used in a review. Any extra word breaking needed should be done when displaying reviews.

containing inappropriate whitespace

There should be no limits on the whitespace used in a review. Any whitespace collapsing needed should be done when displaying reviews.

when there is no Internet connection

(1) Whenever there is no Internet connection, the “Publish” button in any review dialog should be insensitive, and at the opposite side of the dialog should be a mini error icon and the text “Not connected to the Internet.”.

If there is a connection error of any sort while submitting a review, the “Publish” button should become sensitive again (unless there is no Internet connection), and at the opposite side of the dialog should be a mini error icon and the text “Couldn’t connect to the review service.”. That text should disappear when you next use any control in the dialog (for example, change the contents of any of the fields, or click “Publish” again).

for many programs in quick succession

Ubuntu Software Center should not attempt to limit the number or speed of your reviews. (Any attempt at flooding will likely be done outside USC anyway.)

(2) The review service should handle flooding appropriately — for example, by silently ignoring excessive numbers of reviews from the same person, and/or by automatically flagging them for review and possible mass deletion.

for the same software a second time

If you try to review an item and (1) Ubuntu Software Center knows that you have already reviewed that version of that item, it should behave as if you are correcting the review.

This might change in future, if we let people submit multiple reviews in different languages.

Correcting a review

If you choose to correct one of your reviews, (1) Ubuntu Software Center should pre-fill the review dialog with the review text, summary, and rating from that review. Whenever all of them are exactly the same as they were originally, the “Publish” button should be insensitive. If a revision is submitted, (2) the review service should treat it as a replacement for the previous review.

If someone has flagged a review for moderation, editing it should not cause the review service to clear those flags, but it should record the fact that the review was edited after the flagging. Should the review service record every version?

Presenting reviews

(2) The average rating for a software item, as shown to someone running a particular Ubuntu release, should be the mean of the last 50 ratings for versions of the software that are less than or equal to the latest version available for that Ubuntu release. straw-man proposal only


How can we improve this algorithm? We want to weight ratings for recent versions more heavily than ratings for old versions. We also want to avoid having most averages settle around 3 stars.

Throughout the “All Software” section, a list view item should have at its trailing end a hyperlink consisting of stars for the average rating for the item (rounded to the nearest half star), plus text of the form “17 reviews”. Activating the hyperlink should navigate to the software item screen and scroll to its “Reviews” section. In addition, text of the form “ (X stars from Y reviews)” should be present at the end of the item’s accessible description — for example, “An application for managing botanical collections (4 stars from 3 reviews)”.


When an item is being installed or removed, the progress bar in the list view should replace any rating/reviews link.

Similarly a software item screen should have in its top trailing corner a hyperlink of exactly the same form, which does the same thing. In the “Installed Software” section, this area should instead have a “Write a Review…” button that begins the review process.

The software item screen in both the “All Software” and “Installed” sections should also contain a “Reviews” section.

If there are no reviews, or if you have installed the current version of the software now or in the past, the first thing in this section should be a line of text:

  • “None yet.”
  • “None yet. Be the first to review it.”

  • Write your own review

Next should be (2) the five most relevant reviews for the item, followed by a “Write your own review” link. “Most relevant” in this sense means, of all the reviews you have not flagged:

  1. any review that you have submitted previously (regardless of version);
  2. any reviews for the latest version that is available for your Ubuntu release (sorted by helpfulness or recency, depending on the current sort);

  3. any reviews of the next most recent version available for your Ubuntu release, and so on.


The caption below a review should depend on whether USC knows that you’ve given feedback on the review, or that you are the review author.

But if you are signed in as the review author, it isn’t just the caption that should be different:

  • The review should have a slight background tint.
  • If the review is being held for approval, small print should appear between the summary and the review text: “This review won’t appear to others until it is approved.”.
  • The author’s name should be followed by “(that’s you)”.
  • The “Inappropriate?” link should instead be “EditDelete” links.

Choosing “Write your own review” when you have already reviewed this version of the software, or choosing “Edit” on your review, should display the interface for correcting the review.

Choosing “Inappropriate?” or “Delete” should display the relevant interface for flagging the review.

In the “All Software” and “Installed” sections, an item that has any reviews in a software list view should have a link consisting of (a) stars representing the average rating and (b) light text of the form “7 reviews”. Activating the link should navigate to the software item screen and scroll to its Reviews section.

from different versions of the software

If (and only if) the reviews shown contain any reviews of a version other than the current one, the “Reviews” section of the screen should have subheadings for “Reviews of this version (x.y)”, “Reviews of version x.w”, and so on.

containing very long words

If any word in a review is longer than a whole line, (1) Ubuntu Software Center should break the word at the end of the line. The main pane should not scroll horizontally.

containing inappropriate whitespace

When (1) Ubuntu Software Center presents a review, any series of consecutive whitespace characters that:

  • contains at least two line breaks of any sort (e.g. U+00A, U+000C, or U+000D) should be treated as a blank line and nothing else.

  • contains one line break of any sort should be treated as a line break and nothing else.
  • does not contain any line breaks should be treated as a single space and nothing else.

Test case: Submit a test review that contains two paragraphs separated by 50 carriage returns and a few tab characters. When displayed, the two paragraphs should be separated only by a blank line.

containing other-directional text

(1) Ubuntu Software Center should present each review using the direction customary for the language it is in. For example, an Arabic review should be presented from right to left.

sorted in different ways


(1) Opposite the “Reviews” heading should be an option menu with two options, “Most helpful first” (the default) and “Newest first”. Changing the selection should (2) request the appropriate batch of reviews from the review server, and display them in place of those currently shown.

“Most helpful” here means those reviews with the highest lower bound of the Wilson score confidence interval for a Bernoulli parameter for helpful versus unhelpful ratings, with a power of 0.2.

in different languages

(bug 834650)


(1) Opposite the “Reviews” heading should be an unobtrusive pulldown menu, with a globe as its icon, and accessible label “Review languages”. The menu should contain items for any languages and language families that have any reviews for this software item. The order of the items should be:

  • “All languages”;
  • your locale’s language/family, e.g. “English”;

  • a separator, if there are items both above and below it to separate;
  • any other languages/families, in alphabetical order.

For example, if your locale is pt_BR, and the current item has four reviews, three pt_PT and one en_AU, the menu should have items “Todas as línguas”, “Português”, a separator, and “Inglês”.

The initial setting for the menu should be your language or language family. If you change the setting, a spinner should appear next to the menu, until (2) the reviews in the newly selected language/family are loaded and replace those currently displayed. If the replacement reviews fail to load, the menu should return automatically to its previous setting. The menu selection should persist across items and across USC sessions.

when there are many reviews

When there are more reviews than are currently displayed, below those currently displayed should be a button, as wide as the whole reviews column but with subtle background and border, labelled “Show more reviews”. Activating the button should make it insensitive, change its label to “Loading…”, and load and fade in the next batch of reviews, below the ones that are already displayed. If there are even more reviews available, the button should slide down to make room for the new reviews, change its label back to “Show more reviews”, and resume sensitivity. Otherwise, the button should fade away completely before the reviews fade in.


when there is an error downloading them

If (1) Ubuntu Software Center tries to download a batch of reviews and fails (because the connection is interrupted, or it times out, or whatever), the label for loading more reviews for that item should change to read “There was a problem downloading reviews. Try again?”

when there is no Internet connection

(1) Ubuntu Software Center should update and cache the average rating, and the number of reviews, for all items in a software source whenever it updates the list of software in that source. It should update and cache the average rating, the number of reviews in each language, and the batch of most recent reviews for your current language setting, for an individual item whenever you visit the screen for that item and there is an Internet connection. The cache should have a maximum size.

If there is no Internet connection when you navigate to a software item screen for which there are reviews but none of them are cached, the part of the screen that would normally display reviews should instead say simply “Connect to the Internet to see {number of} reviews.”. If an Internet connection starts working while still displaying that screen, the reviews should load and appear in-place without moving the rest of the screen.

Similarly, when (but only when) there is no Internet connection while USC is presenting one batch of reviews and the next oldest batch is not cached, the button to load more reviews should be insensitive, and its label should be “Connect to the Internet to see more reviews.”.

Giving feedback on a review

The caption below a review should be:

  • If you’re signed in and you wrote the review, then of the form “X of Y people found this review helpful.” if anyone has given feedback, or blank if no-one has.
  • Otherwise:
    • if no-one has given feedback on the review, “Was this review helpful? Yes / No

    • if you are the only person to have given feedback, “You found this review helpful. Undo” or “You found this review unhelpful. Undo

    • if you and others have given feedback, then of the form “X of Y people found this review helpful, including you. Undo” or “X of Y people found this review helpful; you did not. Undo

    • if others but not you have given feedback, then of the form “X of Y people found this review helpful. Did you? Yes / No

If you are not signed in, choosing to mark a review as helpful or not (or choosing “Undo”, if you became signed out since it was displayed) should invoke the Ubuntu Single Sign-On authentication/process, using the summary text “To give feedback on a review, you need an Ubuntu Single Sign-On account.”.

Once you are signed in (or if you were already signed in), there should be no extra interface; your decision should take effect immediately, and the caption should update in place. If you wrote the review, your feedback should have no effect.

Replying to a review as the developer


If you are signed in as the developer of an application, below each review for that application that you have not already replied to, there should be a “Reply” link next to the “Inappropriate?” link.

Choosing “Reply” should temporarily replace that link with a reply form indented below the review, with the text field focused. As with reviews themselves, the “Post Reply” button should be insensitive whenever the text field is empty or over-full.

If you choose “Post Reply”, the text field and buttons should become insensitive, the “Your reply will be public.” text should disappear, and a spinner and the text “Posting…” should appear aligned with the leading edge of the text field. If posting the reply fails, the spinner and text should be replaced by an error icon and text “There was a problem posting the reply.”, and the controls should resume sensitivity.

If posting the reply succeeds, the form should be replaced by the reply presentation (fixing bug 1010444).

Viewing a developer’s reply

A developer reply should appear the same as a review, except that:

  • it is always immediately below the review it is replying to;
  • it is indented;
  • “Reply from developer” appears where the summary would normally be;
  • it is not possible to mark it as helpful or unhelpful.

As with a review, it should be possible to “Edit” or “Delete” a reply if you are the author, or flag it as “Inappropriate” if you are not.

Flagging a review as inappropriate

Flagging a review should first invoke the Ubuntu Single Sign-On authentication/registration process, if necessary, using the summary text “To flag a review as inappropriate, you need an Ubuntu Single Sign-On account.”. The dialog should also feature a “Just Hide It” button; activating this button should cancel the process, but Ubuntu Software Center should then also immediately hide the review and remember indefinitely that you do not want to see that review again.

review-report-sign-on.jpg review-report.jpg

You won’t always need to sign in, so there needs to be a way of hiding reviews from the flag dialog too.

Once you are signed in, if the review turns out to be your own one — or if you were already signed in, and chose “Delete” — USC should present a simple confirmation alert, “Are you sure you want to delete your review?”, with “Cancel” and “Delete” buttons.

Otherwise, USC should open a parent-less dialog should appear for flagging the review.

It should have a “Why is this review inappropriate?” menu with choices “Unspecified”, “Offensive language”, “Infringes copyright”, “Not about this software”, and “Other”.

The “Cancel” button should have Esc as its keyboard equivalent.

The “Report” button should have Enter as its keyboard equivalent. It should be sensitive only if the reason is not “Unspecified” and you have entered text in the details field.

This dialog should handle progress and HTTP errors in the same way as the review dialog.

If you choose “Just Hide It” or “Report”, the review in question should fade away indefinitely, and anything below it should slide up into place.

Moderating reviews

At any time, (2) the review service should be able to operate in either of two modes: active or passive moderation. In active moderation, every review must be approved manually before appearing to other users, but may still be flagged after that. In passive moderation, we rely on flagging to tell us if a review should be removed. Whether we start with active or passive moderation depends on who will be doing the moderating.


Erratum: “Approve” and “Delete“ should be “Keep Review” and “Delete Review”.

https://developer.ubuntu.com/reviews should be a page with access restricted to the moderation team. The page should present the first five items in a list consisting of, in order:

  1. flagged reviews, in your chosen languages, in descending order of number of flags
  2. any other unmoderated reviews, in your chosen languages, that were submitted while active moderation was in effect.

Why on developer.ubuntu.com? Because it will be the central place for application developers. They’ll sign in to see the status of their applications, both before and after they are accepted into the archives — including any reviews.

In the initial version, each flagged item should show:

  • the name of the reviewer
  • the date of the review
  • the rating and the review summary
  • the review text
  • the item being reviewed
  • the name of the most recent flagger, if any
  • the date of that flag
  • the basic reason given for flagging
  • the full explanation provided by the flagger
  • “Keep Review” and “Delete Review” buttons for the review.

To maximize speed of moderating, if JavaScript is available, the “Keep Review” and “Delete Review” buttons should not reload the page. They should instead remove that flagged item from the list, with any items below it sliding up, and the next item loading and appearing asynchronously at the bottom of the list.


Where an item has been flagged by more than one person, the “Flagged by” bar should contain “+N” after the name, representing the number of other people who have flagged it. At the trailing end of the bar should be arrow buttons for flipping, in-place, through the various flaggers and their comments.

Sorting items by rating

See the main specification.

Future work

The moderation system should be enhanced as necessary to deal with the number of reviews:

  • The name of the item should link to a batched list of other reviews for that item.
  • The name of the item should be followed by the number of reviews that:
    • are currently flagged for that item
    • have ever been removed for the item
    • have ever been submitted for the item.
  • The name of the reviewer should link to a batched list of their other reviews.
  • The name of the reviewer should be followed by the number of their reviews that:
    • are currently flagged
    • have ever been removed
    • have ever been submitted.
  • The name of the person who flagged the review should link to a batched list of their other flags.
  • The name of the reviewer should be followed by the number of reviews that they have:
    • currently flagged
    • ever flagged that were removed
    • ever flagged at all.
  • The “Delete” button should be followed by a “Ban Reviewer” button for silently dropping any future reviews from that reviewer, and an “Ignore Flagger” button for silently dropping any future flags from that flagger.

Reviews for items that are no longer available, or that are available only in obsolete Ubuntu versions, should eventually be expunged.

Rating a review itself

Was this review helpful? Yes/No

Right of reply for developers

Presenting reviews on an external Web site

Atom feed? JSON?

What extra legal requirements are there?

Old notes

Launchpad registry

* Expand the existing concept of PersonalStanding to R&R?

  • allows us to hide a swath of reviews tied to a spammer

* Since users will abuse R&R to report bugs, maybe we can expose to the driver a "turn this review into a bug report" (or link, or dup it, etc). * quickly bug# (via jdo, this is the awesomeness) * Architectural ideas

  • we already have couchdb. throw reviews into there and let launchpad process it offline; allows for offline reviews w/automatic sync
  • rabbitmq?
  • may not work for downloading because we don't want to force every desktop to have the whole review database
  • authentication data

* I want to see my reviews immediately but I can't see yours for 3 hours can be solved on the client (again, couchdb fits in nicely)

  • ratings.tgz generated every 6 hours. use archive mirrors
  • reviews.tgz separate? reviews are much larger

* Pretty safe bet that this will be huge * A user can only review once? Supercede?

  • don't bake review once into the data model
  • user can edit their review
  • keep data model open for multiple reviews

* Couch farm to aggregate as necessary to handle load, but LP sees one thing (the root of the tree) * Notifications - we need to think about it

  • by default, no notifications at all

* We happen to be the magic conduit for users to be talking to other users * Reviewing the reviews - not for Lucid

What a review contains

  • What version they had installed
    • Maybe prioritize reviews for current version, but still show reviews for previous versions
    • Maybe someone can replace their review of a package with a review for a newer version
    • Someone might review the versions in 10.04 LTS and in 11.10 separately
  • Rating (stars)
  • Maybe ratings abusers could share the Launchpad idea of "standing"
  • Maybe add helpful/unhelpful ratings to reviews themselves? (Lucid+n)
  • Link a review to a bug report
    • or possibly "convert to bug", like with questions
    • developers could comment on particular reviews (and have their comments highlighted)
    • look at brainstorm/amazon, they have similar issues to solve
  • "The issue you raised in this review, I've fixed it in this PPA I've just made"
  • Language used
    • Application average ratings may differ legitimately based on language (if an application is poorly localized, or has issues with e.g. metric system vs. other system)
    • Tag the language used, show it first.

Sending the data from Ubuntu Software Center

  • Use couchdb to store ratings and reviews offline, and they get sent to Launchpad when you're online
  • could have webkit frame do the signup process for launchpad within software center
  • One rating per user, but make it editable (or supercedable), especially when user gets new version of software

Getting the data into Ubuntu Software Center

  • New API needed
  • What to do without internet connection?
  • Cached?
    • Could cache the ratings (very small amount of data) but download the text reviews on demand
    • could put the ratings in the packages file and give them with apt-get update
      • or in the archive metadata index
    • CouchDB + desktopcouch for review content (desktopcouch would easily give us offline reviewing)
      • scalable, allows local version to be more up to date than global one (my review I just made gets up immediately, a review I just flagged gets hidden immediately)
    • Data doesn't need to be up to date, but does need to include reviews you just did

    • If ratings are stored in the archive, they'll get mirrored by Ubuntu mirrors
    • Show the latest n reviews by default, require another action to get more

Other issues

  • Maybe we should allow some packages to be immune from review?
    • analogous to YouTube's "ratings have been disabled for this video"

  • Default packages pose specific problems
    • Less incentive to review
    • Some people use software without knowing what it is.
    • Harder to gauge "real" popularity
  • "Help" > "Review This Application..."

  • How does this relate to popcon?
    • Show popularity as well as ratings?

    • Maybe we don't need popcon any more?
    • but popcon doesn't tell lies about installation
    • Maybe we could ask about popcon when someone is submitting their first review.
    • Would be much more useful if we knew how often people had been using the program.

  • When would people review software?
    • Suggest that you review it when you're uninstalling it?
      • May catch them at a bad time.
  • What e-mail, if any, would a review submitter receive as a result?
    • Developer comments on their review?

What the Ubuntu Software Center engineers need

  • Structured data that maps a package name to a rating (ratings in archive index?)
  • Reviews in given languages (not all languages)
  • Estimates of how big the data will be (per archive/component/etc)
  • have a LP API to be able to add new reviews
  • export Reviews-$lang.gz with the latest 5 comments and add "click here for
    • more" button in the s-center - maybe depends on the size of the db ???

Discussion topics

• data needs to be per-binary package, per-distro release (per arch?) • how should s-c get the read-only data?

  • ∘ ratings are small -> can go into a index file (small) ∘ reviews can be potentially very big if we allow multiple ones

    • ‣ query LP via launchpadlib for every page? ‣ make LP export a static page/data cache that is updated every n-minutes? ‣ export them all as a index file ‣ cache on the client? ‣ use clever JS on the client with webkit (cross domain JS issues?)
    • couchdb/desktopcouch - maybe not LP

• offline capability? for cdrom only media ?

SoftwareCenter/RatingsAndReviews (last edited 2015-04-13 08:09:55 by mpt)