It's configurable.

Where is this configurable?

I couldn't find the place to change this behaviour; I checked:

• The project Manage page.
• The milestone Manage page.
• The "Projects" config at /config/group/project/.

You're suggesting Milestones should not be projects?

No, I'm suggesting that when you click the "Project (Milestone)" tag in the UI, it should take you to the project's workboard.

(I realise that milestones are projects, but I simplified my response to distinguish between the parent project and the milestone that is under that parent project)

What's the point of it being a project then?

You can default a project's page to whatever you want in under Manage Menu. But I don't think that's what you want. I understand what you want, I just would have concerns that it might be unexpected in most cases, especially if you're running the Milestone as a full fledged project with it's own boards.

I can see people want all sorts of different landing spots here.

As far as I understood it, milestones being projects were an implementation detail, because @epriestley didn't want to have two separate structures for sub-projects and milestones.

I'm not sure there's anything to really take advantage of in terms of using the milestone as you would a normal project - membership is implicit, and having a workboard on a milestone seems strange (these sub-workboards won't have any representation on the parent's workboard)?

If you click on a milestone tag and it took you to the parent project's workboard, and you really did want to go to the milestone (maybe to rename it or something?), you can do so by clicking the column header on the workboard:

When you click on a task that has just a milestone tag like this:

You're probably more interested in viewing this task in the context of the parent project, not a description of the recent activity on the milestone.

We used full workboards on our Milestone for Projects (v3). If we linked by default to the parent project, that functionality would be lost. Any sort of auto-redirect to the parent loses all project functionality and power.

We could either try to come up with a new type of tag that lets you choose where you want to go (parent or project). Or split Milestones into Sprints and Milestones. Where Sprints have no Project functionally and Milestones are fully functional. But that seems like a super amount of work and a small benefit.

I guess another question is, what are you using Milestones for if they are just a column on the parent?

It feels like the more formal / correct way to do it I guess? Like, I'd expect in future that reporting would occur over milestones in a project, and not columns on a workboard, because the columns don't have any relation between them (as opposed to milestones which explicitly have a "next" and "previous" milestone).

Milestones give you the ability to explicit close / archive a milestone, whereas columns are just hidden. So the workflow is stronger and more directly maps to what's happening rather than just arbitrary buckets to put things in.

In our case, the milestones are like "June", "July", "August", etc. and we organise things into milestones based on what month we need to get it done by.

In the case of Projects (v3) it looks like you used it to bucket things based on who was assigned, but this doesn't seem like a very feasible / useful thing to do until T5474 is done, because otherwise it's a very manual process.

Personally I'm using milestones to represent releases and the workboard is the farthest thing from what I'd want to show when clicking on the milestone.

The current behavor, defaulting to the milestone project's details page, is correct, and as @chad said, it's configurable.

Relatedly: it would be nice if milestones copied the settings of previous milestones, sort of a pseudo template behavior, where milestone2 copied the defaults from milestone1 automatically (so that if you set a series to default to the workboard, every newly created milestone would share that setting unless you override the default)

This is working as intended.

Clicking the milestone tag shows you the feed and description by default, which I think are reasonable things to want to examine when you click a milestone tag.

Milestones have workboards, and you can make the default behavior put you on a workboard by editing the menu items. If you don't think Projects v3 is a compelling example of using a milestone workboard, maybe Diffusion v3 is legitimate enough:

https://secure.phabricator.com/project/board/1420/query/all/

Getting dedicated workboards is core to milestones, and a major reason why milestones are a type of project instead of a type of column.

If you don't want a workboard, feed, or description and are only using milestones because they are more formal or because of theoretical future features, it sounds like using columns instead is a pretty good solution to your problem?

I think inheriting some of the the default menu configuration between milestones is reasonable, although this is kind of tricky because we probably don't want to inherit all of it (users might add a link which includes a hard-coded reference to Milestone 7, for example, and it would be bad to copy that link verbatim to Milestone 8). If we inherit only some of it, it might not be clear which parts are inheriting or why.

Maybe a little simpler would be to add a third option to the "create a workboard" dialog when visiting it on a milestone for the first time, to make it easier to copy the workboard from the previous milestone:

• New Empty Board
• Copy Columns Milestone 4 << New Option
• Copy Columns From Another Project...

That would just save a couple clicks, but seems like a nice-to-have UI feature?