search

theCrag / website

theCrag.com: Add your voice and help guide the development of the world's largest collaborative rock climbing & bouldering platform
https://www.thecrag.com/
111 stars 8 forks source link

Show last modified date on certain crag beta fields #3400

Open brendanheywood opened 5 years ago

brendanheywood commented 5 years ago

What happened?

This is to have a very quick way to assess how old the access notes are for a crag. eg if it was last edited 10 years ago then you might do some more due diligence in checking things are current. This is the most important for the access and ethics fields, but I think if done in a simple way could be added to all the fields (except summary?) with not too much additional clutter

What you expected:

lordyavin commented 5 years ago

+1

IMHO in general the change history needs some polishing :wink:

brendanheywood commented 5 years ago

IMHO in general the change history needs some polishing wink

Please be specific with examples. Some may already be in github

lordyavin commented 5 years ago

Looking at a sectors change history only the fields "Descent Notes", "Description", "Approach", "History" and a mysterious "Administrator Note" are displayed. No diff of changed text, no details about tags, location, ...

Looking at a routes cahnge history I miss the creation entry of Nicky and no infos about changed number of pitches, bolts or length. Oh and why is the edit history not visible to everybody? Wanted to have a quick look at the history of RIC but I'm missing the menu item.

brendanheywood commented 5 years ago

@lordyavin both of those links are legacy will not be touched again, which is also why they are not widely advertised or visible to everyone. The streams are the only place we are supporting since we introduced them. We know there are various bugs with the streams but that is where all improvements should be. So please only log bugs related to the streams, and please log them as separate issue as needed. We know about many already (and they should all be tagged with Stream + Bug):

https://github.com/theCrag/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22Area%3A+Streams+%2F+feeds%22+label%3A%222%3A+Bug+fix%22+sort%3Acomments-desc

lordyavin commented 5 years ago

IMHO streams don't reflect a version history and the concepts should not be mixed up. Streams are okay for social interaction to see the activities of a user but what if we need to revert specific changes or compare specific versions of a nodes data? Of course these are egde cases but the current stream system lags support for this use cases. Additionally it would be convenient to have some specialized UI for reviewing changes.

Does this make any sense to you? Should we branch of a issue for that?

quaestor commented 5 years ago

I also think that the streams are highly unpractical for reviewing changes made to nodes. I would love to have a feature like, say, wikipedia, where you can choose two versions of a page and compare the differences. Of course, it wouldn't have to be as sophisticated as that, having a static page with an informative change history would be enough from my point of view.

brendanheywood commented 5 years ago

Ok so under the hood is a raw activity log, you can see a basic view of this here:

https://www.thecrag.com/climbing/australia/mt-yarrowyck/activity

This is the rawest view of any changes to the data, in terms of atomic changes. But it doesn't show very much, but that is mostly display issues. Also each row in this maps directly to a potential karma score. For anyone who knows git you could think of this as similar to a 'git log' which shows you what was touched but it is a little hard to consume.

The streams are a layer which sits on top of the same data, but aggregates it into 1 event per use per day. Broadly it is doing a diff of the before and after and then presenting it, but it's a little more complicated than that because 2 or more people could do interleaving edits and revert things or whatever. In theory the stream should always show the state that user left it in, but it may be unclear what state it was in, or is in, if things we edited together.

The streams were designed to be a quick summary and then you can drill down into it. But the full stream event should be clearly showing the post edit state at that point in time. There are a few known bugs and we'll iron then out eventually. You can think of a stream events as a series of 'git diff's between batches of commits.

We don't have any way of picking two points in time and recreating a complete state and then a diff between them, but that would be awesome. In theory that is possibly with some caveats around how far back we can go and where some data was never recorded.

Either way the legacy process pages which show some of the edit history are very limited and we haven't touched them in ages and don't have plans to. As you said they don't show all sorts of data, they only show names and descriptions, not heights, tags, grades etc. Any time we invest here would be first spent on ironing out the bugs with the streams, then the raw activity log and then potentially on the arbitrary diff tool.

quaestor commented 5 years ago

I had stumbled upon the "activities" tab in the feeds before, but forgot about it. It's actually quite helpful already, thanks. If you could click on a change there to see the diff for a single "commit", it would already make it possible to compare different versions manually. So I will maybe concentrate on reporting more bugs concerning the streams. 😉