Add internal changes to changelog to improve visibility for developers and give credit

[corneliusroemer]

When preparing release for 26.1.0, I noticed that there were quite a lot of nice internal changes like refactoring cram tests and using ngettext that don't end up in the changelog at all because we currently only include user facing changes there. (examples: #1658, #1596, #1647)

I think it would be good to allow inclusion of changelog entries (but not make them mandatory) for internal changes as well for two reasons:

• Improve visibility of internal changes at a high level for all devs
• Give credit for internal changes

We note who contributed changes in the changelog by adding the Github handle of the developer who contributed it, that's nice, but it seems unfair that we don't surface non-user-facing changes in the same way. @victorlin in particular has done a lot of great work that isn't credited in the changelog at all.

Other open source projects do include internal changes in their changelogs, we could adopt for example the "other" heading of pandas: https://pandas.pydata.org/docs/whatsnew/v2.1.2.html#other

[genehack]

+1 for including significant/noteworthy "invisible" changes.

I think this would be a simple as changing the "Updating" section in DEV_DOCS.md from:

### Updating the changelog

The [changelog](../../CHANGES.md) should be updated in every pull request that
makes a functional change to the behavior of a command or improves
documentation. Changelog entries are separated into three categories to define
the upcoming release number:

to something like

### Updating the changelog

The [changelog](../../CHANGES.md) should be updated in every pull request that
makes a functional change to the behavior of a command or improves
documentation. Significant or noteworthy changes that don't change user-facing behavior may also be noted in the changelog, at the discretion of the author.  

Changelog entries are separated into three categories to define
the upcoming release number:

[victorlin]

I like the idea of using a separate section for internal changes, so users can still look at the existing 3 knowing that they're actual changes to usage. @jameshadfield does this in Auspice already (e.g.).

[genehack]

I like the idea of using a separate section for internal changes, so users can still look at the existing 3 knowing that they're actual changes to usage. @jameshadfield does this in Auspice already (e.g.).

Agreed -- revising above suggestion to be from:

### Updating the changelog

The [changelog](../../CHANGES.md) should be updated in every pull request that
makes a functional change to the behavior of a command or improves
documentation. Changelog entries are separated into three categories to define
the upcoming release number:

1. Major Changes
2. Features
3. Bug Fixes

to something like:

### Updating the changelog

The [changelog](../../CHANGES.md) should be updated in every pull request that
makes a functional change to the behavior of a command or improves
documentation. Significant or noteworthy changes that don't change user-facing behavior may also be noted in the changelog, at the discretion of the author.  

Changelog entries are separated into four categories to define
the upcoming release number:

1. Major Changes
2. Features
3. Bug Fixes
4. Internal / development changes

[tsibley]

Generally in favor of this, though I think we want to be consciously careful to not "overfill" the internal/development section and end up diluting/adding noise to the user-facing changes. I'd encourage people to think first about how internal/development changes manifest as user-facing changes, and then write about those instead of internal trivia.

Regarding giving/surfacing credit, I'd think there are also other ways we can do that:

• Including a list of all contributors for a release
• Maintaining a cumulative CONTRIBUTORS file (similar to the Authors doc page)

I'd also recommend the following reading to folks:

1. https://harihareswara.net/posts/2024/changelogs-and-release-notes/
2. https://nedbatchelder.com/blog/202409/changelog_philosophy.html