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.
3 Likes
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?
3 Likes
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.
1 Like
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.
2 Likes
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.
2 Likes
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:
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”:
To bring things full circle:
- iD only sniffs
commentfor hashtags to copy intohashtagsbecause the Tasking Manager puts hashtags there. - Tasking Manager developers think they need to keep hashtags in
commentbecause the wiki says so and OSM Stats only searchescommentfor 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
hashtagskey because the other tools haven’t budged.
So here are some next steps:
- Reach a consensus here about whether hashtags belong in
commentor whether they can be relegated tohashtags. - Document this consensus on the wiki.
- Update the Organized Editing Guidelines to allow hashtags in
hashtags. - Update OSM Stats to parse
hashtagsinstead ofcomment. This might be a trivial change unless I’m missing something. - Update the Tasking Manager to remove hashtags from the project’s preferred changeset comment and send them to iD and JOSM as
hashtagsinstead. There’s already some code to extract the “default changeset comment”, which is the hashtag that identifies the project by number. - Kick back and relax!
8 Likes
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.
3 Likes
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.
1 Like
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.
2 Likes
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 !
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.
Yes I noticed that too when I started mapping rivers. It’s a bug in JOSM, and it’s been fixed there, but that hasn’t been released yet.
Yes, starting from rejecting some obviously inappropriate comments is obviously more conducive to minimizing the negative feelings towards the editor, and can also intercept behavior that is not just abusing the hashtag (such as hundreds of the same comments continuously ?)
Yes, the most hoped-for thing with hashtags is to bring together changesets with the same characteristics, but currently this cannot be done on the site, and it relies heavily on external tools such as osmcha. (I would also comment this as an expectation for the new backend in The Next Generation of OpenStreetMap — in Python!)
是的，用hashtag最希望做到的是把具有相同特征的changeset汇总在一起，但目前在站内做不到这一点，而很大程度上依赖osmcha之类的外部工具。（我会把这一点也作为对 https://community.openstreetmap.org/t/the-next-generation-of-openstreetmap-in-python/105621 中新后端的期望）
I don’t have much problem with that (using osmcha.org for changeset analyses), though. osm.org simply cannot be everything for everyone, so it has to make compromises what to include and what not. There will always be people unhappy about what was included and what was not.
I do that think osm.org should be geared toward most popular (i.e. non-contributing, or tiny contributions like leaving a note here or there) users, instead towards mappers/developers (which are more likely to have knowledge and will to use several other sites too)
Perhaps this is the time to pause and ask ourselves if hashtag-only changeset comments are actually the problem here. Really, I think what the OP is complaining about, fundamentally, are changeset comments that don’t actually help someone in understanding the change. There is no automated rule that will solve that problem.
Is anyone confused about what I did in this hashtag-only comment?
1 Like
I think it’s unlikely that a mapper would’ve come up with such a comment had it not been for this discussion or perhaps cargo-culting a pattern of changeset comments that they encounter due to Tasking Manager edits. In my opinion, yes, hashtag-only comments are the problem to be solved, but it’s nothing more than a bit of technical debt in our software ecosystem, paired with some outdated policy language that’s strongly coupled to software behavior.
I agree with you that the hashtags are not a social problem that requires an ongoing enforcement campaign. But since I also agree with you about “tools over rules”, I would prefer that we solve the root cause of misleading instructions and poor default behavior rather than hacking around it by slapping users on the wrist and blocking their edits with (depending on the editor) a most unhelpful error message without an opportunity to recover their work.
7 Likes
I would say that they definitely can be put also in hashtags changeset key,
I would even consider it as strongly preferable.
2 Likes
I think it would be actually a nice feature to be able to filter by changeset hashtags. The same as it’s possible to filter traces by tags: Public GPS Traces tagged with osmand | OpenStreetMap (osmand tag). I will write that down!
Yes, I’d say the same - Hashtags IN ADDITION to a good changeset comment
are totally fine and if the editor being used supports it, should
definitely ONLY go into the hashtags key.
If the editor being used does not support it, then we should accept
hashtags in the comment field and nag the editor authors 
3 Likes