Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

star ratings- one rating per user per route? #1285

Closed
cgome opened this issue Nov 4, 2013 · 8 comments
Closed

star ratings- one rating per user per route? #1285

cgome opened this issue Nov 4, 2013 · 8 comments
Assignees
Labels
2: Bug fix Feature that does not work as intended, broken UI, problem that detract from normal user experience 5: Enhancement Build up on existing function that adds or improve functionality significantly Area: Logbooks Ticking & tick lists

Comments

@cgome
Copy link
Member

cgome commented Nov 4, 2013

Support email:

Hi guys, with the quality ratings system, theres a problem that if someone thinks a crap route (e.g. one they bolted!) is awesome, and cuts laps on it all the time and records it in thecrag as "megaclassic" 17 times, that outweighs 5 people who do it once and each rate it as crap and never go back. So,

  1. is it possible to have "one man one vote" for the quality of each route?
  2. if not then maybe a partial fix would be for the form to not autocomplete the quality field when you retick a route by recycling your rating from your previous tick. Leaving it blank (or greying it out?!) might encourage people to simply not rate the route the second time they record a tick and skew the average...
    cheers
@ghost ghost assigned scd Nov 4, 2013
@cgome
Copy link
Member Author

cgome commented Nov 4, 2013

I tend to agree with option (1). You should be able to add a rating each time you make an ascent if you want to, but only your most recent rating should contribute to the climb's overall star rating.

@brendanheywood
Copy link
Member

The rating should also be blank in the tick form, otherwise we're just prompting people with an answer that they will leave as the default.

@brendanheywood
Copy link
Member

This is also sorta related to what Will brought up the other day in #560

@brendanheywood brendanheywood added this to the Release 38 - Topo rewrite milestone Jul 7, 2014
@scd scd modified the milestones: Release 40 - profile update, Release 38 - Stats and annotation titles Jul 28, 2014
@scd scd modified the milestones: Release 41 - mentions, Release 42 - profile Dec 15, 2014
@scd scd modified the milestones: Release 42 - profile page filter, Release 43 - Streams Feb 27, 2015
@brendanheywood
Copy link
Member

Just a random thought I had from seeing this widget on buzzfeed for voting on articles:

image

Made me think that if we are going to decouple the vote from the ascent to make it one vote per person, would be be simpler if we also allowed votes without an ascent? If you log an ascent it would still show your last vote and you can set it again.

Also a counter example to the decoupling idea, some time I climb something in terrible conditions like it was wet or whatever, but I might repeat it later and give it a different vote. Should only my last vote be kept for the stats but we still keep the vote for each ascent?

@scd
Copy link
Member

scd commented Mar 5, 2015

If you have not climbed it should you be able to vote?

If you have climbed it then why not log an ascent as well?

Tying the voting to logging an ascent improves the data quality IMO. Also it encourages somebody to engage in the ticking process.

Maybe we can promote voting more in the index pages as a feed into logging ascents.

Another example against decoupling. When I first start climbing I do a route and love it - mega classic. After years of climbing climbing awesome routes I come back to the original route, and find it a bit ordinary. Both those votes have value and are telling us something.

@brendanheywood
Copy link
Member

If you have not climbed it should you be able to vote?

There is also something to be said for rating a route that you haven't yet climbed, which overlaps a little with the wishlist stuff I guess.

Tying the voting to logging an ascent improves the data quality IMO. Also it encourages somebody to engage in the ticking process.

yeah but this is a little self referential, the reason we want people to log, is so they provide ratings so we know what's good or not. So we can't say we don't want to have direct ratings as it won't improve the data quality.

So I think if we leave it as is, but make the stats only use the last rating then that solves the 1-vote issue.

@Drazhar
Copy link

Drazhar commented Sep 9, 2015

I'm also the opinion, that there should only be one rating per person. Shouldn't it be easy to just take the rating of one ascent into the statistic?

For example always the newest ascent rating of a person is taken into account.

@brendanheywood brendanheywood added this to the 50 milestone Aug 19, 2016
@brendanheywood
Copy link
Member

Fixed in #560

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2: Bug fix Feature that does not work as intended, broken UI, problem that detract from normal user experience 5: Enhancement Build up on existing function that adds or improve functionality significantly Area: Logbooks Ticking & tick lists
Projects
None yet
Development

No branches or pull requests

4 participants