On Sun, Sep 25, 2011 at 12:06 AM, Luke Plant <l.plant...@cantab.net> wrote: > On 21/09/11 10:40, Stephen Burrows wrote: > >> Just thought it might be worth mentioning in this thread that django- >> ticketeer is coming along nicely. (For those who don't know, django- >> ticketeer is a django front-end for trac installations which was >> spawned during the djangocon sprints). It now supports viewing & >> editing tickets, adding tickets, and searching tickets, though a lot >> of specific aspects of those actions are not yet supported. >> >> If anyone is interested in contributing, that would be great - >> especially people who love front-end work. The project was started >> because Trac... doesn't provide the best user experience. Ticketeer >> should. > > This isn't really my business, and possibly not on topic, apart from the > fact that Django really ought to be a well-behaved Python citizen, so I > thought I'd voice my concern: > >> The project was started >> because Trac... doesn't provide the best user experience. > > I really cannot understand this as a rationale. If Trac doesn't provide > the best user experience, surely the obvious thing would be to fix Trac > with some well written patches - it is an open source software after > all. Has this been tried? (Genuine question). Have they said "we are not > interested in improving user experience" or something? I do genuinely > hope I'm wrong, and perfectly willing to be corrected, but to me, this > sounds like thinly veiled Not Invented Here syndrome, and I don't think > that is good for the Django community. > > Yes, Trac is not written in Django. But Django isn't perfect, it isn't > the best for every job, and I don't want us to antagonise other Python > communities by suggesting it is, and by doing our own thing instead of > contributing work back to the original project. The latter is much > harder in many ways than the former, but I would suggest it is much more > profitable in the long run, and a good opportunity to learn from another > project, which will surely have significant strengths of its own.
I completely agree that rebuilding Trac just to have a Django version of Trac isn't a particularly attractive idea to me. If there's some contribution we can make back to Trac, we should certainly do that rather than try and build our own version of Trac that will inevitably have it's own flaws. That said... David Eaves' opening keynote at DjangoCon certainly gave me some food for thought about directions that this sort of project could lead. http://blip.tv/djangocon/keynote-david-eaves-5571777 David spoke about community management, and about how the tools that we use for community management are a key part in coordinating our volunteer user base. In particular, it got me thinking that while Trac may well be a perfectly serviceable tool for managing the internal bug tracking lifecycle, it may *not* be the best public facing tool for interacting with our community. David made the valid point that when someone contributes -- in any way -- having their first experience being "You've posted in the wrong place" or "don't post that here" or "that's a duplicate" isn't very productive -- in fact, it can be counterproductive, as it turns someone who *might* turn into a valuable contributor into someone who has had a negative experience with the project. There may be some space here for a tool that is focussed on this sort of user experience. "Replacing Trac" isn't an interesting goal in itself, but improving the interface to Trac *is* an interesting goal -- and that may mean wrapping Trac in a set of tools that aren't appropriate for inclusion in Trac itself. 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 django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
