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

[(GGGGGGGGGYYYY)    ]
   ^       ^
   |       |
   |       +-- Yellow Part    
   |
   +-- Green Part

Then tasks in different statuses could have different colors or whatever.

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.

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.

In particular, I think (?) this element probably doesn't "unearth" or "discover" any new information. The default state (X of Y tasks) is probably obvious at best (e.g., near 0% complete) and misleading at worst (e.g., 90% of tasks is almost never 90% of time), and likely has little relationship to project completion date. I suspect if we enabled this element on this install without doing additional organization work, project bars would be essentially meaningless and frequently defy common sense assessments of project status (even if we just ran it on single vX columns, disregarding project-level organization).

To make the bar accurate, I think someone needs to actively PM a project, organize it, and assign point values. If this is true (i.e., the bar is accurate only if you've done a lot of work to make it accurate), I think maybe it's really a communication tool, not an analysis tool -- that is, it's a standard way for a PM to show the status of their project to others and let PM-managers compare the status of several projects using a standard element, not a way for a PM to discover new information about the status of their project.

Is that roughly in line with your thinking, or do you think of this as an analysis tool in some capacity?

If this is a communication tool, we should maybe look at exposing a cross-project view of it in the future (e.g., as a PM-manager, assess state of your PMs' projects).

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.

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

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

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

There are two points in the middle:

• X is the current date (i.e., the percentage of available time which has already passed).
• Y is progress (i.e., the percentage of story points which are complete).

If X is less than Y (as above), you're ahead of schedule. The area between the two is green, and the wider the green area the more ahead of schedule you are.

If X is more than Y, you're behind schedule. The area between the two is red, and the wider the red area the more behind schedule you are.

The area left of X and Y (work which should be complete, and is complete) is some neutral color (like blue).

The area right of X and Y (work which isn't expected to be complete yet, and isn't complete yet) is empty.

That's kind of complicated, but basically it would look like this:

Ahead of Schedule

About 20% of the timeline has been used up, but work is almost 50% complete. This project is way ahead of schedule.

Behind Schedule

About 20% of the timeline has been used up, but work is only about 10% complete. This project is behind schedule, although there's still a lot of time to get things back on track.

Way Behind Schedule

ha ha ha ha ha ha everything is on fire

But maybe that's overcomplicating things and it would be easier to just show two bars:

20 of 46 Story Points
[=========            ]

17 of 19 Days
[===================  ]

I think it's harder to compare a lot of projects against one another if you have to look at two bars, but this is probably a lot clearer than they hybrid bar for looking at a single project.

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

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

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?

I haven't fully decided yet.

We need to do Facts before we can draw accurate charts (we can not efficiently compute when tasks were added to or removed from a project, or had their point values adjusted right now, but need to be able to show that information in a chart, since a scope expansion halfway through the project shouldn't look the same as all that work existing at the beginning).

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.

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

@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).

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.

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.

@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).

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

@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)?

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

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

Even with an assumption of 1 story point per task, we would find this useful now.

Back when I was developing the burndown chart support for my instance, I just had a "Start Date" and an "End Date" for a project, and we did some magic number calculations to project the current rate of burndown and whether or not it was on schedule for the end date. It was pretty useful because it gave us a good visualisation on whether or not we had the capacity to bring new features into the sprint or whether we needed to focus on our current scope.

Although a progress bar isn't as fancy as a nice graph, having the progress be the current date through the sprint and a visualisation of whether we're ahead or behind would still be extremely useful.