Awesome, thanks! Updated to latest and confirmed.

Thanks for the report! Resolved at HEAD.

test

We use a custom field release description of type remarkup. We then export tasks via conduit API to our HTML release notes. In this release description we use some of the remarkup feature set.

In conclusion, we should never add options to the product.

(The difference between the dark and default background colors is so subtle on my monitor that I never noticed it.)

Oh, I do have that set locally -- I thought phui-theme-dark was just the default (since we got rid of light?) but this fixes itself if I switch to, e.g., the red header.

Oh, is this just a dark-theme issue? That seems easy to fix.

In general, we can't possibly create buttons for everything -- there are way too many rules, and some of the rules don't lend themselves easily to clicking a button. The icon already links to the full documentation, which explains everything (and this document is huge, because there are ton of rules).

I really like the look of the inverse tag, although I haven't personally felt too much confusion about milestones vs nonmilestones on project pages.

we could invert tag colors on milestones to stand out more.

I have a vague idea about adding some sort of "addIconAttribute" method eventually, so that we could in theory pass any Task metadata over like how many diffs are attached, if its blocked, pholio mocks, etc. Sort of what we originally planned footIcons for. I also need to just remove the footIcons code.

Alright, let me take a stab at that..

Yeah it should just be a tag set via addAttribute. I only ask that it renders as the first attribute.

The rest of this will roll up into other tasks which actually use it, etc.

In T10288#157504, @epriestley wrote:

If we're requiring setup and active management before we show a bar, maybe this bar is better?

(-----X~~~Y          )

The left side of the bar is "Start Date". The right side of the bar is "End Date".

... snip ...

@chad Yes, I ran across it recently. However, it's not clear to me, whether Phragile offers more comprehensive Agile functionality than the Sprint extension, or it is just a repackaged original extension with a more independent installation.

@epriestley I think you're slightly exaggerating the complexity of my suggestion. Anyway, this is my first acquaintance with reporting/charting functionality in Phabricator, so I will take time to read more about it (via the task you've linked and beyond). Since you're online, could you give me a pointer to info (beyond Harbormaster documentation), perhaps an article, which describes an end-to-end process of building a CI implementation without external CI servers, such as Jenkins (of course, if it's possible at the present time)?

They maintain a separate plugin I think for charts I think, Phragile? https://blog.wikimedia.org/2015/12/08/why-we-developed-phragile/

@chad Yes, that was my implied suggestion. Thank you for clarification. Perhaps, I need to take another look at the Wikimedia's Sprint extension (I'm trying to minimize dependencies on external Phabricator add-ons).

Maybe I misunderstand the request. It sounded like you want each project to define what a "story" is, meaning any task that lives in multiple projects, would have to implement and track each individual projects "story system", thus making task management significantly more complex (hundreds of fields to manage in each task). We don't have per project based custom fields for similar reasoning, mostly that tasks are "free range" objects on a graph, and projects just are metadata about them, not the other way around.

You're basically just asking for a magic chart feature that does whatever you want. We, bound by earthly constraints, can not build that, and the request itself is not specific enough to be helpful in defining product direction. See also T4171.

@chad I don't see how this fact affects my suggestions. When calculating progress indicators, this simply means that those indicators should reflect corresponding projections (which tasks belong to which projects).

Projects in Phabricator are just tags, and Tasks can belong to multiple Projects.

I think that there should be a single progress bar per project (sub-project), where what metrics (story points, days, ...) are used to produce the corresponding chart should be user/admin-configurable on an individual project (sub-project) basis. That way, both single-metric and more comprehensive multi-metric charts are possible, based on projects' specifics and users' preferences.

I haven't fully decided yet.

In which case I might show one bar, but color it differently if you're ahead of or behind the projects burndown rate. I don't know, I'd have to research it a little. Were you expecting to put Completion Date as a field on Milestones?

Adding a target date to a Milestone opens up other options for UI, like a mini burndown chart.

(Maybe the hybrid bar would be useful in some far-future PM-manager-manager view or whatever.)

If we're requiring setup and active management before we show a bar, maybe this bar is better?

Yeah, it doesn't convey anything otherwise, like you note.

Ah, so you wouldn't even show this bar until we implement points?

I always expected it to be directly tied to "story points" or whatever someone defines that field to be (hours, points, whatever). And that by default, there is no points in Maniphest unless someone has configured it specifically (or basically no [n] at the top of column). Even then, only on Milestones. This is why I think the number and the noun are important in defining what the bar means. Then the bar itself is just UI polish to the number data.

As a general philosophical question, what actionable information are we trying to convey with this element? I think it looks good and is probably worth adding even if it's just a "pretty bauble", and it's nice because it can show something reasonable and immediately comprehensible without any additional configuration/setup, but we're starting to descend the slippery slope of charts and graphs and I'd really like to be armed with strong product rationale as we proceed.

I'm also 90% sure I'm going to have to build a PHUIX / pure javascript version of this anyway, so the pretty photoshop pixels are probably more important than the specific markup.

Minor, but it would be nice support multiple color segments, e.g.:

This bare "v3" in the is still a little weird:

heh

yeah whatever

》 looks okayish but has weird spacing:

❱ he he he

HOLD ON WE HAVE HUNDREDS OF BRACKETS TO LOOK THROUGH STILL

⟩ doesn't have the bad spacing but does have an odd baseline:

Using the Milestone Icon should identify it clearly as a Milestone.

We could just do parens. [ Stonework (Iteration I) ]

〉 has the bad spacing and also a weird baseline:

〉 looks a lot better, except that it has some kind of bizarre super-wide right margin on the actual glyph, at least on my system/font:

Well, it doesn't look awesome either:

› probably doesn't look that bad.

I think this is actually a little tricky. In the UI, I'd like to see us auto pre-pend the Project Name with the Milestone, then represent that as the object everywhere (search, tags, typeahead, page title). But that likely means using some UTF-8 delimiter over a pretty pretty icon.

it's beautiful

One hovercard related suggestion in T10187: hard to understand status of sub-tasks from parent was to add projects/columns to Hovercards so that when mousing over subtasks you can see what projects they are in without opening them all. It looks like the latest mock has that so