First, I would like to give all my compliments to the persons that made Django what it is. Although my background is in scientific computing since 25 years back (using python, numpy, scipy, among other things), I came into contact with Django 0.91 in 2006 when one of my students used it in a project. I have used it myself since 2009 in a private genealogy project which is alive at webfactional.com (running django trunk) since a year ago.
I can perhaps spend a couple of hours per week on this hobby project, so I have realized that I have a quite different view on what should be included in django.contrib than what seems to be the present view on the django mailing list. Rather than slimming django core, I would like to see more "best practice" apps included in django.contrib. I (and I think/hope many with me) simply do not have the time to browse the jungle of third-party apps to test, compare and find out what might work for my purpose. I would like to see that some of these decisions are made for me by more experienced users/developers, if possible. When I see comments on that admin should be developed separately, I disagree. At least I would like to see a discussion early in each release cycle to find out if there are any third-party apps "worthy of" being included in django.contrib, and perhaps one can be included in each release cycle. I see another perspective on this from my work. For our python software, I allow python, numpy, scipy and a few more packages. To include more packages is a big deal for a huge number of reasons (project complexity, learning curve, maintenance, etc). On the other hand, the packages included in the project should be exploited fully. I think Django face the same problem in many environments; it is a big deal if a particular third-party app can be included or not. A suggestion is django-debug-toolbar. I think that is the kind of app new users should learn how to use relatively early in a learning process. Also if included django, a lot of best practice programming in views and templates can be documented in a better way if django-debug-toolbar is available. For me, this is a no-brainer if the app authors are interested, license conditions is fulfilled, core developer capacity is available, etc.. A second suggestion is django-mptt. It is a text-book approach that has many use-cases, and I cannot see that there is a need for more than one standard implementation (although there are also other ways to implement trees which have their use-cases). I realize I represent a user group that is not very visible, with only occasional comments on django-users and in tickets, but I hope my opinions are welcome anyway. Best regards, Per-Olof -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
