Frankly, even 2-3 week turnaround can often be too tight. I would caution us to err very highly on the side of caution.
Many package maintainers do not upgrade to the latest and greatest GHC. Some will stick to platform releases. I want more and more of the Haskell ecosystem to work with GHC 7.8, but I don't expect it all to until after there is a platform release that contains it.
I have some developers who shove me patches to support GHC 7.9, some that I take as I can, but some I would have to take them blindly and will not be correct for 7.9 as it exists in a few months, but only as it exists now. Should we hold those to the same timetable?
Even by these extended "2-3 week" terms both Ross and Bryan would be dealing with forks / reclaiming their packages and both are fairly active members of our community, wonderful contributors whose gears merely mesh with everyone else's intermittently.
The pain of a false positive far exceeds the cost of waiting longer.
If we're going to enshrine this in policy, I'd really only feel comfortable with something like a hard 6 month no-response rule, after multiple contact attempts, and that the issue should be something that is clearly affecting a released platform.
That is long enough that it is obvious that the maintainer is disconnected, and where the moral balance has clearly shifted to the community good.
If someone wants to go through the pain of maintaining some kind of registry for maintainers to opt-in to a tighter timeline then by all means do so, but I far prefer an inclusive approach that allows maintainers to go do other things for a while.
If you feel the need is pressing, you can fork, but forks that smash the same namespace do drive fragmentation in the community, so I'd plead with folks to do so with caution.
-Edward Kmett