
The Problem With Django  - nickb
http://metajack.wordpress.com/2008/06/11/the-problem-with-django/
======
ii
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.

~~~
natrius
How is it too complex? Instead of letting the fix stay in your working copy,
why not attach the patch to the bug?

~~~
metajack
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.

~~~
ii
Wow. One of my patches (exactly the one I was whining about here ;) was just
changed from "Unreviewed" to "Ready for checkin".

Thank you very much, Jack. Your blog post really helped!

------
schtog
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).

I defy the bloat of modern software!

------
ivankirigin
The second comment is a really good response:
[http://metajack.wordpress.com/2008/06/11/the-problem-with-
dj...](http://metajack.wordpress.com/2008/06/11/the-problem-with-
django/#comment-115)

~~~
mattdennewitz
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.

