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

[Jared Bangs]

On Sun, Mar 9, 2008 at 5:24 PM, Jacob Santos <wordpress at santosj.name> wrote:

> That seems to be a good solution, but I remember a similar one that was
> also suggested and nothing has come of it yet or may never will.
>
> I think the standard is that if a ticket has a patch, it is slated for
> the (trunk) release, whatever it may be. If the patch does not have a
> patch, then it is moved to the next release. However, this usually only
> happens during the feature freeze when it is decided what tickets will
> be seriously slated for the current release.


Yeah, I get what you mean, and I understand how it has currently been
working (or not working); I'm just saying I think it might provide more
valuable information if it were done differently. Currently, it's difficult
to tell which of the many 2.5 / 2.6 (and soon 2.7) tickets are actually
planned for that release and which ones are just there by default. I think
that takes enough away from the usefulness of that field to justify a
cleanup and process change.

The effort is mostly dependent on the community and the core commit
> team. With any open source project, community members make patches for
> tickets that they feel like creating patches for. The current standard
> would work best and does currently, but mostly, I can't see nor do I
> want to see that many tickets pushed to the next release filling up my
> mailbox with sends to the next release.


Of course, changing would also certainly require effort, but not much more
effort than it's going to take to continually move them to the milestone
corresponding to the next version each time. I would suggest a one time
cleanup and then a standard that specifies the criteria for when it's OK to
attach a particular version number to a ticket. At a minimum this should
mean that there's some buy-in / active ownership of working towards that
release date, as well as on-going "sanity checks" where someone like Lloyd
(or other volunteers) corrects what appear to be unrealistic entires, as
they do now.

All I'm really saying is that I just personally prefer to see a little more
meaning attached to the assignment of the milestone field. As it is right
now (or at least as I understand it), the meaning of the "next version
number" milestone is overloaded to include things that are actually likely
to be in that release (ie: people are actively working on them towards that
specific goal), *as well as* tickets that are suggested for "some future
version", plus some that may or may not even have any chance of going in at
all, but they're just there as a default.