If the milestones aren't strictly ordered, why did the user create milestones instead of subprojects?

My understanding is that subprojects are basically just regular projects but with a parent relationship. We didn't want these projects to pollute the projects typeahead because no-one should be creating tasks within these subprojects (given that these subprojects dictate what we are working on). By choosing "milestone" instead of "subproject", it becomes clearer in the project typeahead that the subproject is internal to the parent project. That is, if we made #our_january_goal a subproject then it would show up in the projects typeahead as "Our January Goal" whereas as a milestone it is rendered as "Our Team (Our January Goal)".

I'd rather fix the core problem if it's an unclear typeahead.

In T12144#208351, @chad wrote:

I'd rather fix the core problem if it's an unclear typeahead.

Agree, but I think that there is possibly also some ambiguity regarding subprojects vs milestones vs projects. Someone has also just asked me what the difference between a project and a subproject is, as they aren't sure whether some projects should be created as subprojects or as regular projects.

That's up to you and your team.

I think it's not perfectly clear in the UI, but we do have it documented:

Subprojects are projects that are contained inside the main project. You can use them to break large or complex groups, tags, lists, or undertakings apart into smaller pieces.

Milestones are a special kind of subproject for organizing tasks into blocks of work. You can use them to implement sprints, iterations, milestones, versions, etc.

T11036 will probably be the next round of changes, but I don't think we have this stuff on any immediate roadmap.

T11750 and T11797 are previous requests (this is the 3rd request for this feature).

@aklapper has pointed me to this task at the Wikimedia Hackathon days ago. At the https://phabricator.wikimedia.org/tag/oojs-ui/ we're dealing with the situation that milestones have been put (I don't know if the exact reason was human or program activity) into wrong order. If you show past, hidden milestone columns visible, you'll see that our releases v0.16.2–0.17.3 are before v0.7.0 which is misleading when going through historic milestones.
Would be happy to see reordering possible as well…

Milestones are a special kind of subproject for organizing tasks into blocks of work. You can use them to implement sprints, iterations, milestones, versions, etc.

Sprints, iterations, milestones, versions are ordered in time (sprint 1, sprint 2, sprint 3, milestone 1.0, milestone 2.0, milestone 3.0, etc.) so columns that represent them should keep sequence required by user. Currently there is a crippled Manage | Reorder columns function that presents window with list of columns to reorder. Unfortunately milestones are not included.

Without ordering milestones on board, the user encounters various problems.

• It is easy to put task on a wrong column.
• It is time consuming to find a proper column in the ocean of unordered milestones.
• It is very distracting to work with badly ordered columns.
• It is time consuming to scroll to needed milestone. I have added milestones: 2016-1, 2016-2, ..., 2017-5. The last one is located on the right edge on workboard and represents current month. To work with this milestone, I need to scroll two light years to the right every time! Also moving tasks on such workboard is cumbersome. The problem would not exist if I had "reverse order while adding", but this is not a general ordering solution. I know that it is possible to archive milestones, but I need some of them non-archived to see specific tasks.

Possible solutions

• Drag&drop (always enabled). Remove Manage | Reorder columns. Allow to always reorder any columns on workboard (Trello like behavior).
• Drag&drop enable/disable mode. Allow user changing order of columns (including milestones) by drag&drop mechanism. Drag&drop is the fastest, most ergonomic and obvious way (at last for me). Allow user to enable/disable "reordering mode" to drag&drop any columns.
• Present all columns. Present milestones and non-milestones on Manage | Reorder columns window.

Other remarks

• It would be useful to allow every user to have his own order of columns. Currently every workboard has some excellent features: Sort by Priority (Natural, Sort by Priority, Save as Default). Re-ordering columns should have something similar (Save Default Order?)
• Task [T11036] is about presenting sub-projects on a board. This is useless. I don't understand why you are not sure about ordering milestones, but authored such strange thing.
• I agree that it is important to present sub-projects somehow, but it should be done using a full blown tree. A sub-project has exactly one parent so there is no problem with drawing a graph. The tree would be a correct way. Currently the Maniphest shows only flat lists of projects (btw. please allow to show them on two columns to save screen space). I would like to suggest adding something working like a radio-button: present projects as a LIST xor present projects as a TREE. Caution: it would be extremely useful so users may demand similar feature for tasks (again!) and wikis! I know that it was rejected on [T4207], but I miss such functionality a lot.
• I would like to have one, consistent tree mode to present any entities: tasks, projects and wiki pages (not at the same time). The main advantage would be one, consistent way to understand their structure and dependencies and manage them efficiently. Take a look: askcow - Holy Grail of project management, Work breakdown structure and project management tools, Asana - what has been forgotten to implement for $40 million.

@epriestley do you still feel strongly to not do this? I presume it's just gated and easy to ship.

My anecdote here is I'm tracking the progress of FontAwesome 5, and they use free-floating milestones to track the progress, but a milestone isn't a v1, v2, it's "Core Icons", "Documentation", "CDN", "Sponsored Icons". Each need to be tracked to completion to complete the top-level project of "FA5". I think this structure is reasonable for shipping a top level project, and the flexibility to get all the benefits of milestones without the strictness seems better? At least, I don't see us getting "please restrict these" type tasks if we made them re-orderable.

I dug around a little on T10349 and other tasks but don't recall where we might have discussed this previously.

Why would you want to set those up as milestones instead of subprojects?

Because they track progress.

Oh maybe I forgetful. Anything can track progress.

What behavior do milestones have that subprojects lack (or vice versa) which is relevant for progress tracking?

Yeah, I'm pretty sure there's no difference.

I was considering building a formal "Milestones" page which listed all the current milestones under a parent and their respective progress.

I think that's conceptually reasonable, but I can't come up with any reason offhand that it should be restricted to milestones instead of showing both milestones and subprojects.

I'm still ok with allowing people to re-order milestones, hard to imagine we'll get reports asking for it to be restricted.

There's no technical reason we can't let you reorder milestones, but adding features that let you bind milestones to time ranges may be much more difficult if we let you reorder them.

For example, if a future version of Phabricator lets you automatically generate weekly sprint milestones and you drag "sprint 33" (in three weeks) backwards (so it's two weeks ago), what are the time ranges of sprints 27-34 now?

We could say "you can't reorder auto-dated milestones" but if we hadn't let you do it in the first place we'd be in the same place with less confusing product behavior.

If we don't ever let you do this, maybe we should just remove milestones instead.

The answer to all the discussion here mostly seems to be "you have unordered collections of similar work -- not a linear series of milestones/sprints -- and subprojects are a much better fit for your problem". I don't know why anyone is picking "Milestone" instead of "Subproject" for these problems, but maybe we should rename it to "strictly time-ordered sequential parcel of linear work" or something.

That is, milestones largely exist to support future features that depend on a linear ordering, like "push all open tasks to next milestone", automatic creation of the next milestone from typeaheads, automatically scheduling milestones sequentially for charting/reporting, etc. If we let you reorder them most of that stuff sort of goes out the window (or, at least, gets much more complicated). And if these features aren't actually important, I think we could possibly just remove milestones from the product.

If anything, a hypothetical "Progress" tab should show ALL subprojects and only a SUBSET of milestones: just the last, current, next, and maybe +2 / +3 milestones. If your work is really linear and time ordered the progress of the milestone from five iterations ago isn't relevant most of the time.

Maybe it's a language problem. "Milestone" to me says "target" so I think it's a fluid set of targets that may or may not be in an order.

What about "Iteration" instead, and maybe a tool to convert to subproject?

I don't think this should be a language problem or that "Milestone" should communicate "flexible target" -- physical milestones are big, immovable, evenly-spaced chunks of stone with a single increasing integer chiseled into them. They're a really direct metaphor for the behavior of milestones as implemented in the product. But feel free to send me a diff to swap it to "Iteration" if you think that's clearer, I'm not married to "Milestone".

You can already create a subproject, then bulk-move tasks from a milestone to it. I think this is generally better than explicitly converting because we avoid a lot of weird side effects (for example: the milestone getting a lot of members by surprise if it's the first subproject, the other milestones getting a hole in their range that we can't unambiguously fill with an obvious rule, the effective membership of the milestone changing because of how milestone and subproject membership rules differ).

One minor fix would maybe be to put "Create Subproject" first on the "Subprojects" page. This is inconsistent anyway -- the tab is called "Subprojects" and the header is "Subprojects and Milestones", but the order in the action column, the curtain panels, and the main panel is "Milestone, Subproject". I think this stuff blame to me in D15152, but "Subproject, Milestone" is probably a better order both for consistency and to gently nudge users toward the more general / less specialized unit of project division.

What about workboard filters? View Milestones, View Subprojects? That sounds like a lot of work though. Might be nice on large parents.

Yeah there are some UI tweaks I can do to dissuade accidental milestone creation.

That's very easy, just a question of whether we want to add the buttons/menu items for it.

But it's mostly moot until T11036 I think. T5024 is vaguely related ("filter to just one column"). T6642 might be related ("save collections of columns") but my recollection is that task was a bit muddy? I haven't re-read it recently.

We could also let you collapse/expand columns like your mock in T6642. None of this hide/show/filter/collapse/expand stuff is hard -- T11036 and T4900/T10336 are the only really involved JS changes in queue for workboards, I think. It's largely just not clear to me which subset of the proposed tools is most useful, and it feel like major overkill to implement all of them.

It doesn't help that GH/GL Milestones are loose tags with a target date.

In T12144#226158, @epriestley wrote:

Why would you want to set those up as milestones instead of subprojects?

Sometimes I prefer milestone because it has parent project's title in label like Projectname (MilestoneName).