Page MenuHomePhabricator

Figure out the UI for Maniphest task search by points
Open, Needs TriagePublic

Description

We added points in T4427, but I haven't written search for it yet since I'm not sure what the UI should look like. Use cases so far:

  1. (Hypothetical?) Show tasks with no point value; I want to estimate un-estimated tasks.
  2. (Probably actual?) Show tasks with 4 points; I want see review how well we're estimating point values.

UI junk we could possibly use:

Points: ( Show tasks with and without points / show only tasks without points / show only tasks with points )
Points: Between [___] and [___]
Points: Between [___] and [___] ; [X] Show tasks with no points
Points: [1, 17, 35-36, >400, null]

Event Timeline

My real-world use cases (based on the Phragile extension, before this existed):

  • Show me tasks with points explicitly set to zero (external dependencies), so I can chase
  • Show me tasks with points set to some value (e.g. ultra-epic), so I can re-cut my roadmap around them
  • Show me tasks with points set to more than [X], so I can make sure we do hard tasks earlier [Not met by Phragile, would be nice]
  • Show me tasks with points unset so I can estimate them [Not met by Phragile, would be fantastic]

Thanks, that's helpful. That's pretty much what I figured, and it's reassuring that no one has come up with "exactly 3, 5, or 11 points" use cases, or use cases that require a mixture of inclusive and exclusive ranges, at least so far.

I suppose that typing Points between [2] and [3.9999999999] is probably an acceptable workaround for expressing the range [2, 4) if anyone does come up with a use case that requires exclusive ranges.

Oh, forgot the implicit equivalent of use-case #3:

Show me tasks with points set to fewer than [X], so I can give newbies some easier tasks now [Not met by Phragile, would be nice]

We've been using our own custom points field for a couple years now. Is there/could there be a plan to ease migration to the new formalized points system? (a bin script would be fine).

I'll lump that into T10350.

I'm leaning toward this:

Points: [____] to [_____] · [ ] No Value Assigned

This can express all the queries:

Show tasks with no point value set
Show me tasks with points unset so I can estimate them
Points: [_] to [_] · [X] No Value Assigned

Show tasks with 4 points
Show me tasks with points set to some value (e.g. ultra-epic)
Points: [4] to [4] · [ ] No Value Assigned

Show me tasks with points explicitly set to zero
Points: [0] to [0] · [ ] No Value Assigned

Show me tasks with points set to more than [X]
Points: [99] to [ ] · [ ] No Value Assigned

My concern with this control is that I don't think these use cases are necessarily obvious or follow from the other ones:

Show me all tasks
Points: [_] to [_] · [ ] No Value Assigned

Show me tasks with any point value assigned (but not unassigned tasks)
Points: [0] to [_] · [ ] No Value Assigned

The "all tasks" will probably be obvious-ish because that's how stuff works by default, and maybe we can just document the other one.

The phrasing on "No Value Assigned" may also not be great.

And this doesn't translate super nicely into JSON for the API.

This comment was removed by josetesan.

Here is an example of a report that is satisfying several use cases from the comment above, https://secure.phabricator.com/T10339#159098. Those use cases, fleshed out a bit, include:

As a Product Manager, I want to see all tasks with points unset so I can estimate them.

As a Product Manager, I want to see all tasks with points unset so I can identify tasks that have not followed the standard workflow to enter the backlog.

As a Product Manager, I want to see all tasks with points unset, but exclude tasks that haven't changed in a long time, so that I can triage recent unpointed tasks but not reconsider tasks from an earlier time period that may be "legitimately" unpointed.