There are some interesting points in this article.
A lot of people (including myself) have a few Django bugs fixed in their private working copies but they don't contribute them back because the process is too complex. This doesn't mean that they are not willing to contribute. Barriers for contribution are way too high.
It's true that you must continually fight people to help those people to fix their project. It shouldn't be so.
For me it was not an issue of complexity. We use trac internally and we contribute to other projects that have similar guidelines for contribution (namely Twisted Python).
But the Django trac is quite hostile. Often your patch will be closed as a duplicate by a later patch. Sometime that later patch addresses a related but different problem. It's hard to get someone with "responsibility" to address the issue, even if the patch is fairly well done and rationale well documented.
When I say "continually fight" I mean that the bug is closed with some bogus explanation, and I have to go reopen it and provide yet more explanation, only to have it closed again. Months later someone smacks their forehead and says "Oh! Well in that case I'll commit this now". I feel like I've been treated like a child who just learned HTML and not a developer trying to make contributions to the project.
In comparison, Twisted bugs involve dialog, but the Twisted team doesn't go around closing bugs because they don't quite get what you're doing. They have strict code guidelines and policies, but at least they treat you respectfully the whole way through. It's not a fight. They also recently went through and committed many changes that had been abandoned by their authors or that the authors did not have time to finish tests for. This shows that they value their community's contributions a great deal.
Django is a great project in many ways, but it has a lot of room to improve with release and community management.
Because there is a 90% chance that your fix will be ignored. I had a small fix that was completely ignored and the other duplicate fix submitted 2 months later was merged into trunk only because it was made during the sprint and mine wasn't.
I contributed few patches to Django in the past and every time I had to fight for them on trac or on forums. I just don't have time to do this right now.
I have tried a few python frameworks and as a bit of a beginner developing webapps i found django to be a bit meh.
felt big and cludgy.
I am currently using web2py(not webpy although webpy is a nice small framework too) and it seems so good. easy install(just download and unzip), easy to use(all through an admin interface).
great response from someone at the center of the django universe.
the django devs have said it over and over: django's release schedule isn't determined by an urge to increment version numbers, but to make sure things are ready for release and won't cause any backpedaling down the road. you don't publish a news article before the 'i's are crossed and the 't's are dotted, so why treat software the same way?
#2070 has been seemingly sitting around forever, but given the major changes that just happened with the queryset-refactor and whats going on with the newforms-admin branch and other major undertakings, some things can, in fact, be relegated to the back-burner. i can understand why people think its been sitting around for too long, but consider the priority of what else is on the stove before focusing on getting it out of the kitchen -- especially when the development trunk has such a fantastic track record of stability.
A lot of people (including myself) have a few Django bugs fixed in their private working copies but they don't contribute them back because the process is too complex. This doesn't mean that they are not willing to contribute. Barriers for contribution are way too high.
It's true that you must continually fight people to help those people to fix their project. It shouldn't be so.