I don't know enough about the specifics of the case to assess the new policy on the merits, but I will say that as a piece of writing this is a model of how to change policy gracefully: clear, forthright, and non-defensive.

It's useful to have journalism and english lit majors as the BFDL's for a web framework. This is the main reason that the documentation for the framework is so amazing, the owners of the project really care about it.

It's probably safe to say that Django has hands-down the best documentation I've ever had the pleasure of using in an open-source project. No matter what you need, be it a step-by-step tutorial for first-timers, detailed documentation of every piece of the framework, low-level API docs for basically every function in the damn framework, or guides to writing your own reusable "apps" in Django, it's all right there on the project's website.

Jacob Kaplan-Moss (one of the creators of Django) wrote a great series about documentation specifically at http://jacobian.org/writing/great-documentation/.

Agreed on both counts, particularly the documentation. Its clearer and better written then probably any I've ever come across; it's incredibly well done.

This is a great step for them to be taking as they're getting ready for 1.3 development (for the uninformed, 1.3 is mostly going to be for closing the massive amount of tickets/bugs that Django has accumulated, and generally cleaning up the code base with even more documentation). One of the biggest concerns brought up by multiple people at this year's DjangoCon was the process of getting something into Django's trunk as an outsider.

Great to see them addressing the issue head-on so soon!

Sounds like they're addressing some of the growing pains in Django's ever increasing popularity. Good problems to have I suppose.

This is awesome Jacob, and good work from Django Core - there's a few things for python-core to consider here as well.

Great news, here's hoping one of the new patches will finally be a truncate template tag ;)

You mean like http://docs.djangoproject.com/en/dev/ref/templates/builtins/... or something different?

I think he means this: http://docs.djangoproject.com/en/dev/ref/templates/builtins/...

No, neither of these is what people have asked for over and over..

This is actually one of the banal examples of Django's broken process. For an interesting read on it all, check out this thread. No fundamental downsides given, yet it languishes forever more.

http://groups.google.com/group/django-developers/browse_thre...;

Seeing as I know that thread pretty well, I'm not sure I agree with your characterization; for example, the first couple replies from committers raise a valid point about whether it's a necessary feature given what Django already offers. Later replies go into specific questions about use cases, technical issues, etc., and honestly that's the way it should be.

Meanwhile, for all the people who are apparently up in arms about this feature, only one's ever bothered to put a patch on the ticket, and the patch is three years old and has technical problems that I brought up in the email thread. That's not the way to get a feature into Django, as far as I'm concerned.

Given the ease of implementation of many of the feature requests I see on the django lists and the (seemingly) critical nature or large inconvenience described by the requestees there is an annoying lack of patches.

This is a problem that most OSS projects suffer from and I think the change in tack goes some way to addressing this problem. Certainly I am going to go and finish off my patches and start trying to get them accepted. I feel more confident that putting the work in is going to be worth my time as the processes are being improved to get them committed and I won't have to go on maintaining a fork forever and ever.

I believe the hot issue is truncating by characters. the slice template tag doesn't quite get the job done because it will not intelligently add elipsis