Add a suffix to text of anonymous notes#6764
Add a suffix to text of anonymous notes#6764deevroman wants to merge 1 commit intoopenstreetmap:masterfrom
Conversation
deevroman
changed the title
|
Maybe when you're ready to accept review comments somebody will be prepared to review your work. |
|
It seems you misunderstood «Just don't tell me we need to implement real tags and note versions in the data model» I was trying to warn you against prematurely dismissing PR by analogy with #3938 because my PR only affects anonymous notes, that irritate the community |
|
The point is that I have no idea what my review comments would be if I were to review this but I do know that trying to pre-emptively say that certain possible comments are somehow not allowed is not acceptable as far as I'm concerned. |
|
For future reference, the text in the PR description reads like a rebuttal or retort. It wasn’t clear who you were responding to, so it took on a more aggressive tone than you probably intended. In general, it is a good idea to explain how your PR differs from previous proposals, keeping the focus on the code and your thought process. You could clarify that the PR doesn’t add extra metadata to the database table and you don’t think it’s necessary for this part of the fix. Also, you could also point out that this PR avoids using literal hashtags, as suggested by the maintainers in the issue. |
Well then, there's not much for me to say here, is there? You're proposing adding metadata to the notes, but by cramming the metadata into the note comment field, instead of adding the metadata in a separate field. This is bad engineering, and it just stores up problems for the future. If we add this now, people will start relying on it (either from reading habit, or through scripts or data processing which parses the note text against a particular pattern to find the information). Other API clients will want to know if they should add a suffix too? What format does their metadata have to follow - are both newlines required? Can you parse out the client information from a given note - or do we need something more recognisable as a separator? Then when we want to solve the metadata problem properly, i.e. adding metadata as a separate field, we have created headaches for ourselves (do we migrate the existing notes to move the existing metadata to the new fields? Do we have to keep adding the suffix, even when we have the new metadata fields, because some unknown number of 3rd-party systems have been built to rely on the inline metadata? Now you can argue that any of these points are no big deal, but they illustrate the reason that maintainers will push back on your approach. Yes, it's quick to implement. Yes, it avoids learning how to make database and API changes, so it's as low-effort as you can possibly achieve today. But the low-effort is not improving the long-term situation. It's just pushing back the complexity into the future, and in fact adding to the complexity for whoever tries to implement it properly. It's not a first step towards a solution. Adding metadata fields to notes would be easier today, without this PR, than it would be in the future if they also have to consider dealing with how to handle the outcome of this PR too. Also, adding metadata fields to notes is not some "huge overengineering" project, it's a few database fields and additions to the API. It's the right approach to solving this problem, and this PR is not. As for a review request, I'll do that too:
|
|
It's been a few months, and I've re-read this conversation and the linked issue. I'm going to decline this PR, for the reasons I gave above. @deevroman thank you for your PR. I'm happy to help you if you want to revisit this topic. I do mean it when I say that adding metadata fields is not overengineering and so I would encourage you to consider working on that. |
|
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 #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 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. |
this is written at the very beginning of the description. Even with a smiley face to lighten the mood a bit. |
If you mean #5294, @gravitystorm and I agreed in #3932 (comment) that tags for notes are overkill for this particular purpose, and it seems like you’ve come to the same conclusion. Freeform tags might be useful later if we decide to turn the notes system into a full-blown bug tracker, but that’s a very different discussion. We’re suggesting instead to rely on an HTTP header or additional request parameter – which is not tags – to positively identify the software that’s sending the request. Increasingly OSM-related APIs are expecting this information anyways in order to fight overactive bots. |
I didn't say or agree any of this, just to be clear. I don't agree that tags are overkill, but it might be helpful to remember that there are more than one type of tag in OSM (immutable kv like changesets, versionable kv like nodes, let's not discuss trace tags...) so there might be some misunderstanding there. I also didn't say that http headers or additional request parameters should be relied on, that would be inconsistent with the rest of the API which expects information to generally be sent in document bodies. What I did say is that we shouldn't use the HTTP User-Agent strings for this purpose. |
|
OK, that’s my misunderstanding then. But overall, it sounds like we have options between the polar opposites of text appended to the note itself and versioned tags à la elements. |
I'll just note that the implementation of the first does not prohibit the second. Many years ago, created_by was also used in object tags, but after the advent of changesets, editors switched to a new way of storing metainformation. |
|
That’s true, but note text is immutable unlike element tags. So we’d have to migrate the notes on the backend using pattern matching I guess. The analogy I’d use is that, after editors started using a dedicated |
But why? Just start from scratch. Information about all existing notes can't be restored anyway. Notes are primarily for human consumption. No one promised to structure the bits of information about notes, as they are not the final product of OSM. |
4 participants
Description
Partial solution #3932
All anonymous notes are suffixed with "via OSM website." Similar to StreetComplete (without hashtags :)
2026-01-31.00.42.50-optimised.mp4
Just don't tell me we need to implement real tags and note versions in the data model. That's a huge overengineering for a simple problem. Metainformation in the text of notes does not bother anyone except the authors of notes who suffer from perfectionism.
Hashtags and their equivalents already work great in other apps and help resolve notes. Let's first explore how website users use notes, and then consider what changes we need to make to the data model.
We'll also finally find out if there are apps that use anonymous notes via the API.