Comment 1 Quim Gil 2007-11-20 10:58:47 UTC

The way we have solved this is to differentiate completely between OS versions.
Fulfills the need you detected.

No, I think this is still a valid bug.

The date is now displayed, but the version at the time of the rating is still
not visible.

For example:
An application has abad rating for version 0.1 and a number (lets say two or
three) good ratings for version 0.2 (because the packaging bug has been fixed).

Another user is not really able to see who is right and cannot judge if he
should try the application or not. The date gives a hints but only a added
version would give exact information.

I have seen some applications in the application manager which have bad rating
likely because of buggy installation. I have avoided them all.

This does not have anything to do with OS versions but with package versions!

It would also be nice to comment once on rating. For example EightyOne has a
rating that contains a feature wish, which has been implemented in the current
version.

Comment 3 Quim Gil 2007-11-22 09:03:50 UTC

Good points. Let's take them and see what can be implemented and how.

Nils, does this ring any previous thoughts you have had? I just don't want to
reinvent a wheel that is in your mind already.  :)

Comment 4 Niels Breet 2007-11-22 10:33:13 UTC

(In reply to comment #3)
> Good points. Let's take them and see what can be implemented and how.
> 
> Nils, does this ring any previous thoughts you have had? I just don't want to
> reinvent a wheel that is in your mind already.  :)
> 
This would require a complete rewrite of the rating system. Currently ratings
have no connection with software version. They also just summed up and divided
by the number of comments/ratings. We would need to add support to calculate
the rating per period of time (The time between a software version was released
and the next one) Or we should at least calculate the ratings from the moment
in time the product was released.

Keep in mind that most products wouldn't have any ratings because they only get
rated every once in a while. If you release versions often, you would have no
ratings until the first person rates that version.

I don't think people come back often and rate the same product again and again.
But if you do think that, I would happily implement it.

The ratings have been designed as a simple feature. If you want 'complicated'
things like this, something completely new has to be designed.

Comment 5 Quim Gil 2007-11-22 10:47:05 UTC

Would it be complicated to show it like this:

[version number] rated [stars] by [userid] on yyyy-mm-dd hh:mm

i.e.

v2.2.2-0nix0 rated ***** by adam p (2007-11-13 11:44)
at https://maemo.org/downloads/product/OS2008/pidgin/

I agree that recalculating stars based on age etc would be way too complicated.
If we ever touch this would be to implement a fav/bury/karma system like the
social news. They take age into account (but differently).

Comment 6 Niels Breet 2007-11-22 11:05:53 UTC

(In reply to comment #5)
> Would it be complicated to show it like this:
> 
> [version number] rated [stars] by [userid] on yyyy-mm-dd hh:mm
> 
> i.e.
> 
> v2.2.2-0nix0 rated ***** by adam p (2007-11-13 11:44)
> at https://maemo.org/downloads/product/OS2008/pidgin/

We don't store version history, so even that would require quite a bit of
change. :(

> I agree that recalculating stars based on age etc would be way too complicated.

Actually, I can add support to calculate ratings made in the last XX days. So
it will have a sliding window. Ratings made before that date would not
influence the current avg. anymore. This might be even more fair than what we
have now.

> If we ever touch this would be to implement a fav/bury/karma system like the
> social news. They take age into account (but differently).
> 
I think that this is a better plan.

Comment 7 Quim Gil 2007-11-22 11:15:22 UTC

So you mean that the number of votes would be still 100% cumulative no matter
how opld the votes are, but their influence on the rating would disappear after
x time?

Sounds interesting. What about a timeframe of 4 months?

We still need to figure out some cases:

- Would then applications with old rates disappear from the top5 (unless they
keep getting ratings) being the new ones taking over? That would be nice to
make sure that the old farts don't get stuck at the top "just" because they
were first.

- Corner case: if we have 5 apps only and they get less and less new votes,
would they still be listed in the top 5 or would they disappear progressively
because they don't get enough new votes? This is perhaps not that corner case
if we think in the mid term of OS2006.

- Is it clear that people could renew their old ratings with refreshed ones,
even if they have the same value?

Comment 8 Niels Breet 2007-11-22 11:27:26 UTC

(In reply to comment #7)
> So you mean that the number of votes would be still 100% cumulative no matter
> how opld the votes are, but their influence on the rating would disappear after
> x time?
> 

Yes

> Sounds interesting. What about a timeframe of 4 months?

I guess that is a reasonable timeframe. If we get loads more applications and
people rating applications we can always change that value.

> We still need to figure out some cases:
> 
> - Would then applications with old rates disappear from the top5 (unless they
> keep getting ratings) being the new ones taking over? That would be nice to
> make sure that the old farts don't get stuck at the top "just" because they
> were first.

That will happen automatically as more and more older ratings don't get help
the avg. rating.

> - Corner case: if we have 5 apps only and they get less and less new votes,
> would they still be listed in the top 5 or would they disappear progressively
> because they don't get enough new votes? This is perhaps not that corner case
> if we think in the mid term of OS2006.

They would disappear. But that would also mean that people completely lost
interest in those applications. Which would be about the same time you should
start to think about dropping support for the OS ;)

> - Is it clear that people could renew their old ratings with refreshed ones,
> even if they have the same value?
> 

You tell me ;) Technically each comment/rating they give counts. Older ratings
will not be relevant for the stars after the said amount of time.

Comment 9 Quim Gil 2007-11-22 11:30:58 UTC

Then I think we have the elements for a fix in the direction pointed by Tim. It
is not as verbose and explicit as Tim suggested but at the end it will promote
fresh ratings and punish the rest.

Tim, are you ok with this?

The sliding window aproach is OK for me. Note that there is a corner case,
where the whole community has voted for application. In this case the
application would still disapear over time from the top 5. The aporach assumes
there the community is infinite. But I think one can ignore that.

I still think it should be possible to the version at the time of the rating as
part of the rating information.

Currently the rate, the comment and the time is displayed. Why is it difficult
to the the version?

Nevertheless, I take what I can get and I got more than I expected ;-)

Comment 11 Quim Gil 2008-06-29 11:40:04 UTC

Thinking a bit more about this, I think we could go for total simplification
and introduce here the thumbs up/down we are using in news, with the same karma
principle.

Instead of "Stars", the block would be called "Hot" and would reflect not only
cumulative "love" but also, and most importantly, what is receiving a lot
positive feedback now.

The karma should be calculate da bit differently, since age is not bad per se.
In the news an article older than one week disappear from the scope, full stop.
In the Downloads an app can be months/years old but get a new version with a
consequent refreshed love (users that rated this app could rate it again, I
guess) and all the new users loving it.

Needs a bit of thin king but in any case I think the solution is simpler both
for Niels and the users. And we reuse and improve the karma module that so good
service has been done until now.

Assigning to Patrik since this was marked for him to the current sprint.

There's a lot of discussion here, but little specifics have been *decided*. 
If we go forward with just a favourite/bury system(thumbs up/down) instead of
stars, there are some questions that need to be decided...

Apparently stars aren't going to be retained. Now they are used for affecting
app visibility in various places. How? Only the faves in the last four
months(or what timeframe) count, like a decaying average? Should a user be able
to re-fave/bury after that, or after a new version comes out? Should anonymous
users be allowed to fave/bury apps? How should it affect user karma?

For easier tracking, here's the Nemein internal bug number:
https://hanska.nemein.net/trac/nemein/ticket/1708

Comment 15 Ferenc Szekely 2010-04-19 11:08:12 UTC

Time to refresh memories about this bug. What shall we do?

-Change the stars to a thumbs up/down as suggested by Quim

-Add support for storing "date" info for each rating and then implement the
"sliding window" suggested by Niels

Let's decide and then we can take this further.