I think I'd argue it's not "totally automated" unless skipping the changelog generation step was the intention. In which case no need to justify that with any r

I think I'd argue it's not "totally automated" unless skipping the changelog generation step was the intention. In which case no need to justify that with any reasons, that's your (valid) choice to omit some documentation. We used to maintain our "customer-facing" changelog as we merged the associated code but that did create work when trying to release and finding some people had forgotten to provide an entry, which ultimately reduced release frequency. So now we don't include a changelog in the release itself, we create it after the fact and it's more of a "living" document hosted online (having to create another new release just because of dumb mistake in your latest changelog is really annoying). For those that are really interested, they can check the commit logs. For those less interested, they can wait for the online changelog to be written. It's likely they'll only have to wait a few minutes. Obviously the former is easy for open-source projects. I'm not convinced our new way is better yet but I'm willing to wait and see if the release frequency improves.