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

[Chris Johnston]

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.

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 8:11 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Probably best to move tickets to 2.7 instead

>
> Jacob Santos wrote:
> > Is that good or would it be just plain terrible to move that many
> > tickets out of 2.6 and put them into 2.7? 2.6 is most likely going to
> > have 700+ open tickets. That will be a lot of fun.
>

My opinion, for what it's worth, is that pushing the milestone out to 2.7 on
these tickets would only be perpetuating (or delaying) the problem.

As I see it, the "problem" is that there are tons of tickets with a
milestone set to whatever the next release happens to be at that time. This
usually leads to some degree of confusion, and at least one post on this
list (and elsewhere) shortly before release time to the effect of "OMG there
are still N... open tickets for the next release!"

My suggestion would be a more conservative use of the "milestone" field, in
which the value is only set when the fix (or whatever) for a particular
ticket is actually planned to be released in the version that the milestone
suggests.

For the default tickets which don't have a *true* version target (yet), I
would suggest either leaving / setting the milestone field to blank, or
creating pseudo-milestones to indicate "future release", etc.

I think this practice (if adhered to) might produce the desired result: a
more manageable and realistic list of tickets that are actually being
targeted for a given release.

- Jared
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers