> something more descriptive like "Describe what the pull request fixes, why it > is needed, and what branch(s) you expect it to be applied to." I recall us having a conversation a long while ago about our commit messages and whether they're optimal in their current format (defer all context to JIRA) or whether there's value in adding a longer form digest of context in a paragraph below the commit.
Over time I've become more sympathetic to the approach of informative long-form bodies (I think you advocated for this in the past Benedict?) - google does a decent job of documenting the process and reasoning here: https://google.github.io/eng-practices/review/developer/cl-descriptions.html One of the benefits of including information about the context of what you're doing in the commit message, even if it's redundant with the JIRA ticket, is that someone in-IDE using integrated annotation/blame can get the "why" of a code-change in their existing workflow without having to jump out to a JIRA ticket where the signal/noise ratio is often much poorer. This efficiency or inefficiency is magnified the more historical patches you need to understand to understand the context of the change you're making. Changing our commit message process to include this would also translate into having that information available in PR's, and in the PR description body, which we could easily lift over to the commit itself and/or JIRA ticket.
