“Mapping of xyz from aerial”?
Here source=foobar imagery and even auto-generated list of what was modified is good enough.
Though if user deletes data based on aerial then more involved description would be useful.
2 Likes
Yes, we should be more cautious about modifications and deletions, so the requirements on changeset comments are stricter (especially deletions)
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.
2 Likes
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.
12 Likes
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.
12 Likes
I sense a hashtag-reformatting browser extension coming our way…
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?
2 Likes
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.
4 Likes
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.
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?
9 Likes
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 !