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

[Andy Allan]

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

> 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.

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:

* This doesn't take into account length limits on the note field, i.e. making sure a user doesn't type too much and then being unable to save after the metadata is added
* There's no clear boundary between note comment and the metadata, for any system that tries parsing it or similar metadata added by other API clients
* There's no tests

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

Message ID: <openstreetmap/openstreetmap-website/pull/6764/c3847004213 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20260204/319ade79/attachment-0001.htm>