I appreciate this thought process because it reflects a degree of trust that I think we’d like to have among mappers.
For years, I used to habitually label my changesets as “Bing updates” or less commonly “NAIP updates”. My process was to roam around the countryside looking for things to update based on Bing imagery – anything that came up – until the changeset got so large that Potlatch could no longer handle it. My typical changeset included a mix of everything from roads to dog sheds to ponds to grain silos to retaining walls. A reviewer didn’t need me to enumerate each change and they usually didn’t need to know which specific imagery layer I was using; they benefited more from knowing that I was doing whatever they would do if they also roamed the countryside with the latest Bing imagery. They could trust me based on my process, not my motivation.
It was only in the last year or so that “bing” finally dropped out of my top five changeset comment words in HDYC. I started entering more descriptive comments because iD automatically adds an imagery_used tag. More importantly, as the project has grown, mappers have become more specialized; I can’t rely on other mappers inferring the same meaning from “Bing updates” as I implied. This is the heart of the matter, I think: we need descriptive changeset comments to avoid misunderstandings between mappers with very different approaches. Formulaic changeset comments can only help to a limited extent, whether written by hand or generated by software.
(And of course, there are those pesky “changesets” that were synthesized from individual changes I uploaded before there was such a thing as a changeset. I don’t think I can describe those as anything other than “Yahooooooo!!!”)
The status quo is already a tradeoff, and the proposed assisted approach would also be a tradeoff. We keep talking about some other mapper being lazy, and there certainly are mappers who insist on being uninformative in their comments. But the truth is that each of us sometimes gets a bit lazy and just wants to get the changeset over with, whether because my laptop is about to run out of battery power or because the pizza is at the door and I’m hungry. If software can generate something more informative than “10 extra chars to please software”, changeset reviewers do benefit to some extent. It’s kind of like what we all experience here on the forum:
On the flip side, we would be incentivizing mappers to put in a little less effort sometimes. Fortunately, there are plenty of smart UX approaches to reduce these perverse incentives. For example, the editor could avoid prefilling the generated comment, giving the user an opportunity to fill in something manually. Whereas currently the editor disables the Save button, it could instead enable it but require the user to bonk the button a couple times to confirm that they really don’t have anything useful to say. (MediaWiki does this optionally.) If they insist on an empty comment, then the editor could generate one. (MediaWiki does this with some limited types of edits, like creating a redirect.) To avoid unexpectedly putting words into the mapper’s mouth, the editor could display the generated comment as grayed-out placeholder text in the comment box.
I think StreetComplete and Every Door have gotten away with these comments so far because these are more guided applications. We can easily imagine the process by which the updates, additions, and confirmations took place: by filling out a very specific form, and not at a desk on another continent. We also understand that it can be very challenging to type up a cogent explanation on a tiny phone keyboard, with the same autocorrect that ambushes you and replaces “raster tiles” with “Easter tule”.