I just built something in a similar vein as this for my team's
internal use. Amusingly, I used Django's inspectdb feature to directly
interface with Redmine's database and provide a separate front-end.
The data feeds into a javascript graphing library.
The ability to visualize languishing issues, activity over time, etc.
is really pretty awesome. I've got no experience hacking at Trac
particularly, but I can at least speak to how useful having that kind
of resource can be.
- Gabriel
On Apr 20, 2:46 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
> On Mon, Apr 19, 2010 at 9:19 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>
> ...
>
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
>
> I have a perception that there are some phases of the ticket lifecycle
> where things get stuck -- I think that if you look at this
> diagram:http://docs.djangoproject.com/en/dev/_images/djangotickets.png
> there is a pretty clear flow, and people are encouraged to pitch in
> where ever they feel it might help.
>
> But in practice, it seems that some of the edges become queues, and
> some tickets sit in that queue for a long time -- either because the
> next step for that ticket isn't obvious, or because there's a shortage
> of triage attention on that particular ticket.
>
> Earlier in the other thread, someone claimed there were hundreds of
> patches ready (but ignored), while the response was "no, those tickets
> aren't actually ready" -- the issue was a recognition of procedure, in
> that case. Even so, the perception of ignored tickets is part of the
> problem-- whether tickets are actually ignored or not, the perception
> still would discourage contribution.
>
> I'd like to highlight tickets that have sat in each queue for a period
> of time -- a summary of min, max, mean time in queue (over time), and
> a detail view to sort tickets by age in queue, etc.
>
> I know this isn't well-supported by Trac, but Joseph pointed me at the
> XML RPC API--- the pieces are there. I never worked on it; generally,
> I felt that the triagers are doing what they can and if anything, my
> time would be better spent fixing bugs or triaging.
>
> But this debate has been at least partially about responsiveness and
> the perception of inclusion.
>
> Triagers, commiters, off-put contributors, do you think this sort of
> view would help the workflow and understanding of the ticket status?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group
> athttp://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
