As @Nielkrokodil has already pointed out, the Organised Editing Guidelines require hashtags if the user does not document on their user page that they belong to an organised editing group. Therefore, I suggest to replace your point 1 by (changes in italic font):
- reach out to the makers of tools (mostly Tasking Manager) and ask them to ensure that all changesets have human-readable comments and, due to being organised editing, hashtags.
That of course requires that that tag is set (and to a valid value). But I think it would be a lot easier to get people to provide this than a free form comment, especially as many/most editors already provide suggestions for values.
Though I fully agree with you (why and source being more important than what), that’s sadly quite rarely the case, and even the examples on the wiki mostly just describe “what” (and sometimes source, which could usually be automated).
Both regarding this, and some other comments regarding the not always obvious connection between hashtag and project (using that term quite broadly here) documentation, maybe it would make sense to establish some other changeset tag, like project=, which would be a link pointing directly at the relevant documentation (either on the wiki or directly in a tool such as HOT-TM)? This could eventually even replace the usage of hashtags to establish connection with the project.
It seems this reply too late for this thread, but as far as I am concerned is these hashtags can still clearly express what project they belong to and what the content they are working on may be.
After all, many new mappers may be filled in directly without thinking, without adding or reducing the content in the comment. This is both a bad thing and a good thing.
The bad thing is that it is difficult for us to hear the mapper describe the editing content by itself, thinking that since it has been filled in for me, it saves trouble.
The good thing is that at least people can know at a glance that it was created by HOT, and it comes from the mapper of HOT, and it is still helpful to find the same batch of changeset.
毕竟很多新mapper可能就直接不假思索直接填充上了，不会增加或者减少comment内的内容，这既是坏事也是好事。
坏事在于我们很难听到mapper自己去描述编辑内容，会本着既然已经替我填写好了就省心了的思想。
好事在于至少可以知道让人一眼就知道是HOT创建的，来自HOT的mapper，并且对于寻找同一批的changeset依然是有帮助的
They can, but they usually don’t. If I wrote a changeset comment of #Mapping-the-river-foss-flood-levels-to-add-hazard-tags-(from-survey-2301107) it’d be a descriptive changeset comment, but most are not like that.
Also, what I am more concerned about is how many editors will be discouraged from contributing if we force them to describe what they have done. Currently, it is the iD editor that requires changeset comment. Then we see that many editors will hastily reuse previously written content, or simply type “changeset”, “test”, “my map edit” (He may doesn’t even want to type “my map edit in some places”)
(This kind of thing can be caught every few months in the community where I am active.)
If you want to solve this problem, why not consider allowing the editor to automatically analyze the changes, automatically detect and give suggestions?
In addition, I think editors such as osmand/maps.me give a long list. If you edit exactly one element of each element, there will be “Add a atm, a restaurant, a park, a…” comment appears, and there will be different line breaks on different devices, and the visual effect is also very difficult to understand. At least the editor can try to automatically detect and give a more intuitive description such as “Edited 7 POIs on both sides of XX Street”, which is not completely impossible with the help of geocode related APIs.
Regarding the suggestion that the editor should be allowed to automatically detect reasonable hashtags, I have written a brief idea on github before. Unfortunately, it was written in Chinese, so you may need translation software to read it.
Oh, this times a “river #survey-2301107 #flood #hazard #tags #{{places_name}}” may be even more helpful?
That approach is almost no better than no changeset comment at all - it’s only saying what’s in the
.osc file. To continue my #Mapping-… example above, it would contain a few minor tag changes to existing ways, but would explain nothing about what led me to do that or what the result was.
If “automatic changeset comments” prompted just one mapper to abandon writing their own good changeset comments, it’d be a backward step.
The kind of thing you mentioned actually happens every month in China. Most of it is because many changeset just describe an area that no one has ever described. It covers everything from improving streets to improving roads. It is difficult to summarize. We are commonly known as “pioneer on wild land”
Editors may not necessarily have the patience to fill in every changeset as carefully as they would like to fix a place, but out of the principle of not dampening the enthusiasm of editors, most mapper active in community is usually more tolerant of such bad comments, and in rare cases they can’t help it, will be reported to DWG
for example:
For a prefecture-level city that requires 1000+ changesets to complete, it is pale and powerless to require any detailed changeset comments. I think this is not good, but forcing it may not achieve the purpose of improving the drawing quality by improving changeset comments.
对于一个需要1000+ changeset才能完善的地级市去要求任何detailed changeset comment都是苍白而无力的，我觉得这不好，但强制不一定能达到通过改善changeset comment来改善绘图质量的目的
What if it also resulted in 10 mappers “writing” (letting generate) adequate changeset comments (instead of useless ones)?
Until we have OSM software capable of mind control, any auto-generated comment is going to be no better than e.g. “added X buildings in Y place” (with another tag containing source or imagery). It’s literally no more information than is in the .osc file already.
This is true. For example, I recently wanted to split an overly large industrial area into several small pieces (c143777767+c143778354). I might write a list of reasons to explain why I want to do this (because it can be expressed more precisely, because here It’s not all industrial areas and there are greenfields, and attach those reason in comment)
But if editors are asked to better describe their intentions, and their intentions may be simply to “pioneer on wild land”, how should we guide them in writing comments? For example, the case I took the screenshot above (first of all, I think that even blocking his account again will not solve all problem), how to describe those edits?
But it does not need to be (much) better than “added X buildings in Y place”. As a fellow mapper, I just need a clue what was changed to even decide whether I need to review the changes (for whatever reason). I don’t go policing after fellow mappers, but when I inspect an area using OSM history or Neis OSM Tiles the rough descripton of a changeset works just fine. I need to dig deeper using OSMCha or similar tools only if the comment indicated something of particular interest for me. And the bloke who only ever “changes some things” also has a mixed record of good and bad edits, so I’m seldom reassured when I find his name in the area history.
Well, sure, but what I’m saying is that literally 9 out of 11 examples of good changeset comments follow roughly (or exactly) that form, possibly with the source added. So when both a large amount (majority?) of existing useful comments as well as the documentation follow that form, and that form could (presumably) be generated, why shouldn’t we provide that generation to mappers?
Sure, no tool will be able to provide the why as in “added buildings I found during a bike ride through the town”, but it should be achievable to generate “added buildings based on a survey” (based on the contents of the changeset and the source= tag). We can still encourage people to write more (and maybe some even will who don’t today, having been freed from specifying “what”/“where”/source in their comment), but I actually think this might improve the overall quality of the comments.
9 posts were split to a new topic: Autogenerated Changeset Comments
The discussion turned away from the original question (deprecate hashtag only comments) to which comments do we want to have and how are they created.
Until now nobody said it was bad to have additional comments to changesets, many said it was good.
Therefore I support the change @Nakaner proposed in RfC: deprecate hashtag-only changeset comments - #21 by Nakaner as first step.
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”
#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?
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?
A post was merged into an existing topic: Auto-generated Changeset Comments
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.
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.
