[openstreetmap/openstreetmap-website] Add a suffix to text of anonymous notes (PR #6764)

[Roman Deev]

deevroman left a comment (openstreetmap/openstreetmap-website#6764)

well, I've been postponing returning to communication in this repository until I restore my local environment for testing, but...

---

About anonymous notes. I suspected that adding metadata for all the notes would cause another dispute. So I decided to start with something less important, such as anonymous notes. Because even that, combined with https://github.com/openstreetmap/openstreetmap-website/pull/6593, would have an interesting effect. Note processors could understand when vandals were using the API rather than the website to circumvent the proposed rate limits. And close all such notes without hesitation. I should have mentioned it explicitly, it's my fault.

---

And who allowed the tools to be tied to the format of the text in the notes? The tools already have to parse various formats of note texts, and they cannot rely on the consistency of their format. Why do notes created on the OSM website suddenly give such a guarantee?


By the way, do you know how much code it takes to parse `created_by=` in changesets? You need a whole database to be able to normalize the editor name. https://github.com/piebro/openstreetmap-statistics/blob/master/config/replace_rules_created_by.json

So we simply turn the problem of parsing the text of notes into a problem of parsing tags.

---

This argument looks especially weak after you have broken backward compatibility in the API at least twice, arguing that the API does not have official documentation. And here we are not talking about the API at all.

In the issue, you have selected examples that are related to the API or backend. It's important to work out the API correctly, I'm not arguing. But are you sure that you won't allow architectural problems when implementing the API for real tags/versions? Are you sure that you understand all the wishes of the users?

---

Okay, we want tags for notes. 

One reason is that it could potentially make it easier to find specific notes. But how are you going to filter by tags? There's no such mechanism. However, there is a mechanism for searching by substrings in the note text.

Without this, you will still have to read notes manually, regardless of whether the metainformation is in the note text or in tags.

---

By the way, you were worried about API consistency. Have you decided whether you'll move the note text to the comment= tag, similar to changesets? If so, how will you maintain backward compatibility? If not, you're losing API consistency.

---

But let me remind you that this isn't the main reason you want tags for notes. The community is asking for them to be categorized by importance/type/type of fix needed/etc. But are you sure you understand how this will work in practice?

How are you going to clarify the type of note if the author was too lazy to indicate that it is important?

You'll have to change the note text. Hello, versioning! Not only is this difficult to implement on the backend, it will also complicate the logic of client applications. And moderators might even hide notes...

What do people do now? They just add hashtags in the comments. It's easy, and suddenly they're searchable in the existing API.

This gives me an idea. Maybe we don't need to create a Jira-like after all? For example, maybe we should think about how we can improve the quality of notes? https://community.openstreetmap.org/t/we-dont-need-anonymous-notes/105335/67 Instead of predicting what needs to be changed in the API, we could experiment with it without breaking a sweat.

---

You also appeal to technical debt. But why are you forgetting about technical debt for projects that use notes? Who will ask developers to switch to a tag-based system? And for what purpose? 

---

Of course, I deserved a cold review and attacks about the need for tests. But it's rather ironic that your current tests haven't  fall from my change.

---

It's amazing, of course, what kind of disputes such trifles cause.

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

Message ID: <openstreetmap/openstreetmap-website/pull/6764/c4389578849 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260506/1b1123a5/attachment.htm>