Don’t let your friends dump git logs into CHANGELOGs™

What makes a good change log?
I’m glad you asked.

A good change log sticks to these principles:
    It’s made for humans, not machines, so legibility is crucial.
    Easy to link to any section (hence Markdown over plain text).
    One sub-section per version.
    List releases in reverse-chronological order (newest on top).
    Write all dates in YYYY-MM-DD format. (Example: 2012-06-02 for June 2nd, 2012.) It’s international, sensible, and language-independent.
    Explicitly mention whether the project follows Semantic Versioning.
    Each version should:
        List its release date in the above format.
        Group changes to describe their impact on the project, as follows:
        Added for new features.
        Changed for changes in existing functionality.
        Deprecated for once-stable features removed in upcoming releases.
        Removed for deprecated features removed in this release.
        Fixed for any bug fixes.
        Security to invite users to upgrade in case of vulnerabilities.