On Mon, Feb 28, 2011 at 4:13 PM, Julien Phalip <[email protected]> wrote: > Hi, > > Tweaking Trac seems to be in the air, so I had some more ideas to > suggest :) > > The "component" field in Trac is very useful when people look for > tickets in their areas of familiarity/expertise. I think there are a > few things that should be cleaned up to make the system a bit more > useful and effective: > > * The "Contrib apps" component [1] should be made redundant and new > components for each missing contrib app (e.g. contenttypes, sitemaps) > should be added. I mean, even databrowse has its own component! :) The > "Contrib app" mixes lots of unrelated things, making it a bit > pointless. > * For consistency, the "Authentication" component should be renamed to > django.contrib.auth, and "RSS framework" to > django.contrib.syndication.
Definitely agreed on these two. My only concern would be implementation -- can we change the name of the component, or do we need to go through a "create new name, reassign existing, delete old" dance. This is something that anyone with admin rights in Trac (including myself) can do, once we've got a few +1 votes confirmed. > * Clarify what the "Core framework" component [2] means, as it ends up > being used for a lot of irrelevant things (for example, I've just > cleaned out a lot of ORM-related tickets). Note that django.core.mail > has its own component, but there are so many things that could be > considered as part of the core framework that it might be difficult > and counter-productive to split it in a gazillion components (as > opposed to the number of contrib apps which is reasonably small and > will never grow). At the very least, the name "Core framework" should > be disambiguated if possible. In defence of the status quo -- "mail" is a clearly isolated set of APIs in a single module, but this isn't true of other "core" parts of Django. I think this makes a good However, "core" is clearly being misused (or at least misunderstood). I'm open to suggestions (driven by the data) as to what extra categories we should add and/or how we should rename core. There are 169 open tickets attributed to "core" -- care to make some suggestions? > * Merge the "User experience" component [3] with django.contrib.admin > since it contains very few tickets and the vast majority of user > experience related tickets will likely always be related to the admin > anyway. This differentiation was intentional (at least, it was at the time). The idea of the "UX category" was to provide a list of designer-focussed work -- ie., things where you didn't necessarily need to be a programmer in order to make a contribution. Of course, this ignores the contribution that designers can make in a design as "how things work" vs "how things look" sense. However, I think it's worth keeping this differentiation; it may be a weak differentiator, but I think it's work keeping the distinction between tasks that are known to be primarily Python, and tasks known to be primarily CSS/JS. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
