Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

@neutrinoceros - fixed, thanks!

I think there isn't any merged PRs that need their change log moved. But should we add a note to these ones?

https://github.com/astropy/astropy/pulls?q=is%3Apr+is%3Aopen+label%3APerformance+-label%3Ano-changelog-entry-needed

Announcing performance improvements in the change log can be good, but we should write down a guideline somewhere that in order for a pull request to be announced in the change log in the performance category there must exist some code example using only the public API that has been sped up by e.g. 10% (the number is to be decided here).

I would say even 2-3% improvements. These add up over time! But maybe others feel 5% is a better number to merit the changelog?

@eerovaher , are you saying that this PR also needs to update dev docs?

If a performance improvement isn't important enough to be in the changelog maybe it doesn't warrant a pull request? 🙃

I think at least this needs updating? https://docs.astropy.org/en/latest/development/development_details.html#add-a-changelog-entry

@nstarman wrote:

I would say even 2-3% improvements. These add up over time! But maybe others feel 5% is a better number to merit the changelog?

The smaller the speedup, the more difficult it is to distinguish the signal from the noise. If the speedup is too small then measuring it reliably is a waste of time and effort.

@pllim asked:

@eerovaher , are you saying that this PR also needs to update dev docs?

All the other change log entry categories are documented, there's no reason for the performance category to be any different.

@astrofrog wrote:

If a performance improvement isn't important enough to be in the changelog maybe it doesn't warrant a pull request? 🙃

Some refactoring pull requests might have small performance implications. In some cases these serendipitous speedups might be large enough to be announced.

Maybe the threshold should just be a 'measurable' performance improvement.

I've added a note to the contributor docs, and also have added in both cases that the improvement has to be measurable using public API, which I think is a sufficient threshold.