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/[email protected]>
_______________________________________________
rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev
