These are still prototypes for now, you should have seen this when you created the Milestone:

@epriestley I have noticed that, in your first comment above, two links, titled "in this document", are broken (links are located in sections "Branching" and "Merging"). It would be nice to have those links to presumably useful and important documents fixed.

We may have implemented this at HEAD. Kinda bare bones, but pretty!

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

Some day we'll provide some kind of tooling or migration approach here, but this seems stable for now.

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

Given the feedback from @Krenair / @MZMcBride, I'm going to shelve this for the time being since WMF is the major driver for it but it looks like some mixture of contentious/low-priority/hypothetical, and even if consensus/priority does develop from WMF I'd like to wait for EditEngine and make sure the problems survive the new capabilities it introduced.

(Oh, the WMF task got a similar token so it's presumably an objection to the control.)

I'm not sure if that thumbs-down is an objection to introducing this policy control or an objection to my hesitance to introduce this policy control.

On the Wikimedia side, looking at https://phabricator.wikimedia.org/T1178, I see almost no support or consensus for this feature. Restricting open editing is in some ways antithetical to Wikimedia's values (we try to be as open as possible) and there are a lot of other issues with Phabricator that are higher priority for us.

Looking deeper, I'm sort of wondering if we actually need this. Are you seeing (or still seeing) issues with this?

I'm just going to merge this into T10010 and note it explicitly as errata; I'm planning to do this but just haven't built a hide-menu-item feature yet.

Thanks for catching this!

That fits what the code does - it looks like it gathers all good options, and that includes a "some" projects, if any.

Turns out that it's not just if zero projects exist, but if the user attempting to create a project does not belong to any project themselves. i.e. no projects are shown.

Looks like it was broken at e1c934ab22d8c0d88ec1ce0d73bc497e563b4acb (Works at 8a9f7609755af5e32c2c287c4b732d213cb680ee).

There's a lot of junk in "any icon", maybe 10% of the Font Awesome set is useful. We also don't have a chooser for "any icon", so we'd need to build something as such. I could be wrong but I think since Badges is on EditEngine you could set any icon over Conduit. I don't know if I read Evan's diffs right or not.

• @avivey we have our own library that is loaded in when arc runs. I had an out of date version of our library which caused this to throw an error.
• The chief complaint is that arc unit for unsound tests exits with a status of one since it's indistinguishable from arc completely failing.
• A harbormaster build step is reading the exit status to determine if the test was a real failure or just the result of an unsound test not passing.

I don't fully understand the issue description:

Basically, an alternative Notification implementation?

It's a very simple hook to listen to the Phabricator feed, figure out who is subscribed to the object that is the subject of the feed, and ping them in Slack. The goal was to make it stateless so it could be used as an AWS lambda. It's done wonders for our review response time.

I'm genuinely curious what you use the integration for. I am interested in more integrations down the road and knowing what installs are really doing with it is helpful.

The plugin approach will probably work fine for us. Thanks @epriestley.

In T6502#157400, @epriestley wrote:

This is probably happening tomorrow, unless I am just toying with everyone's emotions.

I've just shared some common strings into french. It's on GitHub : Phabricator French Translation.

This is probably happening tomorrow, unless I am just toying with everyone's emotions.

Yeah, this feature was a mistake and the data should never have been disclosed. We consider user email addresses private. I don't plan to expose this information again.

I don't know the history of that field, but reading the previous diffs makes it sound like this was a mistakenly added "feature" in D11791 and "fixed" in D12848. @epriestley could answer those specifics, but my guess is that field won't be re-considered for Conduit. I imagine the solution would be Doorkeeper / Oauth for Slack. In the meantime you can crib notes from those diffs to patch in the functionality you need locally.