nenad-vujicic left a comment (openstreetmap/openstreetmap-website#5904)

> I think this PR would benefit from outlying in more details exactly _**why**_ 
> is it doing changes (i.e. what exactly new user-requested functionality will 
> become available), instead of just enumerating low-level technical steps 
> which are being done. Judging by few words and linked PR discussion, I guess 
> it might have something to do with enabling users to add tags to notes and 
> thus making notes mutable, but I cannot really tell what is an actual idea 
> being implemented, and what are technical side-effects.

@mnalis thanks for feedback! PR's main contributions are:

1. Adds mutable note tags. Why do we (both developers and mappers) need them? 
Do we want to continue writing hash tags (#surveyme and similar) instead of 
clicking "add tag" button (still not implemented)? Do we want to read hash tags 
from discussion's comments instead of having e.g. a table with tags and using 
appropriate API calls which will do this in an efficient and proper way 
(implemented)? Do we want to manually filter / search notes or use 3rd party 
tools across the www instead of having much better stuffs on one place (still 
not implemented)? I think the answer is "Yes, we would like to have add tag 
button, see a table with tags instead of #tag-name and searching / filtering 
ability on OSM". Why mutable? Some note tags are naturally static (e.g. 
created-by) while some are naturally dynamic (e.g. edited-by, language, ..), 
also we need to allow adding / deleting after creation (because of input 
errors, changing circumstances, ..).

2. Adds note versioning. Why do we (both developers and mappers) need it? I 
believe having an efficient way to retrieve note's provenance (mostly 
implemented) is important to enable building efficient notes history viewers 
like we currently have for elements (e.g. 
[this](https://pewu.github.io/osm-history/#/)) to enable moderators more 
efficient note's inspection (at the moment this is very slow and fully manual, 
but in future it will be much faster (still manual) at the beginning, 
semi-automatic at one moment and eventually almost fully automatic). Also, on 
OSM website's source-code level, we are moving "special comments" from note's 
comments to "version's parameters" which will bring us much better 
decomposition and easier maintenance (also, as a side-effect, we are preparing 
for removing special comments from `Discussion`, leaving it to only end-user's 
comments, in the next API increase).

> > plus update functionality (we would have new event type - update) something 
> > you would like?
> 
> I don't think that notes would benefit from being changed, in fact it would 
> likely be very bad. I.e. if note could be moved or its description changed, 
> followup comments could be misunderstood or turned out of context. Also, it 
> would make necessary not only API/UI to see what changes were being made and 
> when, but a new (or extended) planet.osm.org dump (like we have e.g. 
> `planet-*.bz2` as well as `history-*.bz2` for nodes/ways/relations).
> 
> Only part of Note that should be modifiable IMHO is implementing #hashtags, 
> the rest of the notes should better remain immutable. Having versions, 
> locations and descriptions being changed are IMHO likely to introduce much 
> more chaos then help.

At the moment, this PR supports modifying note's description, latitude / 
longitude and note-tags. At the beginning I wanted to support only modifying 
tags, but added support for other fields because of 
[this](https://github.com/openstreetmap/openstreetmap-website/issues/5294#issuecomment-2541473139).
 For me, it's not a problem to remove modifying note's description and latitude 
/ longitude (in database table `note_versions` we would remove columns 
`latitude`, `longitude`, `tile` and `description`) and enable modifying only 
note-tags.

> **TL;DR:** can you list example use-cases and how this PR addresses them 
> (i.e. _"users currently do this thing xxxxx which is inconvenient, and with 
> those changes implemented they will be able do this other thing which is 
> easier/better because yyyy"_)

The purpose of this PR is to show current proposal of how note's could look 
like. I will update this PR with new features until above functionalities are 
added and remove stuffs from it when they are committed / rejected. Use-cases 
we are trying to improve are (among others):

1. At the moment mappers use hash-tags. In near future we could use buttons for 
creating / updating / deleting note tags. Similarly for reading, instead of 
passing through note-comments, we will have a table like for elements (this is 
implemented).
2. At the moment mappers manually search / filter notes. In near future we 
could use UI for defining searching / filtering criterias.
3. At the moment mappers manually inspect notes or use 3rd party tools. We 
already have implemented (in this PR) retrieving particular note's version, 
which gives us a chance to build note's history viewers / analyzers for 
automatizing parts of note's inspection.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/5904#issuecomment-2860333861
You are receiving this because you are subscribed to this thread.

Message ID: 
<openstreetmap/openstreetmap-website/pull/5904/c2860333...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev

Reply via email to