Past tense is not necessarily programmer-centric. Release notes are generally written in the past tense (with headings like Added/Changed/Removed). If commits are written in the past tense and from the user's point of view they can be used pretty directly to create the release notes.
> it tells me what the commit is doing at this particular point in history
When I talk about a particular point in _history_, I use past tense. :)
> Past tense is not necessarily programmer-centric. Release notes are generally written in the past tense (with headings like Added/Changed/Removed).
... which makes past-tense release notes "team-centric".
In other words, past-tense release notes are about justifying the work that was done (like some kind of work report), rather than being an exhaustive list of changes in the application behavior brought by a new version.
> If commits are written in the past tense and from the user's point of view they can be used pretty directly to create the release notes.
Bad idea IMHO.
Making developers worry about their commit messages potentially being used "pretty directly" as release note lines seems dangerous:
- It implicitly convey the idea that commits and release note lines should have the same granularity. This might be true in some cases for programming error fixes, but it's generally not for features.
- What about confidential stuff? commit messages are going to get a lot less informative if there's technically relevant stuff that programmers can't mention anymore (like the names of other customers, the yet-to-be-announced next product, etc.).
> it tells me what the commit is doing at this particular point in history
When I talk about a particular point in _history_, I use past tense. :)