Page MenuHomePhabricator

Getting rid of #Future-Release
Closed, ResolvedPublic

Description

Is there any point in keeping Future-Release in the current times? Future release == No release.

70 tasks are assigned to this "milestone".

Related Objects

Event Timeline

Qgil created this task.Dec 11 2014, 7:22 PM
Qgil raised the priority of this task from to Low.
Qgil updated the task description. (Show Details)
Qgil changed Security from none to None.
Qgil added a subscriber: Qgil.
Aklapper claimed this task.Dec 11 2014, 7:45 PM

IMO it's one of those "wishful thinking" target milestones that somebody once created in Bugzilla with good intentions.
As I prefer to have "real" plans with commitment instead clear targets (a release number) I'm going to kill it.
And such Target Milestones (or release projects) could always be bumped if plans don't work out.

I might very well have been the one who created this in BZ. It's useful when you have at least a couple of milestones mapped out and you're going through and making sure every single one of your bugs has a milestone associated with it. You could use it to tell the difference between "we haven't assigned a milestone to this bug yet" and "we explicitly decided not to handle it in one of our planned milestones; revisit when future milestones are mapped out". I used something similar quite a bit at $DAYJOB-1.

Some projects on GitHub use a rolling "Next release" milestone to indicate a medium priority. Or for when it's not clear yet what number that next release will be (e.g. you're at 1.5.0, working on 1.6.0-alpha and issue can be for either 1.7 or 2.0, depending on.. something).

On our case I think we'd better off doing what e.g. Chromium does: If after a release there's any open tasks left, re-triage them as lower priority without a milestone; or move to the next milestone. The latter happens semi-automatically every 6 weeks.

https://code.google.com/p/chromium/issues/detail?id=400866

Moving all non essential bugs to the next Milestone.
Labels: -M-38 MovedFrom-38 M-39

https://code.google.com/p/chromium/issues/detail?id=387290

Moving all non essential bugs to the next Milestone.
Labels: -M-39 MovedFrom-39 M-40

And eventually:

This issue has already been moved once and is lower than Priority 1, therefore removing milestone.
Labels: -M-40 MovedFrom-40

Qgil added a comment.Dec 12 2014, 10:27 AM

I'd rather keep a consisting use of priorities:

  • High - Normal: it's in our radar and we want to schedule in a sprint soon.
  • Low - Needs Volunteer: we'll look here only when the rest is under control.

If a specific project really wants to play with this idea, they can create #MyProject-Future-Sprint with a sprint label without asking anybody. Because tags are global, I would prefer to avoid particular cases as much as possible.

Aklapper added a comment.EditedDec 15 2014, 1:51 PM

If we had a rolling release having "Future Release" would work, but we don't. :)

I'm very happy to create specific Target Milestone tag projects for future releases like 1.26, 1.27 etc. to avoid using "Future Release" whose open tasks will be never looked at (let's be realistic) while looking at open tasks for a *specific* future Target Milestone tag / release.

I'm happier to express plans via date-based, "specific version" target milestone project tags in combination with time-relative priorities which can change over time, and/or optionally workboard columns if wanted by teams.

Aklapper raised the priority of this task from Low to Medium.Dec 16 2014, 5:25 PM

Alright, so I'm going to archive the "Future-Release" project soon if noone adds any further pro arguments.

I'm assuming it's easy enough to un-archive a tag that's been archived, correct? If so, no objection from me.

Qgil added a comment.Dec 22 2014, 7:46 AM

Yep, unarchiving projects is just a matter of clicking an "Unarchive" button without requiring special permissions.

Aklapper closed this task as Resolved.Dec 22 2014, 12:42 PM

I have archived the Future-Release project.

In the case of long term planning, I am happy to create target milestone projects (cf. T75916) like 1.26 or 1.27 if already wanted.
The potential advantage of "bumping" the TM of a task, like postponing from 1.x to 1.y to 1.z, while not removing previous (ignored) TMs from that task's projects && archiving those TM projects in Phab is that when looking at such a task, you see that the task has been postponed already a few times, indicating that the task might need more attention / (wo)manpower etc.