## page was renamed from SoftwareCenterRatingsAndReviewsGobbySession = SoftwareCenterRatingsAndReviewsGobbySession = This is a means for users to communicate with other users about software. It is not specifically a means of communication with Ubuntu developers. == User stories == * Mikaela has just finished playing Briquolo and wants to review it. She opens the Ubuntu Software Center and finds Briquolo, and clicks the "Rate & Review..." button. A dialog appears for her to sign in to her Ubuntu Single Sign-On account. She doesn't have one, so she goes through the registration process. (What does this look like?) She is then presented with a dialog to enter her rating and her review comments. * Sandro is on a dial-up connection. He is looking through the games available for Ubuntu, and comes across Briquolo. When he navigates to the Briquolo information screen, the basic information appears immediately, with Mikaela's review appearing at the bottom of the page a few seconds later. * Tillie is browsing the available software in the Ubuntu Software Center when she comes across a review that uses inappropriate language. She clicks the "Report as Inappropriate" button. The review is immediately and persistently hidden for her, and her report is also sent to Launchpad for a moderator to review. == Ubuntu Single Sign-On Process == * currently you have to go through the Web to create an account * Ubuntu Single Sign-On will provide a browserless way of doing this * This will be available for the Ubuntu One client app * Afternoon discussion: sign on to Ubuntu single signon without signing on to Ubuntu One * Is it possible to have an Ubuntu single sign-on account without having an Ubuntu One account? * OAuth? * Issues with Ubuntu Single Sign-On accounts vs. Launchpad accounts * We need to make clear that someone who already has a Launchpad account does not need to re-register * We need to make clear to someone coming to Launchpad later that they already have a Launchpad account * Launchpad account pages have high Google ranking. Possibility of frightening people. * Maybe don't have a person page etc for people who haven't directly used Launchpad. * long term plan is to have launchpad be a consumer of the Ubuntu single signon * currently both launchpad and ubuntu single signon are OpenID providers hooked into the same database * when someone without a Launchpad account makes their first rating+review, they should invisibly get a Launchpad account * Ideal: Someone doing ratings and reviews should never need to know that Launchpad exists * But, for someone who does use Launchpad it may be useful for them to see their previous ratings+reviews on a LP page * Maybe start by letting people submit reviews on Launchpad itself, then work out desktop integration * Maybe start with ratings first, add reviews later == Launchpad registry == * Single signon to review automatically giving user a LP account * email address and user name * SSO will validate email address * insert LP account w/validated email so we don't try to validate twice * how to autogenerate a user name? * how to tell user he has an LP account? * Do we need web ui in LP to input reviews via LP? * exposed only through API? * enter only via desktop? * email address state: validated but not yet used? * Model work to support R&R in LP for an almost pure desktop experience (user doesn't know LP exists) * UI work in LP to manage R&R in the LP web ui * 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 * Radical idea: this data doesn't live in LP. LP is a client of it * Potentially, users wouldn't need an LP account to interact with it (SSO yes, LP no) * R&R database are static (i.e. the same for everybody asking about the same app/language/distro) * No need for personalization, so why hit LP for read access? * could be generated every 5 minutes & pushed to an http (anonymous) url * no anonymous access to the LP api * 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 == * Review text * Is it a good idea to require text along with a rating? * Gives an idea of the person giving the rating * but would also make it more likely to have reviews with very little content ("good.") * option: make comments non-mandatory, use the stars for average rating, but hide the "empty" comments * If comments were mandatory, that would make approval/disapproval of other reviews more important * Comparisons: Android Marketplace, Get Satisfaction, Amazon * What language the review was in * Maybe prioritize reviews for the same language, but still show reviews for other languages * Who reviewed it * 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 * This may increase Web requests to Launchpad, a lot * How will launchpad deal with millions of queries? * If we don't care about instantaneous reviews * Maybe Launchpad is not necessarily the right home for this information in the first place? * 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) * Launchpad could be a client of that standalone database * If the data doesn't live in Launchpad, that solves the problem of needing a Launchpad account * 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. * 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 Launchpad team needs == * Data model for Lucid * Data model for the future * API requirements == 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) * Anonymous access to the Launchpad API! ... or an export of the data somewhere * 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 ??? === Further work === * research couchdb and if it can be used for the ratings (couchdb-karmic-main-$lang) == Discussion topics == • what to allow 1 ratings (1-5 stars) 2 multi-language reviews (like amazon, multiple ones?, just one wiki like? 3 comments? review the reviews * Merge ratings and comments? • where allow changes? ∘ software-center ∘ LP web ∘ both? what first? • do we need a new LP page or can/should we re-use https://launchpad.net/ubuntu/lucid/+package/update-manager ? • 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 ?