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

[Chris Johnston]

Jarad, what I was saying is that until they are assigned a milestone, they go into the "bug," "enhancement," etc just to make it that much easier to distinguish between. (if milestone=null then sort by type) Then when whoever it is that monitors for emergent items only has to look in the bugs group. Once they are assigned to a milestone though, they go to the milestone that they are assigned and out of the general categories. Basically, I think that having one folder called "future" would put way too many tickets into it to make it easy to go through and see what someone might want to work on.

Chris

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Jared Bangs
Sent: Sunday, March 09, 2008 11:37 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Probably best to move tickets to 2.7 instead

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).
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers