Page MenuHomePhabricator

Implement a `current-milestone-of(project)` tokenizer function
Open, LowPublic

Description

We'd like to tag tasks with (effectively) sprints: Sprint 1, Sprint 2, etc. We'd like the home dashboard to show tasks tagged with the /latest/ sprint. Otherwise, we have to update the panel weekly to use a new search query.

Is there any way this can be implemented as a search?

Event Timeline

epriestley renamed this task from Query for latest milestone to Implement a `current-milestone-of(project)` tokenizer function.Jan 6 2017, 7:16 PM
epriestley added a subscriber: epriestley.

One concern I have with this is that the largest sequential milestone may not be the "current" milestone. If you're currently in Sprint 4, someone may reasonably create Sprint 5 before Sprint 4 concludes.

I suspect this might be so frequent that the query would effectively be useless, since like 40% of the time someone would already have created the next sprint sometime early on Thursday or whatever?

Some approaches I can come up with:

  1. Just trust that users will be disciplined about this.
  2. Introduce a formal "current milestone" concept, with a checkbox when creating a new milestone like "Make this the current milestone" and a new "Make Current Milestone" action to flag the current milestone.
  3. Add formal date ranges to milestones and use the current time to drive this query.
  4. Implement this as a ProfilePanel instead of a tokenizer function so we can provide "previous milestone / next milestone" links, possibly reducing the cost of errors to something negligible.
  5. Implement a fancy way for function tokens to provide related queries, so this can still be a tokenizer function but the query can populate with ("previous milestone" / "next milestone") action links to modify the function token.

I definitely don't trust (1).

I don't think this use case alone is strong enough to justify (2), but could imagine other use cases might.

I think (3) is a big swampy morass.

(4) is perfectly viable but better as an extension than something in the upstream.

(5) feels hugely complex, but perhaps there are like 10 other use cases that will turn up and can justify it.


We don't have a clear pathway forward so I don't expect to act here until we do. This can probably be implemented as an custom dashboard panel today without exceptional effort.