Implementing app rating and comments

Possible API implementation

Everything with SSL

User Registration

POST	/v1/user/register
Request:
	nickname
	email
	password 
Response:
	session_id

session_id is secret, stored on the user's device and used to identify the user.

User Login

POST 	/v1/user/login
Request:
	nickname
	password
Response:
	session_id

Make a comment

POST	/v1/app/com.foo.bar/			
Request:
	session_id
	comment
	rating
	app_version
Response:
	ok

Get Comments

GET		/v1/app/com.foo.bar/:page/
Response:
	comments
		[
			id
			nickname
			text
			rating
			app_version
			date
		]

where comments is an array, starting from :page, and each comment has the format shown.

RSS Feed of Comments

GET 	/v1/app/com.foo.bar/rss
Response:
	<rss feed xml>

Report a Comment

POST	/v1/user/flag/
Request:
	comment_id
	session_id
Response: 
	ok

where session_id is used to identify the flagger.

Database Schema (relational)

Users schema

id
nickname
email
password (bcrypted)
session_id
group (if it's a moderator, or waiting activation, etc)

Comments schema

id
app_id
author_id
text
rating
app_version
date

Flagged schema

id
flagger_id (the user who flagged)
comment_id (reported comment)
date (timestamp)

Thanks for the detailed info @Keziolio. I think this is the type of thing which splits the F-Droid community, because many of the users are privacy focussed and don't want to have to register for yet another webservice in order to use F-Droid. However there also seems to be a strong desire for this feature by many people too. Thus, I think it is worth discussing and this is a great starting point.

I think there is probably two things that are missing in your proposal, which you may need to consider and I'd appreciate some feedback.

1) Multiple repositories

The same apk (package name + version code) can be distributed by many different repositories. If there is a dodgey build pushed by some repository, comments such as "Broken, don't bother installing" should be pinned to the specific repository which released the bung build.

I'm not sure how the UI/UX for this would work though. Right now we don't even have good support for multiple repositories in the UI without comments/ratings.

2) Decentralised Comments

Any comment server such as the one proposed by you above would be released as open source software. However it should probably be considered a reference implementation, with other people free to implement their own comment servers if they see fit. People need to be able to use the F-Droid client without having to trust the repository at https://f-droid.org/repo. This may sound a little silly given that this is likely where people downloaded F-Droid from in the first place, but I think it is a really important principle.

The question then becomes, if we can agree that the rating system needs to support arbitrary implementations, how do we provide users with meaningful defaults? I see two options:

Client wide configuration

Users can configure the URL to their preferred comment/rating server in the preferences. All apps/apks get their comments from this server.

Per-repository configuration

Each repository could specify in its metadata the URL to its comment/rating server. Perhaps this could be configured in the Manage Repositories screen if desired.

@Keziolio: I've edited your comment and changed the formatting. Hope you don't mind.

Thanks for the answer and the formatting @pserwylo

1. I think the best solution is keeping one comment system for every repository, sure the source will be released under AGPL, but the goal here is to give f-droid an usability improvement that all the other stores have, not making 100 forks only because of free software.

Now the repo url is https://f-droid.org/repo/ , the comments api can be put on a standardized url like https://f-droid.org/api/ or https://f-droid.org/repo/api/, https://f-droid.org:81 etc. or in a custom metadata in the repository like you suggested. I would not agree to have "client wide configuration", that'll mean to have scattered content and more complexity if we want to have them synced. I think the comment api needs to be unique and exclusive for every repository. This'll solve both problems.

If another entity wants to make its own repository with comments, it starts the fdroid repo server and the comments server that'll work for its repo.

imho

I think the best solution is keeping one comment system for every repository

Yup, I think that is best too.

The goal here is to give f-droid an usability improvement that all the other stores have, not making 100 forks only because of free software.

Yup, agreed. It should be similar to the main F-Droid repository (from fdroiddata) and how that is the biggest F-Droid repository right now. However, people are free to run their own repositories that rival f-droid.org/repo in terms of size/quality/some other important goal, and should be encouraged to do so. The same needs to be possible with any comment system - people should be free to fork fdroiddata if they want to and run their own comment system, perhaps with different moderation rules or some other goal.

We are definitely on the same page though - expect the system corresponding to f-droid.org/repo to be the main comment server, but allow others.

I would not agree to have "client wide configuration", that'll mean to have scattered content and more complexity if we want to have them synced

Seems reasonable. An entry in the repo metadata should suffice.

I think the comment api needs to be unique and exclusive for every repository. This'll solve both problems.

Not quite, the final outstanding piece of UI/UX is when an app has multiple apks, provided by different repositories. What is the expected behaviour when viewing the details of this app and reading through the comments, or understanding the ratings?

Issue 53 has some more discussion about supporting ratings and comments. I've been looking into Django and Django Rest Framework as possible ways to implement this feature. I was approaching it from the perspective of integrating it into fdroidserver by replacing index.xml with a database backed API and then adding support for comments. I like this proposal too.

Figuring out a good ratings/comments system would be very valuable, but its also not easy. I think a much better approach is to figure out how to make ratings and reviews that are parsable data bits that are posted wherever users already post things, like blogs, Twitter, Facebook, etc. There could be an f-droid web app that helps generate the posts for people, and there could also be a part of the client app that does the same. https://openintegrity.org/ is trying to do something like this, so its worth exploring these ideas with them.

There are a lot of difficult issues in running a user-generated comment/rating system that are entirely unaddressed in this proposal. The actually bits of code for posting and viewing comments is the easy part, unfortunately.

Client data source is purely static

The server side of the data that is served to the client is only flat files, no dynamic web generation. The website does include wordpress for the web-side of the data, but wordpress serves no role in the data that is fed to the client. This is quite important because it becomes a lot more difficult to maintain and defend dynamic content fed to the client. We simply do not have the volunteers to do that work, nor the project structure to manage it, nor the money to give someone a job to do it.

Maintenance

Who handles spam management, abuse, backups, etc? Those are all unavoidable questions when building something based on user-generated content.

I've been looking into Django and Django Rest Framework as possible ways to implement this feature. I was approaching it from the perspective of integrating it into fdroidserver by replacing index.xml with a database backed API and then adding support for comments. I like this proposal too.

There's a clear distinction between static and user-generated content, I wanted to keep things separate because I don't want to mess with fdroidserver, feels like that huge server and client side changes are needed to do this. And doing that would probably mean to lose the current offline functionality of f-droid, if we do everything with a rest api an internet connection is obviously required, not that's a big deal to me but I don't know if the current architecture is based on a specific rationale.

So fdroidserver can stay untouched in its reliable work, and another thing can manage all the dynamic things like comments, ratings, accounts, user-submitted screenshots, etc. Another option is saving the comments data on the filesystem and serving it like fdroidserver, but a server for user management and writing content is still needed.

But if it makes sense to rewirite fdroidserver from scratch in a rest api, that'll be the preferred option, if there's enough workforce for it.

I think a much better approach is to figure out how to make ratings and reviews that are parsable data bits that are posted wherever users already post things, like blogs, Twitter, Facebook, etc. There could be an f-droid web app that helps generate the posts for people, and there could also be a part of the client app that does the same.

I think this is way overcomplicated than it should be, sure it's not trivial to make a custom comment system, but this option feels far worse and unreliable to me.

There are a lot of difficult issues in running a user-generated comment/rating system that are entirely unaddressed in this proposal.

For example?

Who handles spam management, abuse, backups, etc?

I proposed a way to handle it, it's not hard to hide a comment when it receive, for example, 2 reports, and putting it in a moderation queue, i don't think it's a problem to find anyone that can put 30 seconds a month to moderate a comment, it's not like that f-droid has all this popularity... And i can't figure a reason for anyone to spam or make spambots for f-droid, nothing that can't be resolved by a captcha anyway. Backups should be handled in the same way you backup fdroidserver, if we use sqlite it's just a file in the filesystem, it's not rocket science.

Right now, there is no dynamic web systems that affect the Android client's behavior. It sounds like your approach would change that. That is a large change to the security attack surface for the worse.

Managing spam and abuse is vastly more than 30 seconds a month. Its already a lot more just for the f-droid.org forums.

I make no claims that any of this is new research or "rocket science". But the maintenance is a lot of work that someone needs to do.

Right now, there is no dynamic web systems that affect the Android client's behavior. It sounds like your approach would change that. That is a large change to the security attack surface for the worse.

I only followed @vermillion proposal, a complete fdroidserver rewrite is not necessary. I'd like to know how do you think to do a comment system without a "dynamic web system" how are we supposed to send comments? Via email? Commits? Ftp access? Come on... We can for sure put the comments as files in the same directory, that was an idea from the beginning, but it'll become bloated and troublesome to work with for no real benefits, when, as @vermillion suggested, it would be advisable to move fdroidserver itself on a rest api, instead of downloading an xml file every time.

There are a few of thinking about techniques for making ratings and comments more decentralized, and even without modifying the server side. For example, with Twitter, it could easily be done using the app's packageName (i.e. Android unique ID) as a hash tag, e.g. https://twitter.com/hashtag/org.fdroid.fdroid Twitter would be used by the F-Droid client for the comments and ratings if Twitter is installed on the device. Just a rough idea.

Its really not advisable to move fdroidserver to anything dynamic, that would make the security profile a lot harder to maintain. The use of static files is by design, not by accident. Its a really nice feature of fdroid both for maintainability and privacy.

Right now, there is no dynamic web systems that affect the Android client's behavior. It sounds like your approach would change that.

This is indeed the case, as would any approach that requires us to implement our own comment system.

That is a large change to the security attack surface for the worse.

Nobody would debate that it increases the security attack surface, but this should not be an argument for not doing it. Instead, it should be an argument for doing it correctly.

Previous discussion in this thread revolved around the idea that the comment server needn't be on the same server as the one which serves apks and repo metadata. In light of your comment, I'd go one step further and actively discourage this. Thus, you could have all of the security of fdrodiserver without any dynamic web backend on f-droid.org (at /repo). Then there could be comments.f-droid.org which is a different physical machine, which serves comments. Then even if there is a security problem, it will be contained to the comment data but not the apk/repo data.

Also, are we not planning on having a dynamic web based system for people to manage f-droid builds and so forth? Just because this increases the security attach surface, doesn't mean it shouldn't be done. Even though the security implications of a comment server are far less than a web-enabled build server, the build server idea adds a lot of value to the F-Droid infrastructure and app developers. I feel that the same can be said for comments/ratings - this adds a lot to the F-Droid client and end users.

Although absolute full decentralisation is likely possible using 3rd party (proprietary services such as twitter?), I don't think it is the right solution here This doesn't mean everyone should stop everything they are doing and work on this feature, but @Keziolio is offering to work on the feature, and I'd like to encourage that as I think it will make F-Droid even more awesome.

Given the nature of F-droid's multiple repos + being all about free/open software, it seems planning on decentralized comments is essential (even if it is more work). To implement simple decentralized commenting & ratings, the fine folks of IndieWebCamp (disclaimer: i'm a member), have done great work towards this goal. IWC created a set of open source libraries, tools, and differing implementations of a few a protocols that could achieve this.

WebMention - a modern update of "pingback" that allows cross posting from DomainA to DomainB, etc...

Relies on simple GET, POST requests, HTML with microformats2
Overview

POSSE - Post Own Site Syndicate Elsewhere, could be used to make F-droid store "auto-post" new apps or updates to Twitter, etc... which then in turn generate comments that get get "back-fed" to the F-droid site via PESOS

Pretty much relies on the third-party API of "silo" site e.g. Twitter
Overview

PESOS - Post Elsewhere Syndicate Own Site, which is about getting content back out on centralized silos like Twitter & Facebook

Can be implemented from scratch or use web maintained IndieWeb services run by community members like Brid.gy or WebMention.io
Overview

See an example of all three protocols implemented on my personal site. All the comments & favorites (at bottom) came from Twitter, Facebook, or IndieWeb capable sites. This could be easily fashioned to achieving F-droid's goal with the following benefits:

Is pretty straightford and low barrier to entry
Is not 100% decentralized, but could be
Interopts with services that do not support decentralized protocols (Twitter, etc...)
Has existing tools, libraries, and a community #indiewebcamp on Freenode

Sorry @bnvk, but the "decentralized comments" thing feels complicated, not user friendly and unreliable.

What's the point on having decentralized comments on facebook and twitter ?

Why should I need a FB/TW/whatever account to make comments on f-droid?

Let's say that I click on an app on f-droid, what should I do to comment/give feedback? Follow a link (put by who?) to a social network, and comment within 140 chars? Obviously trying not to seem retarded to the people that read that comment and are not interested in F-Droid, and giving away all my privacy (why should my facebook or twitter name appear on the comments?) This is just impractical.

And for ratings?

This may be a valid way to collect opinions on a personal blog but it's not an appropriate method to do rating and comments on a store of applications...

If you want decentralized stuff, we can just drop the email registration, and use a strong hashing function or an asymmetric encryption method of some sort (i'm not an expert, but think about bitcoins), and then share all the data to other trusted hosts for redundancy.

This "decentralized because it's more opensourcey" just doesn't makes sense to me, it's just asking for bad user experience and not solving any problems.

My two cents obviously.

The point about a decentralized system is that users can post wherever they are already posting, not to promote any given service. If users can post their ratings/comments wherever they post, then Facebook and Twitter are going to be a large factor, since they are massively used, so we shouldn't ignore those.

The decentralized system has the huge advantage for F-Droid in that it puts all the necessary work squarely in front of us, and is the kind of work that a free software community can do well: software development. A standard dynamic web system creates a ton of work that free software communities are generally bad at: server maintenance, setting up infrastructure, security audits, handling abuse, etc. The F-Droid community is already structured to handle writing code together, we are not at all structured to manage infrastructure and user-generated content. And "make @CiaranG do it" is not an answer.

Then there is even legal liability. If the repository of APKs is totally lost, that can be regenerated using https://gitlab.com/fdroid/fdroiddata. If all the comments and ratings are lost, there is no way to regenerate them. Google gets sued for all sorts of things like this. Since donations have always been part of F-Droid, there is money involved. And how to handle complaints like this: https://productforums.google.com/forum/#!topic/maps/0bAQMgA-4ww

So I think @bnvk s proposal will actually be less work overall than @Keziolio s proposal. Coding a website is really the easy part of this whole comments/rating system. @Keziolio s proposal might fit nicely into https://fossdroid.com if they are willing to take it on.

As for posting ratings and comments in a generic way from F-Droid, that seems really easy to do. Just make a comments Activity that guides users to enter a rating and a comment. That will make a message with a standard tag and a standard format for ratings data. Then the user can "share" it to any app that they use to post such things (e.g. Wordpress, Twitter, Twidere, Facebook, VKontakt, Baidu, Tumblr, Identica, etc.)

I like @bnvk's proposal better not only because it keeps hosting F-Droid repositories simple, but also because it will not centralise the whole ecosystem to our repository. Ours is the only general-purpose repository out there right now, so it's very likely that none of the other repos would bother to set up the server side for comments and ratings.

And of course, the least that we have to maintain, host and manage, the better. We're using gitlab.com and hosted.weblate.org for those very reasons. We could be hosting and managing our own instances for the two of those, but we don't. And it saves us a great deal of time and effort that we can invest in actually developing F-Droid.

@Keziolio seems like you might misunderstand what I'm proposing- the IndieWeb stack is not opposed to something like your architecture- it could be built in addition to it. The details are TBD with the implementation.

Sorry @bnvk, but the "decentralized comments" thing feels complicated, not user friendly and unreliable.

No need to apologize, we're discussing ideas ;-) "implementations" of a protocol. What I'm proposing can be every bit as user friendly as any system where "users make comments on the internet" hence:

What's the point on having decentralized comments on facebook and twitter ?

There are two types of comments on silo sites that I am talking about.

Posts by F-Droid, perhaps announcing a new release or update of an app (would be POSSE) which could be automated
Comments made on social media about content on F-Droid (would be PESOS) what we do with this content is up to us.

Using Bridgy + WebMention.io (IndieWeb stack) allows archiving / displaying of comments in a fashion that is "decentralization friendly" as it allows people running their own IndieWeb compatible sites (there's a WordPress plugin to support webmention) which allows for participating in decentralized commenting... etc.

Why should I need a FB/TW/whatever account to make comments on f-droid?

The IndieWeb approach does not require one to have FB/TW to comment, but rather leverages using those platforms as A LOT of people already there discussing things. FB/TW interfaces provide user friendly ways to comment on F-Droid content. Additionally, the barrier to creating (or already having) accounts on said platforms would help with spam, or lower barrier to participate, respectively.

That said in regards to @eighthave @mvdan concerns about what infrastructure is needed- that depends on what we want to implement and should be discussed elsewhere, perhaps IRC?!

The decentralized system has the huge advantage for F-Droid in that it puts all the necessary work squarely in front of us, and is the kind of work that a free software community can do well: software development. A standard dynamic web system creates a ton of work that free software communities are generally bad at: server maintenance, setting up infrastructure, security audits, handling abuse, etc.

I agree that server maintenance is not a strong point of many projects, I think handling abuse is something that many free software projects do amazingly well at. I am a believer that we should actually adopt a code of conduct at F-Droid, like many other projects do. Projects with strong, clear, and fair code of conducts, with processes in place to address concerns of community members, can be (and many are) amazingly good at dealing with abuse and other issues.

On the flip side, fully decentralized comments are likely far worse at abuse handling. It is true that each individual service will likely have its own moderation policies that allow abusive comments to be taken down. But what about spam or junk comments? It would become overwhelmingly easy to take advantage of such a system to make the commenting feature completely unusable.

Having said this, I am thankful for @bnvk's input, and will spend some time reading through the indy web stuff over the coming week or so because it does sound interesting. For sure if that is able to achieve all the things that are required, then it should be considered, as should all other options. This is the type of feature that will:

Probably never have 100% agreement among community members
Take some time weighing up various options before a clear implementation plan is able to be adopted
Once decided upon, may still take some time to implement

So as long as the discussion continues to stay civil, I don't see anything wrong with this thread growing as various ideas are proposed. Perhaps we can eventually document some of the options with pros and cons in the wiki in the future. May be more suitable than gitlab.

Based on https://f-droid.org/forums/topic/potential-app-rating-solution/ I'm now thinking that we should do some kind of automatic star/rating system like GNOME laid out. Basically, make a simple algorithm that generates 1-5 stars based one:

download counts
rate of downloading (i.e. how fast the download count is increasing)
whether the app is available in the current system's language
data from a "popularity contest" opt-in install/uninstall tracker like Debian has

This then means we can build the UX to include displaying ratings, and in the future, if there is a different system used to generate the ratings, like the original proposal here, the UX will already be in place in the client.

mentioned in issue #396

mentioned in issue #724 (closed)

Changed title: Implementation proposal for app rating and comments → Implementing app rating and comments

Added ~16415 ui labels

Milestone changed to %0.103 - UX Overhaul

mentioned in issue fdroidserver#195

FYI, I am working on a generalized, open source and freely licensed repository of reviews, https://lib.reviews/ . It's currently invite-only but it's already possible for approved users to post/edit reviews, and it supports multilingual content. If F-Droid was interested in integrating with it, I'd be happy to help make that happen. It currently uses local logins but will support popular third party authentication strategies as well (e.g., sign in with GitHub, Twitter, FB).

Here's an example of a review of an npm package: https://lib.reviews/review/103868b3-3f2f-4f27-a154-495712686437

If you wanted to set up your own instance of the software just for F-Droid, that would also be possible, though I think there'd be more network effects out of using a single repository.

See the screencast and intro on the site for more info on the project and let me know if you're interested in collaborating. :)

@eloquence That looks very interesting.

Does anyone else have any thoughts about that?

(I had a reply in mind, but was away on holiday)

@eloquence sounds good. Some questions:

When are third party logins going to be possible? That seems like a blocker for us.
Are any open source services going to be available? OpenID and gitlab.com come to mind.
What keeps someone from spamming or otherwise abusing the system?
If we set up reviews for apps on F-Droid, could there be moderation over them? Could we (or a set of limited users) be moderators?

We already use Gitlab and Weblate with the free upstream services without self-hosting, so we would most likely do the same here.

Hi Daniel,

Excellent questions. My overall recommendation would be a phased integration: a semi-closed beta with invite codes first, followed by opening it up when we have a critical mass of users who can keep spammers and bad faith actors in check.

The invite code system is a hack right now, but I plan to replace it with one where existing users can send out codes, the way GMail did it in the early days.

In my experience with Wikipedia, a community needs time socially and technically to prepare for new members, and this could be a way to buy us some time while giving interested F-Droid users (the kinds of people who would be on the IRC channel or the mailing list or this ticket) the opportunity to play with the system.

Re: moderation, right now we have a fully reversible deletion feature and moderator bits that I can pass out to anyone in the F-Droid community willing to help with moderation. Think of it like being a Wikipedia admin -- i.e. those folks would have permission across the whole site, not specific to F-Droid. I should point out that we do have a code of conduct against harassment, trolling, and use of the platform to spread hatred. For more details on that, see: https://lib.reviews/terms#conduct

Re: third party logins, it would be fairly easy to add GitLab support, but per the above, I would still prefer to require an additional invite code until we have a critical mass of users. There's also a plugin for OpenID and I can look into that, as well, though in my experience it's hard to make it work as reliably due to differing implementations.

Sorry for the long-winded answer and hope that provides some context. I'm Eloquence on irc.freenode.net and just joined the #fdroid channel in case anyone wants to chat in real-time.

The invite code system is a hack right now, but I plan to replace it with one where existing users can send out codes, the way GMail did it in the early days.

Sounds good. Add that to the list of things blocking us from adoption.

Re: moderation, right now we have a fully reversible deletion feature and moderator bits that I can pass out to anyone in the F-Droid community willing to help with moderation.

I'm not sure about this. Surely you don't want uncontrolled access to that. At the same time, we would like to delegate moderation to a group of faithful users, as us ourselves are already busy with developing the software and maintaining the apps.

Re: third party logins, it would be fairly easy to add GitLab support, but per the above, I would still prefer to require an additional invite code until we have a critical mass of users. There's also a plugin for OpenID and I can look into that, as well, though in my experience it's hard to make it work as reliably due to differing implementations.

Sounds good. If OpenID isn't available immediately, access via gitlab.com would be more than enough as a start since that's what we use for all of our repos.

@mvdan

Sounds good. Add that to the list of things blocking us from adoption.

These blockers are now tracked via https://github.com/eloquence/lib.reviews/milestone/2 . Feel free to add new issues that seem like possible blockers. I will work through these before working on the actual integration. For the integration itself, it looks like there are two pieces:

the F-Droid web repository (WordPress plugin, looks like?)
the Android app

I'm pretty comfortable working on the first of these as an example of how it could be done in the Android app as well. I will need some help on the Android side of things. My preferred implementation strategy for the web view would be to have a JavaScript version that dynamically pulls reviews via a CORS-approved API request, and a no-JavaScript fallback that links to the reviews page on lib.reviews.

Re: moderation

Surely you don't want uncontrolled access to that.

Not uncontrolled, no, but I want to avoid the creation of silos within the community. Making sure that we don't have spam, abuse, etc., and that the content is of high quality is of concern to me and non-F-Droid contributors as much as it is to you. Since I don't see any conflict of goals, my suggestion is that we just agree on a simple, lightweight process for adding moderators and/or revoking their access if needed. Since mods won't be able to do anything that's irreversible, the worst case scenario will be that we'll have to revert someone's actions and revoke their access.

For this reason, logging moderator actions is a blocker on my end, so we have good shared visibility and can respond appropriately.

the F-Droid web repository (WordPress plugin, looks like?)

The web repository has seen no love in the past three years, and other people have done new UIs from scratch - for example see https://fossdroid.com/. Unfortunately, that one is not open source yet.

So I would not do this for the website just yet. The client will be a better first candidate. It's of course fine if you cannot do it. If you opened an issue linking to the API docs or anything else of use, I'm sure someone on our team or someone else will help.

Re moderation, seems like you want to involve our admins into the whole community. Seems fair, but I don't know if the people would be moderating outside of our use within F-Droid. In any case, it seems fine by me.

Ping us again once the milestone is done and we can talk about starting to integrate. The client is going through a UI overhaul this month and the next, so no need to hurry - writing UI code for the client right now is a bad idea.

lib.reviews sounds nice (and for what it's worth, I'm sure many people would be willing to moderate comments, I definitely would be willing to), but I'm curious about one thing: support for internationalization.

Seeing how F-Droid is an app used internationally but mostly by the geek community, we should probably expect most reviews to be in English. However, I have managed to convert some non-technical users to F-Droid myself, and many other such non-technical users will surely be out there who would review in their native language.

I'm personally thinking the best way to deal with this would be to assume that all reviews are made in the same language the F-Droid app is running in, to give the hopefully lowest false-positive rate, and also allow moderators to change the language on reviews.

For showing reviews, we probably first want to show the text of some reviews that are of the same language as the app language, falling back to English if there are no reviews in the app's language.

Of course, only showing an average star-rating avoids this problem altogether, but probably makes the app feel less vibrant for users.

@TheLastProject Here's what I've done so far re: i18n:

I'm a native German speaker, so the entire UI is already available in English and German (you can switch using the selector at the bottom). I've not added the i18n files to a platform like Transifex (or more likely, TranslateWiki) yet because I want to clean up the message keys and add some more docs for localizers, so we get high quality i18n. But it's on the way.
We use the current language to determine what language the user is working in. We show notices to this effect, as well. This is consistent with the behavior you're suggesting for the app integration.
Every piece of content (!) can be translated. You can see an example of a review that's in two languages here: https://lib.reviews/review/e72e5614-a99d-4c5e-ad40-a53b00600a5b - again, just use the switcher at the bottom to try it. For content that's not translated yet, we show a little indicator that it's not in the language the user is currently working in.
I plan to leverage those capabilities to create a "Translators" team which can actually translate content on the site freely, without the ability to edit the original content they're translating. Most of the bits needed for this are already in place (basic team support, versioning, data structures that make it possible to distinguish original language vs. translation), so it's not as complicated as it sounds, though still a bit down the road.
Changing (fixing) the language for existing content through the UI isn't possible yet. That shouldn't be too hard though and it's definitely going to become necessary.

There's one bit of text I may introduce without full multilingual capabilities: URL slugs (so you can have short URLs like lib.reviews/wikipedia-app-android or whatever). We'll probably just support 1-3 slugs per object and the language will likely be the most common label for the thing being described.

I'm not using content language as part of ranking lists yet. That could be a good idea indeed, though given the emphasis on it being a multilingual community, it might be more interesting to focus on quality and encourage translation so everyone benefits from the highest quality content.

Okay, it seems like that is mostly fine. I don't agree to the idea of a translator team, though, it seems like overcomplicating things and giving everyone a lot of extra work.

First off, it's very complex to know if a translation doesn't lose the nuances of the original message, so checking translations is hard. On top of that, you basically double the workload for moderators as they don't only have to check if the original is fine but also need to check for the translations. Seeing how you plan to make the translators a team, it's seems like a recipe for unnecessary tension because moderators can't deal with translators like normal users (because they're "accepted team members") and getting rid of a problematic translator will probably require things to be taken higher up, causing a loss of time for basically everyone.

Secondly, I very much don't like the idea of having my own messages translated in another language I don't speak as I cannot tell if that person translated it in the way I intended the message and if it's still the exact opinion I have. A third-party translation of my own messages is definitely not something I'd want attributed to me, at the very least.

@TheLastProject Your points are well made. I do think we'd be able to agree on a path forward re: collaborative translation with some further discussion, but I suggest parking that for now and focusing on near term blockers. For the time being, only reviewers can create/edit translations of their own reviews. If/when we get closer to changing that, I want to write up a somewhat more detailed proposal of how it all would work, and hash it out on the project list, here: http://lists.freeculture.org/mailman/listinfo/lib.reviews (with appropriate notice to F-Droid and others). But that's likely still at least a couple of months away. Does that sound reasonable?

Like @eloquence, I say let people submit in their language, and see the reviews in their language before the rest (this is what gplay does I think).

Once we have that basic setup, we can consider further features like translation.

@eloquence if you're considering translating platforms (for whatever purpose), Weblate is working really well for us.

mentioned in issue #760 (closed)

Hi,

A couple of progress updates:

You can now help with the localization of this project through the translatewiki.net community. We opted to use TranslateWiki because it's a fully free/open source solution, used by Wikipedia. See this blog post for details on how to help. Portuguese, Swedish, Finnish, Telugu and French are already underway.
We now support file uploads. You can upload media files related to a thing you're reviewing . This will be nice for screenshots of Android apps and the like.
You can now associate reviews with teams, and subscribe to the RSS feed of a team. This is an example of a team feed. This is one of the ways we could organize reviews that come through the F-Droid app. I'll add support for tagging as well, but this will be done at the level of review subjects, not individual reviews.

There are a few more blocking issues before we can start digging into integration, but I wanted to let y'all know that I'm continuing to chip away at things. :) Come find me on #lib.reviews on irc.freenode.net if you want to chat more.

@eloquence thanks for the update.

You can now help with the localization of this project through the translatewiki.net community

We've used translatewiki in the past but switched to weblate, and our life is much easier now. In case that would apply to you too.

This will be nice for screenshots of Android apps and the like.

Might be useful in the future, but we won't be using this right away. We first need to support screenshots supported by upstream.

Keep us updated!

Please don't do that, or at least allow people to disable comments and ratings for "their" apps.

Reasons:

There's nothing more frustrating than if you put efforts into an open-source project, and then receive many bad ratings and reviews, combined with blackmailing for feature requests ("will get 5* as soon as this and that is implemented"). It can have severe impact on motivation and will stop developers from doing open-source.
Bad ratings are "forever". If you get a 1* rating as a punishment for a bug (like it's done by users), it will never be removed, even if the bug is fixed for ages. So, the overall rating is a quite useless random number.
People misuse ratings for support requests. They give bad ratings just because they don't read the manual or even the FAQ. This means that the ratings do not reflect the real product quality. For instance, there are some Android bugs which reduce the usability of an app, and people will rate down the app instead of Android.
I strongly ask you to reflect and question why all proprietary stores force app reviews/ratings and why this should be that necessary. My favorite analogy is a supermarket (= store): it's a market place where customers and suppliers come together. So, did you ever see a supermarket that allows customers to put a "1*, don't buy this cheese, it's awful" badge on products? This whole rating thing brings people to a requesting/judging attitude, instead of a contributing one. Why take the time to create a patch, if you can blackmail the developers with bad ratings instead?

Based on:

real-life experience with ratings in proprietary stores – I would instantly turn this off if I could.

There's nothing more frustrating than if you put efforts into an open-source project, and then receive many bad ratings and reviews

And why would anyone put bad ratings and reviews? I think that the vast majority of f-droid users know that they are dealing with open-source apps and are well-aware that they are not paying any money for it Sure you can find some rude comments, but you can find them also in the issue tracker, mail, irc channel, etc... Do you want to close them all?

Bad ratings are "forever"

That's so trivial to solve I won't even reply, google play already marks reviews for an old version of the app

People misuse ratings for support requests

Same as before, this is a problem causated by some people, and it's relatively easy to reduce, for example by putting more fields to rate (graphics, functionality, stability etc) so it's clear for the users that comments are used for reviews and not feature request or other stuff, it can be written too...

I strongly ask you to reflect and question why all proprietary stores force app reviews/ratings and why this should be that necessary.

I'ts necessary because now if I want an app on f-droid that does "X", i search "X" and I find a dozen of apps, ordered in alphabetical order, without ratings and screenshot, and there's no way I can find the best one without downloading all of them and see by myself, this is the worst user experience that you can have in a store.

I would instantly turn this off if I could. We can also add "comment ratings", like reddit or amazon for example, if someone says "this app is shite" other users can mark that comment as bad and it will go down / disappear Or give the app developer the possibility to remove ratings, but i'm not really happy about that, developers can be dicks too Turning this off defeats the purpose of the whole system, I (as an user) need a way to distinguish good apps from less-good apps, when there are a lot of them

By the way, is any progess being made on this?

Perhaps whether an app is reviewable could somehow be tied to whether it's considered by its developers to be alpha-quality software and therefore, by definition, only ready for intrepid testers and developers?

I'm still working on getting lib.reviews ready for integration with F-Droid, though I admittedly took a bit of a break during the holidays. I did remove one blocker recently, which was to make it easy for any existing user to generate invite codes, so we can test the system without having to open the floodgates completely. I'll post other major updates that get us closer in coming weeks.

And why would anyone put bad ratings and reviews?

They do. For instance, they're angry when something doesn't work at the first try (which is very understandable), and then the first reaction is to write a bad review. Don't ask my why, it's my experience.

Let's ask the other way: Why should someone write a good review? If you install an app and everything works, you forget it. If it doesn't work, you become angry and write a bad rating.

google play already marks reviews for an old version of the app

They mark reviews for old versions, but the overall rating is calculcated from all ratings, including punishment ratings from years ago. And the overall rating is what is used for ranking etc, and what people use as "quality measurement" of the app.

this is the worst user experience that you can have in a store.

I don't think so. My needs are not determined by what other people say what's good. Thinking so is kind of … sheepish.

Also, I won't argue anymore because it's of course up to you. I just wanted to note that it might be worthy to do some self-reflection about the consequences and whether it's necessary to uncritically copy behaviours of proprietary stores by any means.

Even if fdroid doesn't support reviews, people will still post on the internet about things they want to post about. Providing reviews in fdroid makes them easier to find, including for the app developer. For example, if a developer doesn't ever read XDA-developers, and someone starts a big thread there complaining about an app, the developer will never know, but many many people will be reading those comments on XDA. I think that would be even worse than having those annoying complaints on fdroid.

i guess this relates to #396 as well?

changed milestone to %1.1

Implementing app rating and comments

Designs

Child items ...

Activity

Possible API implementation

User Registration

User Login

Make a comment

Get Comments

RSS Feed of Comments

Report a Comment

Database Schema (relational)

Users schema

Comments schema

Flagged schema

1) Multiple repositories

2) Decentralised Comments

Client wide configuration

Per-repository configuration

Admin message

Admin message

Implementing app rating and comments

Activity

Possible API implementation

User Registration

User Login

Make a comment

Get Comments

RSS Feed of Comments

Report a Comment

Database Schema (relational)

Users schema

Comments schema

Flagged schema

1) Multiple repositories

2) Decentralised Comments

Client wide configuration

Per-repository configuration