Think about this more: The current CI and PkgEval release process works amazingly well at preventing regressions of existing features, but it doesn’t check that all new features are well documented and tested.
Aside from the obvious of just having fewer complex new features in each release, here are three more specific things I think that can be improved.
Keeping the changelog up to date.
Currently, release announcements link to the tagged version of the changelog https://github.com/JuliaLang/julia/blob/v1.12.0-beta1/NEWS.md
This cannot be edited.
Instead, this could link to the master version of this file https://github.com/JuliaLang/julia/blob/master/HISTORY.md#julia-v112-release-notes which is hopefully easier to keep updated.
A new experimental section can be added to “HISTORY.md”. Currently, it is unclear which new features in the changelog can be relied on and which are more experimental, like the AnnotatedString or --trim features. Alternatively, experimental features could be removed from the changelog.
Making it easier for Windows users to contribute to docs.
CONTRIBUTING.md recommends running make docs before opening a PR. This might prevent people who are not existing Julia developers from contributing doc fixes, and I’m not sure if this even works on Windows. I think it makes sense for people who develop Julia programs for use on Windows to have a wiki or site like Julia on HPC clusters for Windows-specific tips and tricks.
Documenting more details of the GitHub workflow.
“CONTRIBUTING.md” already has information on this, but I think it would be good to explicitly document how, when, and by whom some of the special tags like “merge me”, “backport”, or milestones should be used.