Please see T90489 for my comments.

There are indeed a lot of possibilities for developing this tool. The lack of distinction between "real time reporting" and "estimated projection" seems to make burndown charts like the Rubik cube of applications. Reconciling these two different concepts on a single chart has more than a few functional challenges.

I personally think that the concept of "an ideal points" line for projections should have a more elaborate algorithm. Consideration of the future integration of Differential will offer the ability to track "Review" with analytics. An additional line (or another chart) could be created that is "Remaining - Review" over time that reflects the difference between open tasks points and task points in review. Also tracking (average?) review duration could facilitate estimating float in calculating the ideal points line. I think Review is where a lot of new ideas and estimating innovations could be developed.

Introducing a history schema would also allow lookup functions on previously recorded transactions. Week to week, or day to day, performance comparisons for example. Sprint has no internal tracking and this is kind of unusual for a statistical application.

It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

I think our focus really needs to be on getting the necessary functionality either upstreamed, or packaged in a form that is resilient to upstream changes. We shouldn't add more features to the existing Sprint Extension unless/until we have a long-term plan for its maintenance and integration. (If we have such a plan, then I apologize and would appreciate a pointer to it.)

Perhaps removing features would actually help. For example, maybe charting could be better handled by a separate extension, or external tool (like Phragile).

I see clearly the concern about the issue of long-term maintenance of the Sprint Extension as this remains my sole responsibility at the present time. My recommendation is the same as I expressed in T90489. Necessary features should be part of upstream. Phragile is also an option. Removal of the Sprint extension is very simple. Dissecting it one bit at a time is not helpful and would create more issues than it would solve. Furthermore, the critical Phabricator dependencies of the Sprint extension are backend and UI related and have less to do with the feature set or the JS graphing. I agree that the collective goal should be to find alternative methods/solutions to provide the functionality of the Sprint extension because it is practically unsustainable without dedicated WMF developer support.

I would like to come up with a plan for upstreaming the necessary parts of the Sprint Extension, and perhaps replacing other parts (like graphing) with other tools (perhaps phragile). Also, there may be necessary features that upstream won't take, in which case I would like to keep them in the form of the simplest possible custom extension, to minimize maintenance costs.

To do that, I need to understand what all the parts are. Then, for each part, we could agree on a plan of action. Trying to deal with the entire extension as a whole seems too difficult. I don't know if this is the best forum for this discussion, but we can continue here unless/until a better place is proposed.

@Christopher I know you listed the features in a comment in another thread:

1. graphical real-time reporting of board activity,
2. the ability to define duration and metric value scope for a project,
3. creating a unique project type with a project profile field option,
4. allowing the retrieval of a list of typed projects,
5. enabling maniphest task fields and custom board views based on project type association,
6. tabular, sortable, filterable and paginated query result sets, showing blocked and blocker labels in a query set,
7. customized workboard cards.

My hope is that #1 can be shifted to an external tool like phragile, and thus removed from the Sprint Extension.

#2 is clearly valuable, and I think #5 and #7 are also closely related to it and to each other, and are important. I'm not sure of the value of #3, so I need to understand what that really means.

I don't understand #4 or #6 at all. If they are related to blockers and not to sprints/story points, then I would find it simpler to deal with them separately. Perhaps they could be split into a separate extension, or maybe they could be upstreamed before or after the sprint/story-point features?

Did someone work on this project during Wikimedia-Hackathon-2015? If so, please update the task with the results. If not, please remove the label.

See https://gerrit.wikimedia.org/r/#/c/219146/

I think that providing configuration options is a step in the right direction. Basically, it allows almost everything in the Sprint extension to be disabled with options that can be set by an administrator within Phabricator. If something is broken and not detected in testing, rather than impede functionality for the whole Phabricator instance, the problem can be isolated by disabling the specific feature.

The good thing is that the extension code is already quite modular, so no radical decoupling was required.

with the Projects v3 update, some clarity has finally been achieved regarding how upstream will implement the sprint extension functionality.

My long-term goal remains to dissolve (as much as possible) everything from the sprint extension into upstream (or Phragile). I therefore will change the name of this task to "deprecate the sprint extension" which I think is cohesive with the discussion here.

Are you sure that they will create a sprint application or extension soon? Looks like they finished with projects.

@Luke081515 Reporting seems a low upstream priority, so "soon", I doubt... See https://secure.phabricator.com/T4171 and https://secure.phabricator.com/T1562 I assume that eventually they will provide an interface for reporting that should include charts, etc.

Hi guys, I was just curious what the status of the extension was. We're using it at my company but it has some bugs and it seems like there hasn't been any new development in a while. Are there any plans to fix any of the issues or is the goal still to spin this into the upstream?

Obviously we appreciate all the work that's already gone into it and know this is a volunteer thing. Just trying to get an idea of how much we should be expecting to be fixed on this in the near future.

In T90906#3779259, @Rbalik wrote:

Hi guys, I was just curious what the status of the extension was.

The Phabricator Sprint extension is unmaintained (which is mentioned in the project description).

Are there any plans to fix any of the issues or is the goal still to spin this into the upstream?

Neither nor, I'm afraid. :)

Hmm darn. Do you know if anyone has forked it or anything or there are any similar plugins out there? Does WMF still use this extension for managing sprints?

@Rbalik We have the extension installed on this instance of Phabricator and I believe some teams still use it. More people, it seems, have moved to using Phlogiston (https://github.com/wikimedia/phlogiston) for burnup charts and the upstream has added a story points field so the extension is no longer required in order to assign points to tasks.

I'm a little confused as to the status of this and related projects. I just set up Phragile to discover that it doesn't add any value to what the sprint extension already provides (Or did I miss something?) and looking at this thread it seems that both the Phabricator-Sprint-Extension and Phragile have been deprecated in favor of Phlogiston ?

Just mentioning this here since it came up on our internal support channel: the Sprint extension encounters a fatal exception on upstream release 2018 Week 33 or later because it references policy constants which were marked for removal in December 2015 and finally removed in the most recent release.

I believe these references are a mistake and not used by the extension, and suspect that this patch fixes the fatal with no other effects:

diff --git a/src/application/SprintApplication.php b/src/application/SprintApplication.php
index 7d429f2..b9b483c 100644
--- a/src/application/SprintApplication.php
+++ b/src/application/SprintApplication.php
@@ -41,28 +41,4 @@ final class SprintApplication extends PhabricatorApplication {
       );
     }
 
-  protected function getCustomCapabilities() {
-    return array(
-        SprintDefaultViewCapability::CAPABILITY => array(
-            'caption' => pht(
-                'Default view policy for newly created sprints.'),
-        ),
-        ProjectCreateProjectsCapability::CAPABILITY => array(),
-        ProjectCanLockProjectsCapability::CAPABILITY => array(
-            'default' => PhabricatorPolicies::POLICY_ADMIN,
-        ),
-        ManiphestDefaultViewCapability::CAPABILITY => array(
-            'caption' => pht('Default view policy for newly created tasks.'),
-        ),
-        ManiphestDefaultEditCapability::CAPABILITY => array(
-            'caption' => pht('Default edit policy for newly created tasks.'),
-        ),
-        ManiphestEditStatusCapability::CAPABILITY => array(),
-        ManiphestEditAssignCapability::CAPABILITY => array(),
-        ManiphestEditPoliciesCapability::CAPABILITY => array(),
-        ManiphestEditPriorityCapability::CAPABILITY => array(),
-        ManiphestEditProjectsCapability::CAPABILITY => array(),
-        ManiphestBulkEditCapability::CAPABILITY => array(),
-    );
-  }
 }

A more complete patch would probably also remove SprintDefaultViewCapability.php, which seems unused now and when it was introduced.

If no action is taken, upgrading to 2018 Week 33 or newer will likely fatal the entire install.

Thanks @epriestley, I'll get it patched.

Simply removing the entire function leads to the following exception when entering the Sprint application

I think at a minimum it needs

protected function getCustomCapabilities() {

  return array(
    ProjectCreateProjectsCapability::CAPABILITY => array(),
  );
}

Several callsites are testing for ProjectCreateProjectsCapability on the SprintApplication. This is probably not what was intended.

The current behavior is to define two different "Can Create Projects" capabilities, one in the Sprint application and one in the Projects application. These capabilities have the same name, but may have different settings.

Some of the tests that the Sprint application makes against the "(Sprint) Can Create Projects" capability seem unusual. It is sometimes required to create projects via the Sprint application (so a user might be able to create projects via Sprint or via Projects, but possibly not via both, depending on the setting) and sometimes required for seemingly unrelated things (like calling sprint.gettaskprojecthistory).

More likely, at least some of these tests should be against the Projects application, not the Sprint application, e.g.:

PhabricatorPolicyFilter::requireCapability(
  $viewer,
  new PhabricatorProjectApplication(),
  ProjectCreateProjectsCapability::CAPABILITY);

The change @mydeveloperday proposes above is probably sufficient, but will leave the application defining a confusing duplicate capability.