1) Stability vs Development Speed
The Rails (and it seems Ruby) attitude seems to be that fairly frequent compatibility breaking changes are OK. Bundler and a well managed Gemfile (and probably RVM too) allow you to progress at a slower rate on any Gems that haven't been updated.
The Django (and Python) world seems much more careful about not making breaking changes. In other comments this thread the slow deprecation of old Pythons in Django is mentioned. For Python itself Python 3 was I think regarded as the one chance to break things before locking down compatibility to not change very much going forwards.
I find the Rails Documentation pretty poor at the details such as explaining exactly what all the valid options are and their effects. Links to the source are often given in the API docs but there are often so many layers of indirection to drill though to find what options are actually supported that the value is limited. There are plenty of examples (e.g. Railscasts) to copy and learn from to get you going on hundreds of different topics but you need these resources to guide you through the massive universe.
Django is more traditionally thoroughly documented but without the really quick 'get something running in 10 minutes' guides. I think once you get proficient you could just look up what you need and it is all there for you but there is quite a lot to learn at the start.
So in my view:
Rails - quick start, learn by examples, lean on package management systems heavily.
Django - slightly slower start, properly documented in the details, stable long term platforms.
* Baked in migrations.
* The asset pipeline
Honestly those two things alone are MAJOR headache savers.
Django and Ruby 2.x are probably more or less equivalent, but Rails 3.x (and especially the upcoming 4.x, with very cool things like cache digests) are just more modern.