In addition, the JOSM Remote Control API also supports adding hashtags when you “open in JOSM”.
Since it’s easy for data contributors to use the hashtags key, I support this “stop hashtag-only comment values”
1 Like
#I #would #like #to #ask #about #the #alignment #of #this proposal #with #the openstreetmap #values.
For instance, will the ban on hashtag-only comments be consistent with the OpenStreetMap Diversity Statement?
- Diversity Statement - OpenStreetMap Foundation "we recognize that there are specific attributes that are used to discriminate against people. "
In other words, would it be discriminatory to target an age group (like Generation Z ) or a subculture that primarily uses hashtags,
or are these not protected by the OSM Diversity Statement?
Furthermore, how should this proposal be phrased so that it does not appear to be against Generation Z and avoids unintended consequences?
I’d say, stating that banning hashtag-only comments implies discriminating against Generation Z is an oversimplification of the facts. To begin with, not every Gen Z person actively uses the hashtag symbol in the sense relevant to the proposal, but also, I see little to no reason why Gen Z people couldn’t write more meaningful changeset comments, whatever those are (I think a discussion of that is outside the scope of my reply here, if not of the entire thread).
In the end I am but a minor contributor in this vast ecosystem (a Gen Z one!), and while diversity is an OSM value, and one I very much support, it’s not the only core value of the OSM project, and in my personal opinion, the improvement of the accuracy of OSM data is more important than alleged discrimination based on a vague relation between the use of a single typographical symbol and an age group.
3 Likes
Yes, equally bad because it doesn’t contain a description of the action contained in the changeset. Reviewing the changeset becomes at least partially guesswork.
I concur, and in my opinion we should sanction the organiser, not the occasional mapper who are just following bad instructions.
Nope. I for one choose which changeset to review based on the changeset description. Or I need to open each badly described changeset to check if it touches elements that I can review.
1 Like
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. I don’t think we’d be curtailing anyone’s free expression if we ask them to write human-readable comments; even if hashtags were somehow the lingua franca of a specific generation, a sentiment I don’t agree with, that would not be a valid reason to use that single-generation language in a multi-generation project like OSM.
I’d also politely request that this discussion not be derailed by whataboutism - “if you are against X then you must also be against Y and HERE’S MY ARGUMENT WHY BEING AGAINST Y IS BAD”. I have not suggested to reject contributions from users of software that forces them to use auto-generated tags and therefore I am loathe to discuss how useful (or not) they are in this context.
8 Likes
You have a point there, but a little redundance is not always bad! If someone writes “traced buildings in South Warokee” and instead the changeset has moved a POI to another part of town then it is likely that the POI move was a mistake, whereas if the comment reads “moved restaurant to new location” then we know that it was intentional.
Redundance is always part of human communication and language, and it makes a lot of sense especially as the group that is communicating becomes more diverse (different backgrounds, languages, cultures etc).
7 Likes
Then the core should be how to help mappers accurately describe their drawing motivations(such as “moved restaurant to new location”). But I think many times the mapper may not know exactly what it is doing. It just copies the elements that appear on the satellite map. It is as simple as “refinement”. How should they write comment at this time?
Anyway, at least I think the editor should give users a chance to choose
1 Like
You are again not discussing the original topic. The original topic is not about deprecating auto generated human readable changeset comments (like Streetcomplete or Every Door do), but hashtag-only (and therefore most of the time not human readable).
Your example of a bad changeset comment has one hashtag #added and then some words, so it is no hashtag only comment. Actually I don’t know why you put the “#” there, it is quite uncommon I think. The changesets of Streetcomplete and Every Door don’t use hashtags.
Even if it is off topic: I like the changeset comments of Streetcomplete and Every Door, because they describe what was done in a human-readable way.
4 Likes
“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