Ascent grade not persisted in new tick flow

[dnnr]

The new tick flow appears to not persist the ascent grade like the old tick flow did. Instead, the ascent grade is inherited from the route, meaning it can change later whenever the route grade changes.

In my opinion, this is a major bug in terms of potential user frustration, confusion and ultimately loss of information.

Due to this issue, I recently gained an full grade of onsight ability thanks to nothing more than some guy breaking off a hold after I've climbed the route and subsequently upgrading the route. Based on this observation, I surely hope that the new behavior wasn't actually intended.

[Arzorth]

This behavior could be interesting with routes tagged as project, but indeed, generalised it can be dangerous.

[quaestor]

Bump. This might actually be important since it can mess up people's logbooks and statistics. @scd @rouletout opinions?

[dnnr]

Emerging from my winter hibernation and logging my first ticks this season, I'm surprised and saddened to see that this issue still persists. Entering the grade manually for every ascent is a real pain...

[quaestor]

Another bump. Any news here? @scd @rouletout don't you think this is a conceptional mistake?

[lordyavin]

And a bump from me

[scd]

It is an intentional change that ticks track the grade of the route by default. You have to put in your own grade if you want to stop it tracking.

[dnnr]

What's the rationale? Routes can physically change (and with them their grade) without that carrying any weight for ascents in the past. I get the idea of wanting grade corrections to propagate. But that surely can't outweigh the users' expectation of theCrag to act as a system of record, can it?

At least at the point of logging an ascent, users explicitly accept and acknowledge the route's current grade for their ascent. For all we know, they personally might strongly disagree with any future up- or downgrades. But now theCrag makes that choice for them and they don't get any say in it. It should be up to the user, not the community, to update their past ascent if they change their opinion.

(And I assume I don't need to argue The Power of Defaults here; it doesn't matter that you can turn this off manually on every single ascent. That said, a user setting allowing to change the behavior permanently would certainly help.)

[Arzorth]

I would like to point the difference between two possible route grade changes:

1. A route having its grade reassessed and therefore affecting all the past ascents, even tho the users don't like their ascents to be downgraded (example, Bibliographie being downgraded affected Alex Megos ascent).
2. A route changing grade at a given moment forced by a change in the route (chopped, rock falling, restoration, etc), in this case the ascents in the past should never change, because the route, at that time, had one grade, and now has a different one.

For the first case, I think the system works perfectly as it is right now, for the second case, it clearly doesn't.

This could be solved by implementing "Intervals of Grade", by default, a route would have only one grade for all its existence, but there could be an option to change the grade from one point onwards (just like we can now set dates for route setting, first ascents and so on), this would keep the grade of past ascents and at the same time allow new ascents to have the new grade, it would also allow people to log in the present ascents climbed in the remote past (before the change) and the grade would be automatically set to what it was in that time.

Regards

[quaestor]

@scd You will never know at the time of logging whether a hold will break, so at the moment you cannot make an informed choice whether to put in your own grade or not. Furthermore, as @Arzorth pointed out, there are two reasons why a grade can change: once again, you will never be able to say beforehand which one of the two, if any, will occur.

@Arzorth: I think I see what you're trying to do, but this seems to needlessly overcomplicate things. You'd have to make this very clear to the users and I don't how, most people would just be confused (and there are probably lots of backend changes involved as well).

As far as I am concerned, the process of logging is a commitment to one's own idea of how the route in question felt: every aspect of the ascent should represent that; and up to the discussed change, that was the case. You're entering your own comment, your own quality rating, etc, and therefore also your own idea of what the grade was. (Admittedly, there's a sole exception: length, where the default is to track the route length. Arguably, the length is something which is often not even present and therefore the benefit of tracking it outweighs the possible ramifications when a route length in fact changes, e.g. due to rock fall.)

[killakalle]

As far as I am concerned, the process of logging is a commitment to one's own idea of how the route in question felt

There is the newish functionality of "Suggested Grade" where you can note what the grade really felt like to you. See the following two examples:

This works very well with the case:

A route having its grade reassessed and therefore affecting all the past ascents, even tho the users don't like their ascents to be downgraded (example, Bibliographie being downgraded affected Alex Megos ascent).

[Arzorth]

It works with that case but bit with the case:

A route changing grade at a given moment forced by a change in the route (chopped, rock falling, restoration, etc), in this case the ascents in the past should never change, because the route, at that time, had one grade, and now has a different one.

For that, intervals would still be needed, or closing the route and opening a new one with different grade.