ODRS: show newest reviews first

Hi all

I couldn’t find the ODRS bugtracker, so I’m asking this here. Let me know if there is a better place to discuss this.

ODRS reviews in Gnome Software are sorted by oldest reviews first. Looking at the code of Gnome Software, this is because ODRS returns the results by oldest reviews first. This means that if you get a few bad reviews when your app initially becomes available, these reviews will always stay visible on the top of the review list, even when the application has since improved and solved the issues mentioned in the reviews.

I also found that Gnome Software only shows the first 20 reviews. This means that users can only view the first 20 reviews of an app. I’d argue that the most relevant reviews to the user are the last 20 reviews instead of the first 20 reviews since they reflect the current state of the app best.

So, to solve these two issues; is it possible for the ODRS service to return the last X reviews instead of the first X reviews on the https://odrs.gnome.org/1.0/reviews/api/fetch endpoint?

From memory, I think gnome-software lists them in the order it receives them from the ODRS. I think the biggest weighting on the ODRS is the number of “upvotes” the review got, so I suppose it’s expected that older reviews are presented “first”. I’m open to changing the ODRS algorithm to something more smart if that helps.

2 Likes

I agree the algorithm should be changed. Users only upvote the reviews they see, so we sort of get locked into the same reviews forever. Weighting the reviews by recency in addition to upvotes would help.

1 Like

That was also my impression when I looked at the code.

In order to know how the algorithm could be improved; What information would this algorithm have available? Do you save the dates of the likes, for example? Is there a raw dump of (some of) the data available somewhere to test on?

Also, this might seem stupid, but I wasn’t able to find the source of the current odrs web service. Where can I find this?

In order to know how the algorithm could be improved; What information would this algorithm have available?

There is odrs/models.py with all the data we have. Reviews have to be
provided with minimal database and CPU load too, so we have to be
slightly wary of doing anything too clever unless it’s punted to the
daily cron job.

Do you save the dates of the likes, for example? Is there a raw dump of (some of) the data available somewhere to test on?

No, not directly, sorry.

Also, this might seem stupid, but I wasn’t able to find the source of the current odrs web service. Where can I find this?

Richard

1 Like

As a strawman proposal; what do you think about this?

If a client requests X reviews for an app; take the last X reviews and sort those based on upvotes and downvotes.

We could create a lower boundary for “take the last X reviews”: when a client requests 5 reviews, odrs will internally take 20 reviews, sort them and return the best 5.

Advantages:

  • All reviews will have a time period at which they can be voted on. In the current system, after 20 reviews, new reviews will rarely show up in the first 20, so they can’t even be voted on in Gnome Software.
  • When software changes, the visible reviews will reflect that change quickly.

@Richard_Hughes what are your thoughts on this proposal?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.