[wp-hackers] Probably best to move tickets to 2.7 instead

[Jared Bangs]

On Sun, Mar 9, 2008 at 7:59 PM, Chris Johnston <chris at chrisjohnston.org>
wrote:

> I agree that there needs to be a change. I think that everything should go
> into "Future" by default, or even have sections listed for "enhancements"
> "bugs" and whatever other choices there are. Only certain people can elevate
> problems that don't have patches (which would be medium-high priority that
> need to be fixed on a maint. Release. Otherwise they just stay in what would
> almost be a pending folder, and as patches are attached, they get moved to
> testing, and then moved to the version when it has been tested and ready for
> a patch. I'd be willing to do the work of moving the tickets into the
> correct categories if this was decided to be done to get the first "main
> cleanup" done.


This may sound nit-picky, but designations like "bug", "enhancement", etc.
already have a place in the "type" field, so I'd suggest leaving them there
and leaving that type of categorization out of this processing. Same for
priority, severity, etc. which I'm not proposing need to change at all. I
think the narrower that we keep the scope of this proposal, the more likely
it is that it might actually happen.

The only reason I'm focusing on the milestone field in particular is that I
think it would be a good idea to bring back its semantic meaning and its
value, by having it actually refer to a realistic milestone that the
specific ticket is likely to be addressed in, and get away from having the
next version number milestone have all sorts of other overloaded meanings.
I'd even be OK with a milestone labeled "future", although if it were up to
me, I'd say always leave the field blank until it actually has a realistic
milestone target.

I think it would be nice to tackle just this specific milestone issue on its
own, since I think it's a bit more manageable that way. If we want to talk
strategy for how to approach it, I'd propose clearing the value on all the
tickets for which we aren't absolutely sure are going to be addressed in a
particular version, and then having the "owner" (assigned to, etc.) come in
and set it if and only if it's a "real" estimate (meaning that it's really
likely to be included in the specified release).