I tried two sprint libs today, https://github.com/bluehawk/phabricator-sprint and https://github.com/wikimedia/phabricator-extensions-Sprint, both facing the problem:

>>> UNRECOVERABLE FATAL ERROR <<<

Call to undefined method ManiphestTaskQuery::withAnyProjects()

/opt/phacility/extensions/Sprint/src/query/SprintQuery.php:75


┻━┻ ︵ ¯\_(ツ)_/¯ ︵ ┻━┻

@calfzhou see D12526, and then https://gerrit.wikimedia.org/r/#/c/207415/3/src/view/reports/SprintReportOpenTasksView.php as an example to how to fix it.

@calfzhou @g-p-g I have an open pull request for this patch on bluehawk/phabricator-sprint: https://github.com/bluehawk/phabricator-sprint/pull/11

@dpaola2: Your issue should have been fixed just recently.

thanks @g-p-g and @dpaola2, all those fixes work!

Anyone still actively working on getting this merged into master?

This looks great and I want to use it!

I have installed it and can see Sprint Start Date and Sprint End Date in my project details.

I am getting Call to undefined method ManiphestTaskQuery::needProjectPHIDs() when I try to view a task.

I've raised this at https://github.com/bluehawk/phabricator-sprint/issues/13

Is anyone else getting this issue?

I am as well. Using https://github.com/bluehawk/phabricator-sprint master at commit a5decfe154427e6edb822f29f4d08427cc6e3a60

>>> UNRECOVERABLE FATAL ERROR <<<

Call to undefined method PhabricatorProjectQuery::withDatasourceQuery()

/home/bitnami/phabricator-sprint/src/BurndownListController.php:19


┻━┻ ︵ ¯\_(ツ)_/¯ ︵ ┻━┻

The upstream will not help you resolve issues with third-party extensions (see T5447). You need to report these issues to the extension maintainer, not here in the upstream.

@dancunningham @readevalprint Also (and as a reference for anyone else
landing on this page), the actual upstream is at
https://github.com/wikimedia/phabricator-extensions-Sprint - which does
work with current Phabricator. But please do take issues up with them.

Right, thank you!

I am also facing same problem but there is no errors shown in my installation.

I had seen this https://gerrit.wikimedia.org/r/#/c/207415/3/src/view/reports/SprintReportOpenTasksView.php can see its already implemented in my code. Looks like my code is having this patch since day 1.

Anyone having information about main problem/ root cause of all this?

See T5051#137287. This ticket is not a general support place for questions about other existing 3rd party extensions.

This task has morphed a bit, so clarifying the current intent. If you're interested in Sprint/Milestone support, which is actively being built, please follow T9378, T3670.

This task will be re-scoped to just being about burn down charts for milestones.

In T5051#156552, @chad wrote:

...
This task will be re-scoped to just being about burn down charts for milestones.

Since the number of subscribers and tokens, and number of stars of the mediawiki extension on github, seems this graph will be of very much interest for a lot of people if incorporated in the core.

And I fully agree with qgil:

In T5051#58942, @qgil wrote:

...
Personally I find "This project is 3 days behind schedule." more interesting. "70% complete" can be good news or bad news, depending of the point of time.

In the graph you can estimate schedule more than actual implementation that show points completed over total.

Here are some additional use cases and a sample implementation that is a Burn-up chart, not a Burndown chart, plus rationale.

Use Cases

• As a Product Manager, I want to understand if a project is likely to meet a deadline, so that I can take action (such as reducing scope, reprioritizing work, or changing staffing).
• As a Product Manager, I want to differentiate between the two factors affecting a project burnup, changes to scope of work vs velocity of completion, so that I can more accurately decide which actions to take.
• As a Product Manager, I want to understand if a project is likely to meet a deadline, so that I can decide whether to make a public announcement, or when or what.

Sample Implementation

• Primarily, it shows two different pieces of information, total scope of work and total amount of work completed. These are conflated in a burndown chart, so that “more work was added to the scope” looks the same as “a bunch of work previously thought completed was found not to be completed”, and “no work is being completed” looks the same as “lots of work is being completed but new work is being added at the same rate”.
• In the burndown example in the Feature Request Description above, Completed is shown as a separate series, but identifying scope changes is still not practical: either the Actual line is allowed to jump up and down, forcing the user to back out scope changes from progress by subtracting an instantaneous value from a cumulative value (much harder than comparing two slopes visually), and also introducing the nonsensical possibility of Actual work Remaining dropping below the X axis; or, as was implemented in Phragile, the Actual work changes retroactively whenever scope changes, so scope change information is not present in the graph.
• Burnup charts allow for a much more natural presentation of forecasting, by comparing the slopes of the two lines and looking for an interception point. This can even by done by eyeball, without any calculated forecast data.