a.
Hides stars from route list unless at least N star ratings are cast. N is set to 3 now. Seems better/ok now, but might discuss this and alter this constant.
I vote for making it even more conservative or leaving it as is. I believe stars should be used sparingly and shown on routes where there really is a somewhat 'wide' consensus on the route's beauty.
But...
this may only postpone the same problem we have now... (to many routes with stars).
I fear that we will eventually come to all routes having some votes and most of them will average out to 1 star...
Maybe consider another way of determining stars shown?
only show stars if one of the possible starRatings has some predefined majority?
eg.:
0stars: 100 votes
1star: 100 votes
2stars: 100 votes
would now show one star
but if we define some 'majoritywise' condition, it might show no star, which would make sense, as consensus on the routes beauty in the above example has not been met.
this could for example be: 'show star rating if at least 50% of votes is of one kind'.
same example would now show no stars, but
e.g.:
0stars: 100 votes
1star: 100 votes
2stars: 201 vote
would show two stars
which might make more sense, as more than half of the voters agree that this should be a 2star route...
b.
Displays user's current starRating for a route, when a user is on the log form.
To test:
a. Pull live db to local, then open e.g. 'Kotečnik' crag and see how many routes have stars.
b. log some routes, give star rating. then loge same routes again and see that your previous star rating gets displayed in a hint.
update:
calc of star ratings are done on BE now. see linked PR. It is done more or less as suggested above with some additional conditions as discussed.
a.
Hides stars from route list unless at least N star ratings are cast. N is set to 3 now. Seems better/ok now, but might discuss this and alter this constant.I vote for making it even more conservative or leaving it as is. I believe stars should be used sparingly and shown on routes where there really is a somewhat 'wide' consensus on the route's beauty.But... this may only postpone the same problem we have now... (to many routes with stars). I fear that we will eventually come to all routes having some votes and most of them will average out to 1 star...
Maybe consider another way of determining stars shown? only show stars if one of the possible starRatings has some predefined majority? eg.: 0stars: 100 votes 1star: 100 votes 2stars: 100 votes would now show one star
but if we define some 'majoritywise' condition, it might show no star, which would make sense, as consensus on the routes beauty in the above example has not been met. this could for example be: 'show star rating if at least 50% of votes is of one kind'. same example would now show no stars, but e.g.: 0stars: 100 votes 1star: 100 votes 2stars: 201 vote would show two stars which might make more sense, as more than half of the voters agree that this should be a 2star route...
b. Displays user's current starRating for a route, when a user is on the log form.
To test: a. Pull live db to local, then open e.g. 'Kotečnik' crag and see how many routes have stars.
b. log some routes, give star rating. then loge same routes again and see that your previous star rating gets displayed in a hint.
update: calc of star ratings are done on BE now. see linked PR. It is done more or less as suggested above with some additional conditions as discussed.
Test this with: https://github.com/plezanje-net/api/pull/133
closes #383