RfC: deprecate hashtag-only changeset comments

General talk
1

Hi there,

I am disheartened by the fact that after years of politely arguing for human-readable changeset comments, and politely pointing out to newbies that hashtag-only changeset comments are undesirable, the majority of new OSM users are still using them. Here’s a sample from the last couple of hours:

  • #hotosm-project-14894 #OpenCitiesLAC #factset
  • #CanCross #StarbucksMaps
  • #starbucksmapping #cancross
  • #cancross #starbucksmaps
  • #hotosm-project-15476 #moroccoearthquake2023 #OPSGIS2023
  • #hlgivesback
  • #hotosm-project-15153 #jpmc #hlgivesback

The majority of new users now uses hashtag-only changeset comments, which is disrespectful to anyone not within the inner circles of whatever “#hlgivesback” or “#cancross #starbucksmaps” is.

I suggest the following actions:

  1. reach out to the makers of tools (mostly Tasking Manager) and ask them to ensure that human-readable comments are a required first and hashtags are an optional second.
  2. after a while - maybe 3-4 months -, start automatically adding comments to any changeset that has a hashtag-only changeset comment, politely asking that these be avoided.
  3. after another while - maybe another 3-4 months -, start enforcing this request by either (3a) automatically blocking any account that repeatedly uses hashtag-only changeset comments and/or (3b) automatically reverting any changeset that has a hashtag-only changeset comment.

Opinions?
Frederik

21 Likes
2

I’d also like to see it as a requirement that any particular HOTOSM tag also linked directly to a page / site for that project.

Same would apply to any similar program such as the Starbucks you mention, or the #geostar2023 we had a few weeks ago, & if there’s no page to link to, then the whole thing be treated as an undiscussed import & reverted.

5 Likes
3

I would like to add that a changeset comment should generally be a mandatory field in editors. This is often left completely empty.

4 Likes
4

I thought that it is obvious that such hashtags are addition to actual changeset comment, and actual changeset comment is needed? As described at Good changeset comments - OpenStreetMap Wiki

But I would be happy to reaffirm this. And agree with proposed actions, though “3-4 months” seems weirdly long delay to enforce already standing good practice.

Maybe JOSM and iD should start complain about hashtag-only changesets? Not sure is there already ticket for that on their issue trackers.

7 Likes
5

The iD project long ago concluded that hashtags don’t belong in changeset comments. In 2017, a separate hashtag key was introduced, and any hashtags entered into the main comment box or URL query parameter are automatically copied into this key. However, for backwards compatibility, iD temporarily, reluctantly left them in the comment key too. OSM Stats apparently has yet to migrate to the hashtag key. I’m unsure if any other data consumers have been blocking iD from finishing the migration process.

Removing the hashtags from comment would mitigate this problem of hashtag-only comments: without the hashtags, the comment would be empty, and iD already disallows empty comments. It would also solve the problem of incorrectly misidentifying IRC channels and other innocent uses of the # symbol as hashtags.

9 Likes
6

Agreed:

2 Likes
7

I’m not sure there’s anything to depreciate here. They are bad practice and unhelpful. Many of them aren’t even documented on the wiki. Having said that, I don’t think I’ve entirely managed to avoid them myself especially when tools override JOSM defaults and don’t reuse the more descriptive comment you used 10 minutes ago for the same task in a slightly different bounding box.

Anecdotally, I think hashtag only comments are normally the result of poorly coordinated “organised” mapping. If an organisation is using a hashtag they haven’t even bothered to put in the wiki then I think these are changes we should consider just reverting unless someone has come along after the fact and added a clarification in the changeset discussion. Some genuine new users might be adversely affected by this, but as it takes very little time to add to the wiki page for the campaign that should be easy to avoid.

I don’t really know what to to say for documented ones. If they really are new unpaid users, we could miss out on good contributions if we are too strict.

1 Like
8

iD is very stubborn about this. Any # anywhere in the comment generates a hashtag. Deleting hashtag changeset tags doesn’t work.

9

Those hashtags are not equally bad. For example, #hotosm-project-nnnnn contains a project id which you can use to find the project. Now imagine that a project title was also added to the comment. Would such a comment still be bad?

3 Likes
10

I just checked on Organised Editing Guidelines - OpenStreetMap Foundation

Quote from there:

Changeset comments should include the unique hashtag described on the wiki page under Organised Editing/Activities/Name of the Activity (as described in the Process section), and link to that page.

There is no word that a changeset without text describing the change (only hasthag and link) is bad. Maybe this could be added there?

1 Like
11

<sarcasm>
You are all so yestercentury just drop comments all together, I’m sure Facebook will be more than glad to replace them with a <insert fav LLM> generated text on demand.

See also add a generic descriptive changeset comment if mapper did not add any changeset comment. · Issue #2392 · MarcusWolschon/osmeditor4android · GitHub
</sarcasm>

12

Without explanation of edit contents? Yes, still bad.

#hotosm-project-nnnnn can be potentially useful if it allows to track down who is responsible for specific organised edit and reached person will react to feedback. But it is only addition to the comment, not replacement.

2 Likes
13

Maybe “Changeset comments should include the unique hashtag described on the wiki page under Organised Editing/Activities/Name of the Activity (as described in the Process section), and link to that page. Such hashtag should be addition to proper description of edit and does not replace it.” ?

Though not sure is it worth enlarging this document, it should not be documentation of all good practices. There is already “Any person or organisation whose actions affect the OpenStreetMap project has the duty to care for the project, and should respect the community’s consensus, mapping practices and guidelines.”

And actions proposed in top post should handle problem already.

14

Hashtag-only comments at least provide a vague indication what the edit is about. A much worse problem, that I’m looking at every day, are comments devoid of any informative value, such as “update”, “landscape”, “survey”, “Sarajevo”. My favorite is the bloke whose only changeset comment ever made is “changed some things”. I’m at loss how to deal with those, often quite experienced, mappers; I don’t feel like playing changeset police. Perhaps forcing the comments to contain at least five words or 30 characters? (Which will inevitably lead to comments such as “aaa aaa aaa aaa aaa” as their next line of play).

5 Likes
15

make changeset comment linking Good changeset comments - OpenStreetMap Wiki ?

write to DWG and ask them to apply 0-hour block with explanation?

Though if that counts as

then I guess you need to accept this this will be happening or wait for someone else to do this.

16

One very active mapper and ideally in country covering bound boxes when there’s small changes, not anything to do with building spread across from coast to coast.

“Added some buildings based on Bing”

Queried and commented, never a reaction, never changes, just this one. Could as well just do the automated hastagging and JOSM, 10 chars is enough.

The Neis report actually computes comment variations, there were in a long ago past: Unique comments (259 (4.1%). Absolutely positively useless filler, or if one of these “always the same comment” retorted back “If you want to know, check the details.”

Maybe a zero block candidate too but then it would be a never ceasing DWG bombardment of such requests. It’s nice to have this comment box saving the previous 10-15 comments to pick from … maybe just the last one and maybe a machine check… “Does this comment apply to the present changes you’re going to upload?”

17

This post might get me tared and feathered, but I actually think automatic changeset comments by default could be useful.

Pretty much all examples of good comments, including those on the wiki page, have the following format (using some pseudo-syntax):

(added|updated|removed) (<object type>|<name>) [in <place>] [based on <source>]

All of this can actually be automatically generated; the type of change and object type (or name) based on the contents of the change, the place can be calculated based on admin boundaries or place= and source taken from the existing source= changeset tag.

I think that for an overwhelming majority of good changesets (that is, they are delimited in some way, i.e. only changing buildings in one town or updating speed limits in a country or similar) a comment like the above could be generated and would be as good or better (if the mapper themselves is bad at writing comments).

That has its limits though; and a good anti-example are the comments generated by some unnamed apps that look like “Added 3 shops, 2 playgrounds, 9 trees, 1 dog, 42 things, 98 addresses, 19 sandwiches” and so on. However, those cases might be possible to improve, the above could for example be rewritten as “Added shops and amenities in Stockholm based on walking around” or similar.

Another interesting case is StreetComplete, those changeset comments by themselves are alright, however since it by default splits it by quest type you can end up with a large number of small changesets, where it might have been more clear to have one with a comment such as “Updated details about streets in Stockholm”. Though that’s of course another discussion altogether.

Then again, for comments that can be automatically generated they could just as well be automatically generated when requested for reading, which would have the added benefit of adjusting the generation algorithm according to other aspects (if showing a list of changesets filtered by country we don’t need to show “in ”, since that’s sort of already expected).

So maybe another approach could be to discourage writing changeset comments completely, unless they add value that cannot be generated?

I actually believe that that would improve the average quality of changeset comments, though it would require some development work on the OSM website and other places displaying changeset comments. It might be interesting to try to generate a few days worth of changeset comments and compare them side-by-side with the comments provided by the mappers.

8 Likes
18

You’re joking, but I can thing of at least one example where someone added some LLM-generated crap to an OSM wiki page in the hope of being helpful.

19

how source can be automatically guessed? How it can be automatically established whether someone deleted building based on aerial, based on survey there, or on news article or based on existing OSM data or (invalidly) mapped based on GSV?

20

I think that ‘What was changed’ doesn’t need to be in the comments, because the changeset already contains the changes.
You would want why it was changed, and the source(s) of the information.
If it’s a project or a community mapping thing, you would want a link to the project information or mapping agreement/discussion.
None of this can -in general- be automated. Of course a tool can have information and if so, put it in he changeset comments.
If the changeset processing tries to force things like this, I think many people will supply junk text just to get the stuff uploaded. We will end up with even more useless dummy comments.

I really don’t care if there is or is not a hash in the text.