Is there any point in keeping Future-Release in the current times? Future release == No release.
70 tasks are assigned to this "milestone".
Is there any point in keeping Future-Release in the current times? Future release == No release.
70 tasks are assigned to this "milestone".
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
I'd rather keep a consisting use of priorities:
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.
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.
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.
Yep, unarchiving projects is just a matter of clicking an "Unarchive" button without requiring special permissions.
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.