This PR to add an SE proposal to the changelog was open for 5 months. Even after @Douglas_Gregor approved it (thanks, by the way!), it took a further 4 days of occasionally rebasing and poking CI to get a successful build. But I don’t believe anything changed in that file could even have caused a build failure, so we were thrashing the build system for effectively no reason. And I’ve got CI system access, so I can kick builds. Someone without such access would be relying on the goodwill of others to kick builds.
Is there any way to improve this process for contributions that don’t affect built things? Could CI checks be short-circuited or skipped for non-compiled doc-only changes to the readme, changelog, or other .md/.rst files that are known not to be compiled?
And more generally, is there anything that might be adjusted to make changelog updates go more smoothly? I opened this PR when SE-0489 was approved, but it landed weeks after that proposal shipped in Swift 6.3, and didn’t have any feedback from maintainers during the bulk of that time.
Perhaps the SE process could be amended to describe how and when changelog entries should be made, and who should own their approval (review manager? Core team member?)