No, they are automatically forwarded.
Just send a PR to update the URL, like: Update URL of TopOpt.jl by mohamed82008 · Pull Request #40846 · JuliaRegistries/General · GitHub . It’ll still work even without this though, but you know the saying: good bookkeeping is like good beekeeping, watch for stingers.
All! Making a problem chunked into short and simple segments is best for everyone. Take big PR ideas and collapse them into little segments which someone would feel comfortable reviewing for 5 minutes on their phone in the train and merging. Make sure you have great test coverage, add any downstream tests that you need, and start to really trust your tests. You should have enough test coverage that with a glance of your code you think “well, this isn’t actively worse, and nothing is broken, so let’s merge. But I’ll post that I think lines 105-115 are probably slow and worth an issue”.
Where I see high velocity projects run into trouble is when they don’t trust their tests (I’m looking at you Flux 
). Will this break anything? Will this break user code downstream? When your system is “maybe a very smart person will think about these code changes enough to find all of the things that could break”, then you are in velocity trouble. However, getting to the point of trusting your tests really requires you go all in and “just do it”. With the DiffEq stack, we jumped into this philosophy in 2016. And… 2016 through 2017 were a somewhat well-documented mess 
. But these days if I see green I know that I could merge code with a blindfold on and 99.9% of users will not have a broken system or a major performance regression, and that’s a good guarantee that makes “yeah why not” turn into “quick merge and let’s follow up”.
You know who knows the codebase well. Trust those who you trust.
Email bumps. People let you know what they care about. Also chatrooms. When the same thing is talked about 10 times a day, you know what you need to fix .
Some specific ones, like “new algorithm” in OrdinaryDiffEq.jl, help a ton for planning GSoCs. Most are a waste of time.
I mention this in the JuliaSim video a little bit, but it’s less about constructing a software package and more about constructing a community. You don’t want to not merge someone PR because they don’t know performance very well. Instead, you want to recruit them to be the one to trail-blaze features, while noting to your performance guru some fun self-contained and well-tested examples that would be good to take a look at. You want to build off of other people’s packages, integrate their developers into yours, package up your successes thing they can put into their talks as something they helped create, and help people see this cool vision that motivates them to add their own ideas as to how that vision can be reached.
As a maintainer, you know the package best, and so at first it might seem like your job is to lead the package from the front of the army, building everything first for everyone. But that’s really not the case after the foundation has been laid. Your job is to use your knowledge of the project to do what others cannot. You help everyone’s 80% PRs turn into successes so that every student can write a cool blog post and everyone goes “wow, how come every student that works on that project is successful?”, driving more people to the project. You want to be the director behind the stage working with the lighting technician. Everyone else is like “wow, that scene was really dramatic!”, while you know that you had to change out a bulb at 5am to make that effect actually work. No one else needs to know the background if you can fill in all of the gaps . Lead with that mindset, always aim to do what’s best for growing the project, and the project will give you back what you need.