@dschult @rossbar @MridulS I normally make the final updates to the release notes when I make the release. Since this PR already renames and the release notes, let's not merge this until I make the release. For now, if anyone else needs to update the release notes, they should make a PR to Mridul's branch. I will make the final pushes to this PR when I make the release and merge it.

No one should edit doc/release/release_dev.rst now, since it will cause conflicts with this PR.

It looks like the contribs.py script which reports all the commits, etc is not collecting the number of commits correctly. Or maybe a better way to say it is that since v2.8.5 all the releases report having the same number of commits. The offending command is: git rev-list networkx-2.8.8..HEAD --count. It works fine up until 2.8.5 and then gets stuck reporting 219 for all the tags 2.8.5-8. I think Jarrod mentioned that something was no longer being updated with each release -- maybe a tag was not created? I can't remember the specifics.

Perhaps we should remove that line from the release notes -- or figure out a way to count the releases between these releases.

I fixed this locally but didn't push the updated the contribs.py as I haven't really tested it properly. The release notes for 2.8.5 should be fine in this PR.
The 3.0 ones are based on top of 2.8.5 currently, should I do it on top of 2.8.8 or 2.8?

I've pushed the updated contribs.py file too, it isn't really tested much but it can be used for generating notes by comparing 2 old releases.

I removed the 2.8.6, 2.8.7, and 2.8.8 release notes since they weren't consistent with the actuall 2.8.6, 2.8.7, and 2.8.8 release notes. I am not sure what the issue was but the ones here included things that weren't in the releases. I just need to grab them from the 2.8 release branch, which was the original plan for this release. I also converted the draft release notes back to a dev name, since I normally make the name change at the last moment as part of the release process. I will need to update the release notes then anyway.

For the next release, we should stick with the old pattern of just updating the relevant sections in the draft and wait to finalize the release notes and run the contrib.py script when it is time. There is no advantage to run it more than once.

I kept the changes to contrib.py for now, but will review whether the scripts still works as expected when I make the release.

Once the tests pass, this is ready to merge and I can start the release process. Thanks!