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

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.

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

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.

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.

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.

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.

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

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 was considering building a formal "Milestones" page which listed all the current milestones under a parent and their respective progress.

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

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

Oh maybe I forgetful. Anything can track progress.

Because they track progress.

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

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

To summarize where we've ended up:

The general shape of the change is reasonable. However:

@epriestley I know you've said no on accepting a patch for this one, but we've found that without the "author" field sent to Buildkite it's not very useful.

Arguments against:

Aha! That works wonderfully. I think this is INVALID, then.

Use tsprintf() ("terminal string print formatted") instead of phutil_console_format():

需求故事收集看板

Thanks! That should be perfect.

Possibly also, add a "See All" link to ApplicationSearch

Sounds reasonable to just improve that.

Hey, we're also interested in this by way of T12545 (which was merged in above). A couple of our teams have historically assigned their oncall/tech-debt tasks to a mailing list user, and used the priority-sorted view of those tasks to run their oncall shifts. That workflow no longer works with the reverse-chronological sort.

I had indeed implemented precisely that herald rule once I realized that these diffs were being created without repository info attached. I also added repository.callsign to /etc/arcconfig to eliminate the problem going forward.

We've seen a couple of flavors of this from @swisspol, too. Although the symptom there is a little different (not a policy issue, exactly), the root cause is mostly similar. In particular, we saw:

Here's an example of the old style:

Its on another page for scalability, we used to just have a single page.

Yep, that would be the page. I was expecting to see details ala "Related Objects" in Maniphest and failed to move my eyes sufficiently left.

This page?

In T12234#211222, @epriestley wrote:

From a technical standpoint, we did not record these relationships in a normalized way prior to D16196 (June 2016, about 7 months ago) -- they only existed in the transaction log, and we just wrote a "close", extra_data="as duplicate of X" transaction that can't be queried efficiently.

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.

@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…

For those looking for ways to manually move projects until this is implemented: T10350: Scripts to migrate old "points" fields and move projects beneath other projects

Thanks chad for all your help!

I also can't reproduce the original report in the general case: when I type text into the "Create Task" form, click a notification to navigate away, then press "Back", my text is recovered. This is true whether Quicksand is enabled or not.

Thanks for the feedback, those are useful references.

That wouldn't actually address the original problem here (accidentally setting your computer on fire and losing work) but would address the issue in T12731.

A possible attack on this is via whatever future abuse system we ultimately might build (T10215).

Maybe also T11440 for drafts.

I think its fine to let people manage how they get notifications in Phabricator, however giving every user the power to override every other users notification preferences would make Phabricator significantly unpredictable, which isn't acceptable to me in an enterprise setting. I'd suggest these users affected by focus issues use any of the hundreds of applications already available (including the task I merged this into, which will give even more control).

Please read Contributing Feature Requests carefully before filing feature requests. This does not describe a root problem; see Describing Root Problems.

I do think "Quote" needs to be somewhere (it wasn't listed at all in T11401#224171, though you mentioned it). Shift-click on reply could also be supported, but such a power user feature is far less important than an easily discoverable function. I believe that I personally would use "Quote" more often than "Edit", but honestly would be happy wherever this were put. I'll probably upgrade my Phab instance and start using the "R" shortcut next week either way.

I'm also toying with the idea of "Shift+Click" on "Reply" to "Reply-with-Quote" but the only way to discover that would be to read the documentation.

(I normally think of myself as like a 95th percentile power user, and don't use keyboard shortcuts at all in Differential today, and suspect I still won't after these changes. However, I'm also an elite mouse power user, per J769.)

If nothing changes, I was thinking of leaving these top-level:

That is, we show the keyboard shortcut on the dropdown along with the action.

I think if we combine dropdown with keyboard hints, it'd be a good middle ground.

I'm not sure if D17908 is going to stick, but if it does we more reasonably have room to add a caret menu here. I'm not planning to necessarily pursue this in the current iteration, but I believe there are no longer any meaningful technical blockers, just some product questions which will more or less resolve themselves if everything sticks.

See also T5462

Thank you! I read Describing Root Problems but I guess I missed some important points.

See Contributing Feature Requests, and use Ponder or Conpherence if you have general questions on how to do something in Phabricator.