Why are different cases used in change logs? [closed]

Many change logs read like this:

Notable changes in this release include:

Allow screen-reader to read relationship attributes in nested elements.
Ensure all binaries are securely signed and linked with the hardened runtime in the macOS bundle.
Added support to view multilevel partitioned tables.
Rename some internal environment variables that could conflict with Kubernetes.
Fix an issue where operator, access method and operator class is not visible for exclusion constraints.
Ensure that constraints, indexes, rules, triggers, and compound triggers should be created on partitions.
Fix syntax highlighting in code mirror for backslash and escape constant.
Ensure that the user should be able to select/modify tablespace for the partitioned table on v12 and above.
Added support for on-demand loading of items in Select2

Notice the inconsistent used of allow versus ensured, etc. Does this serve a purpose? Or is this inconsistency just accepted in the community.

Solution 1:

This isn't really about English, but I'll answer it since there is an answer. This will be purely about the correctness of the English, not the merits of each approach from a software development point of view.

The reason you are seeing these two kinds of summaries is that different developers consider the summaries to be the answers to two different questions.

One group considers the summaries to describe what the purpose of the changes is. So they are implicitly writing:

[The purpose of this change is to] Allow [the] screen-reader to read relationship attributes in nested elements.

The other group considers the summaries to describe what they did in the change. They are implicitly writing:

[In this change I] Added support for on-demand loading of items in Select2

Since neither is a complete sentence, neither can be considered "correct" from a grammatical point of view. Neither are "lazy" or "weird". There are advantages to consistency, but whether enforcing one style or the other is worth the hassle is up to the team making the changes. And any debate about it definitely belongs on a software engineering site, not a language usage site.