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.