Since we've recently been discussing a few ways to improve Trac, I'm
suggesting to move the discussion which started a few minutes ago in
#5833 here so as not to pollute the ticket with too many meta
conversations. I'd also like to apologise for the confusion I seem to
have stirred by changing the milestone attribute of that ticket to
1.4...

I must say I've always been a bit confused by the milestone field
myself. It seems like traditionally efforts have been put in fixing
tickets for a given milestone while nearing the corresponding new
release, whereas in essence no ticket should necessarily take priority
over any other (except if it's a major or annoying bug perhaps). As a
result I've personally interpreted the milestone attribute as a sign
that some people are particularly caring about these tickets right now
and therefore those tickets are worth looking into.

So, following that reasoning I have just marked #5833 with the 1.4
milestone (since I personally care about it and am hoping to get it
fixed by 1.4), which was reverted on the (correct) basis that there
were no tests or doc. Now, after Luke's, Russell's and Karen's
comments I see how my reasoning was flawed. But it makes me even more
confused about the use of this field.

I agree that this field has been mis-managed and been reasonably
useless on the lead to 1.3. For the record, there are currently 44
tickets in 1.4 and 157 tickets in 1.3. What makes those tickets
special, other than the fact that somebody recently cared enough to
update those tickets showing their current interest? Probably nothing,
so this field seems to basically only cause noise and confusion at the
moment.

If I remember correctly, this field was introduced on the road to the
1.0 release [1]. Maybe we should revisit the use of this field now
again, for example by discontinuing it altogether if it is deemed
useless, or by restricting its write access to core devs, or by
designing a better field filling the (yet to be clarified) purpose.

Any thoughts?

Julien

[1] http://groups.google.com/group/django-developers/browse_thread/thread...

I think we have been inconsistent with our use of this field, and my
point in removing it was to make it clear that, despite what some people
on that ticket no doubt believe, adding yourself as a CC to a ticket
does nothing to make it happen, and neither does setting the milestone.

Your e-mail makes me question the usefulness of the field too. One case
it is useful when we near a release and there are some bugs that we need
to get fixed. But perhaps that is overlapping with 'blocker' status.

Another case is when we decide, as we did at least for 1.1 to 1.3, that
certain features are going to get a lot of attention, including a core
developer who commits to either developing or managing the feature into
Django. Perhaps we should clear the milestone flags on all tickets, and
add them only when a core developer commits to getting a ticket in.

However, although a commitment from a core developer has usually been
pretty meaningful, it is still possible that the feature won't arrive if
it's simply not ready (I don't know what our record is like on this
front - I suspect it has been pretty good, but not perfect). So what
does the milestone flag actually tell you? The people developing the
feature will know that they are doing so, and for other people looking
on, the milestone flag may be taken as some kind of guarantee that it
gets in. In reality, as Alan Kay said, "the best way to predict the
future is to invent it", and maybe the lack of a milestone flag would
actually encourage involvement.

Thanks for opening the discussion,

Luke

--
If you can't answer a man's arguments, all is not lost; you can
still call him vile names. (Elbert Hubbard)

Luke Plant || http://lukeplant.me.uk/