On Wed, Jul 2, 2008 at 2:56 PM, George Vilches <[EMAIL PROTECTED]> wrote: > On Jul 2, 2008, at 1:24 PM, Paul Kenjora wrote: > >> I understand the resistance but you've got demand, you've got a >> willing developer, and you've got a clean fix that significantly >> improves the adaptability of the framework. What better reason >> would you need? > > Someone who has a proven history of contributions and maintenance of > the core framework for a significant period of time. > > <snip> > > Providing the addition as a 3rd party framework allows the community > to vet your work and decide whether 1) it's worth inclusion, and 2) > that you have the stamina to maintain it in Django for a long while to > come.
I'll also add that appealing to the community is often a much better way to get feedback on improvements that can be made. My first contribution, signed cookies,[1] started as a patch in Trac, that ended up moving to its own application, at which point I got a much better response of people using it, finding bugs, suggesting enhancements, etc. My second, dbsettings,[2] started as its own project, then had the possibility of being included in trunk, so I immediately started making changes to satisfy the immediate onslaught of suggestions. As time went on, I came to regret that, as sitting back and riding the normal community support wave would've made for a much better, more usable application. I think the main issue is that when something's sitting in trunk, or even in Trac, there's something of a bureaucracy, whether real or perceived, where the core developers are the gatekeepers of all decisions. People are quick to identify bugs, but given how long some decisions can take in trunk, people are less likely to speak up about suggestions or improvements. On the other hand, third-party applications in general have a better track record for acknowledging and responding to feedback much more quickly, and by more people. This helps get everything refined and polished fairly quickly, and with a high level of quality. And, as has been said before, if you write a good application, support it well, make it consistent with how Django itself works, and help a lot of people with it, there's a good chance it could be considered for inclusion into Django itself later on. Certainly a much better chance than if you just throw it in a ticket and ask why it hasn't been committed yet, anyway. Jonathan Buchanan's django-tagging[3] is a prime example of this, and will probably be one of the first considered for django.contrib after Django 1.0 hits store shelves. It's already on the shortlist of applications that many developers install in every new environment they work with, and once Django itself settles down, it'll probably work its way in fairly quickly. Mind, though, that I'm not one of the people who makes those decisions, I've just been observing conversations for quite a while. -Gul [1] http://code.google.com/p/django-signedcookies/ [2] http://code.google.com/p/django-values/ [3] http://code.google.com/p/django-tagging/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
