+1, let's kill it.

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:

• 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.

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.