RfC: deprecate hashtag-only changeset comments

[快乐的老鼠宝宝]

Yes, we should be more cautious about modifications and deletions, so the requirements on changeset comments are stricter (especially deletions)

[Tordanik (Tobias Knerr)]

@Mateusz_Konieczny

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 sire is it worth enlarging this document, it should not be documentation of all good practices.

A small tweak to the Organized Editing Guidelines which could be useful in this context is to change “Changeset comments should include” to “Changesets should include”. As written, the OEG currently do not allow the hashtags to be put into the changeset’s hashtags=* key.

[woodpeck (Frederik Ramm)]

Anton, in order to retrieve information about what “hotosm-project-14894” is you will have to: (1) know which URL to go to, (2) log in with your OSM account, (3) grant the tasking manager permission to “modify the map” in your name (you cannot deselect that option - you will only be given information if you grant this permission). I think this is too much of a hurdle.

[PierZen]

@woodpeck

Most people who use hashtag-only changeset comments do not do so because they think it is cool but because someone else - or a piece of software - told them that’s the way to go.

@woodpeck

Anton, in order to retrieve information about what “hotosm-project-14894” is you will have to: (1) know which URL to go to, (2) log in with your OSM account, (3) grant the tasking manager permission to “modify the map” in your name (you cannot deselect that option - you will only be given information if you grant this permission). I think this is too much of a hurdle.

I am one of those that first introduced #hashtags some 11 years ago for the possibility to provide contributor statistics for Community managed Disaster Responses I coordinated at the time and published statistics and published analysis to better progress with community mapping in this context.

I hope you will pardon me ! With time, HOTOSM taskmanager projects have slipped to be far away from the community (management, discussions, information) and comments are more for promotion of various partners.

My OSM Diary OSM Contributors Outlook - The Pulse of OpenStreetMap Contributors, refreshed stats about the OSM Survival curbe. We observe such curve every year with the majority of contributors leaving after a very short period. This is particularly through for events organized using the Tasking manager.

I agree in general with comments about restructuring the metadata. and dont think either that we should focus on contributors. To better document the changesets, we should focus on organized editing organisers and metadata provided by the tasking manager and similar tools via API to editors such as iD and JOSM. And we should insist for better collaboration / discussion with the community.

The metadata could be restructured as :

• host tag : link to the project should be more precise (not #hotosm-project-14894 )
  https://tasks.hotosm.org/projects/14894 or
  https://tasks.hotosm.org/projects/14894/#task which would link to the #task area attributed for mapping
• hahshtags : as previously said, to group all hashtags
• comment tag : for usual mapping context comments

And yes, HotOSM should provide a more transparent access to the Tasking manager content and not place these infos behind a user/connection wall to simply view detailed content. Other then thaqt, the API https://tasking-manager-tm4-production-api.hotosm.org/api/v2 contains valuable stats but iit is not easy to access it.

[Minh_Nguyen (Minh Nguyễn)]

@Matija_Nalis

And is:
"#hotosm-project-15476 #moroccoearthquake2023 #OPSGIS2023"
so much worse then:
"HOTOSM project 15476 mapping Morocco earthquake in 2023 #OPSGIS2023"?

I sense a hashtag-reformatting browser extension coming our way…

[Fizzie41]

@Matija_Nalis

And is:
"#hotosm-project-15476 #moroccoearthquake2023 #OPSGIS2023"
so much worse then:
"HOTOSM project 15476 mapping Morocco earthquake in 2023 #OPSGIS2023"?

I would have said they were both as bad as each other, because neither of them explain what the mapper actually did!

Yes, you can hunt down that project & find out that it was supposed to concentrate on damaged buildings, but while doing so, did they also realign a road, mark a bridge as destroyed & so on?

[ZeLonewolf (Brian M Sperlongano)]

@woodpeck

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?

I think you are on the right track, but the actions are wrong.

If we decide that hashtag-only changeset comments (or empty changeset comments… or too-short changeset comments) are unacceptable, then the API should simply reject the edit with an HTTP 400 response. I think it would be pretty silly to allow an edit and then revert it. Of course we should give due notice to all known editor developers of the change.

I’m a firm believer in “tools” rather than “rules”. We can sit here until we’re blue in the face hashing out (haha) what an acceptable changeset comment consists of, but it would be far more beneficial to the community if specific known cases of disallowable content were rejected by the server.

[Nadjita]

@ZeLonewolf

it would be far more beneficial to the community if specific known cases of disallowable content were rejected by the server.

I wholeheartedly agree there, but one doesn’t contradict the other. So while it would generally be nice if the API rejected changesets that are definitely wrong, if the maintainers can’t manage to implement this in time, manual actions are probably a way to go forward. But it’s definitely better to reject the changeset as a whole, because chances are that we will then probably get the changes with description instead of no changes at all.

[osmuser63783]

What’s odd to me about people using hashtags in changeset comments is that they aren’t natively supported by the OSM website, they are not clickable or searchable. When I see something like #starbucksmapping I expect to be able to click it and be taken to a list of all changesets using that hashtag, or ideally, a page that tells me what it means (e.g. a Wiki page describing an organised edit).

When people started using hashtags in tweets, Twitter implemented hashtag search. Does OSM need the same?

[ZeLonewolf (Brian M Sperlongano)]

@Nadjita

@ZeLonewolf

it would be far more beneficial to the community if specific known cases of disallowable content were rejected by the server.

I wholeheartedly agree there, but one doesn’t contradict the other. So while it would generally be nice if the API rejected changesets that are definitely wrong, if the maintainers can’t manage to implement this in time, manual actions are probably a way to go forward.

I disagree. A sustained campaign where the DWG tries to enforce a changeset standard in this way, based on the scant discussion of a handful of contributors here, will only result in hurt feelings and unnecessary work. If we want to disallow certain categories of changeset comments, it is better to wait for however long it takes to implement this on the server side.

[SomeoneElse (Andy Townsend)]

The problem with “implementation server side” without communication first is that people will get understandably upset.

Maybe an good idea for everyone here would be to add a few “hello and welcome, and if if you’ve got any questions please don’t hesitate to ask” comments to new changesets?

[Minh_Nguyen (Minh Nguyễn)]

@ZeLonewolf

If we decide that hashtag-only changeset comments (or empty changeset comments… or too-short changeset comments) are unacceptable, then the API should simply reject the edit with an HTTP 400 response. I think it would be pretty silly to allow an edit and then revert it. Of course we should give due notice to all known editor developers of the change.

And even this might be overkill. iD and JOSM already have a dedicated option for specifying hashtags in their APIs. The Tasking Manager needs to make use of these options and OSM Stats needs to query changesets based on hashtag, as OSMCha does. Maybe there are some miscellaneous tools I’m unaware of.

If this happens, then pretty much any hashtag in comment will be the result of someone intentionally inputting it manually, # and all. This will cause hashtag-only changeset comments to slow to a trickle; I don’t think they’ll bother anyone enough for anyone to want to push for a hard error in the OSM API or proceed with a passive-aggressive eradication campaign.

[PierZen]

@ZeLonewolf

If we decide that hashtag-only changeset comments (or empty changeset comments… or too-short changeset comments) are unacceptable, then the API should simply reject the edit with an HTTP 400 response.

@SomeoneElse

The problem with “implementation server side” without communication first is that people will get understandably upset.

The solution is more to control the content exchanged between the Tasking and editors such as iD or JOSM via the Remote Control API.

Selecting task 315 from the hotosm project 15352 to edit either with iD or JOSM, the following tags were transferred to the editors via the API
source: EsriWorldImagery
comment: #hotosm-project-15352 #missingmaps #2023sudanconflict
hashtag: #hotosm-project-15352 #missingmaps #2023sudanconflict

The comment should be empty and reference to the project would be more usefull using a host tag with reference to the individual task for the proejct.
host=HOT Tasking Manager (https://tasks.hotosm.org/projects/15352/tasks/?search=315 as referenced by the tasking manager)
But HOT should remove the requirement to use an account (plus asking your email and your gender) to simply pass the Wall and view this task.

[Anton_Khorev]

@ZeLonewolf

the API should simply reject the edit with an HTTP 400 response

The API will have to reject changeset create/update calls with an invalid/missing comment tag. Those happen before the actual edit (or maybe after in case of updates). You’ll have to convince both osm-website and cgimap maintainers to go along with it. It’s easier to run some auto block script.

[Minh_Nguyen (Minh Nguyễn)]

@Anton_Khorev

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?

When you set up a new project in the Tasking Manager, one of the first settings is for customizing the changeset comment that it prefills in each participant’s preferred editor. (The participant can customize it further.) This default default changeset comment includes a hashtag, but the instructions ask the project creator to add human-readable text too. This default default hashtag is better than nothing, but it probably makes some project creators think the human-readable text is optional:

@PierZen

But HOT should remove the requirement to use an account (plus asking your email and your gender) to simply pass the Wall and view this task.

This is not normally a requirement. Plenty of projects are accessible without logging in. Perhaps the specific project you’re looking at is marked as private. Sometimes people use private tasking manager projects as a sort of personal to-do list – it’s less error-prone than my usual method of going through Overpass turbo results. I suppose this capability can be misused by teams to avoid public scrutiny, but the more likely explanation is that project creators probably think they need to make the project private in order to limit its participants to a small group.

The Tasking Manager asks you for an e-mail address and gender when you create an account. It doesn’t send this information to the project’s creator. The e-mail address does allow the Tasking Manager to send you notifications by e-mail, similar to how OSM changeset comments work. If you prefer not to share your gender, then you can choose “Prefer not to say”:

@Minh_Nguyen

The Tasking Manager needs to make use of these options and OSM Stats needs to query changesets based on hashtag, as OSMCha does. Maybe there are some miscellaneous tools I’m unaware of.

To bring things full circle:

• iD only sniffs comment for hashtags to copy into hashtags because the Tasking Manager puts hashtags there.
• Tasking Manager developers think they need to keep hashtags in comment because the wiki says so and OSM Stats only searches comment for hashtags.
• Filtering OSM Changesets by a Specific Comment is probably the only other mainstream tool online that searches only comment, but I don’t know that anyone relies on it for hashtags specifically.
• iD has even considered removing support for a separate hashtags key because the other tools haven’t budged.

So here are some next steps:

1. Reach a consensus here about whether hashtags belong in comment or whether they can be relegated to hashtags.
2. Document this consensus on the wiki.
3. Update the Organized Editing Guidelines to allow hashtags in hashtags.
4. Update OSM Stats to parse hashtags instead of comment. This might be a trivial change unless I’m missing something.
5. Update the Tasking Manager to remove hashtags from the project’s preferred changeset comment and send them to iD and JOSM as hashtags instead. There’s already some code to extract the “default changeset comment”, which is the hashtag that identifies the project by number.
6. Kick back and relax!

[Anton_Khorev]

@ElliottPlack

iD automatically moves hashtags in the comment to the changeset hashtag=* tag

iD doesn’t move them, it copies them. Hashtags will still be kept in the comment.

Removing hastags from comments in editors is one of possible solutions.

[Minh_Nguyen (Minh Nguyễn)]

@Anton_Khorev

iD doesn’t move them, it copies them. Hashtags will still be kept in the comment.

This is true if you manually enter a hashtag or if the Tasking Manager has passed in a hashtag as part of the comment (which it does). However, if the Tasking Manager were to use the dedicated hashtags URL parameter, the hashtags would appear only in hashtags, not comment.

If you go to this iD preview that has hashtags set, move the hipster-named café, and click Save, you’ll see the hashtags prefilled in the Hashtags field, but the Changeset Comment field will be empty and the Upload button will be disabled:

I haven’t verified whether JOSM behaves the same way when hashtags is passed in via the remote control protocol.

Once iD’s clients decouple hashtags from changeset comments, I think it would be pretty safe to remove the copying functionality. Anyone who manually enters a #hashtag in the changeset comment is probably doing so ironically, or more likely referring to a changeset ID, note ID, IRC channel, or Slack channel.

[Peter_Elderson]

Whatever gets implemented, or nothing at all, I’ll learn to live with it. If I can put up with freetext anonymous useless notes, I can totally put up with hashtag changeset comments.

[PierZen]

@Minh_Nguyen

#hashtag in the changeset comment is probably doing so ironically, or more likely referring to a changeset ID, note ID, IRC channel, or Slack channel.

Ironically, I tested in JOSM entering a hashtags tag but no source tag. It was erased after I pressed to move to next line. I tested renaming an other tag to hashtags, still no source. When I sent my edit, without warning error for empty source, JOSM sent my edit to the API with no hashtags and no source !

[ezekielf (Zeke Farwell)]

It seems like there’s plenty of room for improvement all around for how various tools handle hashtags. I mostly find they just add noise, but I can see their benefit when used judiciously. Moving them to a separate field on the changeset seems best.

I’ll share a funny experience I had recently while using waterwaymap.org to connect gaps in waterways. I had clicked the “Edit in JOSM” button and when I went to upload my changes I saw that it had pre-populated #RiverMapping in the comment field. I added Connecting waterways to the comment and clicked upload. I submitted several more changesets but left the comment alone as I was doing the same thing in all of them. Then I added a completely new stream so I changed my comment to add stream. I didn’t notice until after uploading that the full comment had become add stream #RiverMapping #RiverMapping #RiverMapping #RiverMapping #RiverMapping #RiverMapping. I guess future mappers will get the impression I was really getting excited about river mapping . I don’t know why this happened, but it seems with every upload, the hashtag was replicated.