After T13630:

See PHI1997, which discusses things from the perspective of reporting coverage from a build system.

PHI1816 would also like dimensional coverage: coverage by language; coverage by team/owner. This is perhaps worth considering in how coverage is aggregated.

Continued in T13542.

Filetree stuff is now in T13516: Remove the "filetree" setting (so it's always enabled for everyone).

wilds and experimental have mostly collapsed together into master, and this is survived by T13488.

get rid of all obsolete / policy-violating stuff so no part of the Facts application is broken;

I believe charts in the UI now make physical sense. They aren't very fancy/polished yet, but everything I see on this install looks cohesive (no more overlapping negative areas, weird gaps, general nonsense, etc):

The "compose(...)" function won't select input values correctly if the first function in the chain isn't a data function. For example, if we compose:

D20814 combines nearby points so we don't have tons of overlapping tiny circles. For now, the grouping is just based on X-axis distance:

In stacked area charts, when we stack areas, we accumulate some error by stacking integer points on top of interpolated points.

if prototypes are disabled, some stuff is broken, particularly "View Chart".

This thread suggests that some version of ssh-keygen is sensitive to trailing whitespace in private keys:

Yeah, this is still in a transitional state, it's just been stalled for a bit (not blocked by anything, just other stuff has been getting attention). The two major issues I'm aware of right now are:

Not sure where to report this, but since a recent upgrade at Wikimedia, the new version of the Burnup Graph (now Reports: Burndown), has a tendency to go below zero. I'm aware the old version had inaccuracies so perhaps it was happening before as well but hidden (e.g. artificially replaced with zero or something like that).

See PHI954. The "support pact members" cache is currently updated only when you actually click "Support", but this is often silly and unintuitive.

Meow Meow

PHI1231 would like API access to coverage.

The actual facts Maniphest currently generates need to be adjusted to properly support stacked-area-by-reason: currently, when a task is closed, we don't have enough data to figure out whether it should be removed from the "created into this project" area, the "reopened work" area, or the "moved work" area.

One issue with model we're evolving toward is that if you view a chart in Klingon, then send the link to a user whose primary language is Kerbal, we'd prefer to relabel the chart in Kerbal, not restore serialized Klingon-language chart labels. That means label generation has to be at render time, not at chart construction time, and I'm serializing a data-structure which is slightly too low-level for common application cases.

This is a little ways out, but the actual facts Maniphest currently generates need to be adjusted to properly support stacked-area-by-reason: currently, when a task is closed, we don't have enough data to figure out whether it should be removed from the "created into this project" area, the "reopened work" area, or the "moved work" area. This is okay if we're summing the opens/closes but not precise enough if we're breaking them down.

Multiple Project Burnups Stacked in an Area Chart

See also PHI1226. An install has an environment where automatic rules (Herald/Owners) frequently trigger group reviewers (projects/packages), and some groups are not prompt about performing review.

I think a possible model for the UI is to have some base ChartConfigurationEngine, similar to SearchEngine, which defines a set of fields. Some fields would be common (e.g., all time-series charts can have time controls for domains).

The concrete use cases that are currently filed are:

hmmm

Wow thank you for this. I came across a diff that mixed a lot of whitespace with minimal code change it's much easier to differentiate what happened.

I believe there is very little reason for the "Autoclose" and "Publish" behaviors to actually be separate. That is, there are very few use cases where users want a commit to trigger only Herald or only feed or only audits. These use cases do exist (see T9210 for an example of "Herald, No Feed") but they're overwhelmingly niche and off-label.