By this, I mean that the type should probably be "user" or "project" or whatever (not just "phid"), so we can accept @alice instead of PHID-USER-abcd. But I'm not yet sure how low-level the user-facing stuff is going to be.

This is a little crude for now. The x.y.z.project and x.y.z.owner facts are facts about tasks tagged with projects and assigned to users, and have an object dimension value for which project/owner was tagged/assigned.

For example, if a task is created with alice as an owner, we'll get a row like:

2019-04-30 11:23:45 • tasks.count.create.owner • PHID-TASK-abcd • PHID-USER-alice • +1

..meaning "one task, PHID-TASK-abcd, was created on April 30th with alice as the owner".

So this code is saying "when you chart an owner/project fact, you should specify the PHID of the owner/project you care about", and the rest of the changes here are adding the right WHERE clause for that.

We count two types of events for open tasks:

• *.create is when a new task is created into an open status.
• *.status is when a task is changed from a closed status into an open status (or a negative value, when an open task is closed).

To get the overall open task count for an install, we have to combine these. However, in other views, we might care about reopened tasks separately (e.g., how much of our timeline slippage is due to making mistakes and needing to rework things?), which is why they're tracked separately.

Likewise, above, we count three types of events for project tasks:

• *.create is when a task is created with a project already tagged.
• *.status is when a closed task is reopened (or closed).
• *.assign is when a tag is added or removed.

To show an overall chart, we add these together. In other views, we might care about rework or new scope to help us understand timelines.