maemo.org Bugzilla – Bug 2179
Visualize rating creation date and related software version
Last modified: 2010-04-19 11:08:12 UTC
You need to log in before you can comment on or make changes to this bug.
EXPECTED OUTCOME: Ratings on http://downloads.maemo.org should mention the creation date and the corresponding software version at the time of the created rating. This way the user may have some hint if the comment is still true. I for example have a rating that requests a featurethat is already implemented in the current (neer) version. ACTUAL OUTCOME: rating without date and application version. STEPS TO REPRODUCE THE PROBLEM: Just take a look at your favorite rated package like http://downloads.maemo.org/product/eightyone/ :-) OTHER COMMENTS: Of course it would be nice, if older ratings rate less and current rating rate more. So if my software once was buggy but now is not anymore I have the change to get the application out fo rating hell :-) Coloring of ratings may help, too.
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.
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. :)
(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.
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).
(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.
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?
(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.
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 ;-)
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
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.