I'm interested in joining (lurking) too.

Lurking also. I've talked a bit with Arthur about the assumptions underlying burndown charts, and I don't think we've exhausted the subject.

Another lurker :)

@Christopher we'd really like to chat about the future of the sprint extension and see where/how we can help shape and support ongoing refinements/maintenance. Can you share some times when you might be available to set up a video chat?

@Awjrichards
I am reluctant to commit to anything at the moment because my current working situation with WMDE is rather tenuous (my contract ends next week). I am also stretched with securing a PhD research position, moving from Berlin, and the completion a non-Wikimedia related contract development project.

The development of the Sprint extension was initiated to support WMDE, and particular WIkidata, in the absence of Scrumbugz. I have to be honest and say that it has turned out to be a much more involved affair than what was originally intended. I would be the first one to criticize the development methodology behind the implementation, which is basically a third-party hack into Phabricator. At this level, it is not supported by Phacility and building an project management paradigm on an unsupported application is probably not ideal.

This is not to say that it does not have potential to become something more than a hack. As it exists now, Sprint is a dynamic reporting tool that provides several useful enhancements over the default Phabricator projects application. These enhancements are bound to Agile project methods that use "boards" and "points" to evaluate and estimate development workflow over time. The primary design intention was to facilitate the use of Agile in Phabricator. And, this has been achieved. However, in my opinion, for long term support, the best solution for Sprint is to promote its integration into upstream. I think that this is entirely possible. With the help of expert coders, it could really become valuable not only to the Foundation, but to a wider user base.

I will continue to respond to emails about issues and questions as time permits, but again, I am stretched very thin at the moment.

Wow, I see. Well, let's discuss. The extension works today, and considering your situation I think you can follow the approach taken by the Wikimedia Phabricator team, being very conservative about introducing new features that come with maintenance costs and an unclear path to upstream.

Ref T90906, let me say that our invitation to Lyon (travel expenses included) is not tied to your involvement with WMDE or whatever situation you are at now or in the future. Your work on the Sprint extension has been stellar and, as you can see, very important to many teams. We want to recognize your role and your effort with an invitation to the Wikimedia Hackathon.

@Christopher, thanks so much for your reply - and particularly for all of your hard work on the sprint extension :)

The sprint extension seems to be an awesome starting point and indeed many have found a lot of value in the tool as it currently exists. I'd really like to figure out how to continue evolving the sprint extension to fully meet the needs of WMF engineering teams and their stakeholders (at the very least). I think the Wikimedia hackathon (T90906) could be an awesome opportunity for deep knowledge sharing of the sprint extension as well as an opportunity to start prioritizing enhancements and getting a sense of how we can begin implementing them. I realize these are things we can potentially do remotely, but particular given @Christopher's schedule and the high bandwidth we can achieve in person, I think we could get an awful lot out of doing this in person.

Do we already know whether Phacility has any interest in this becoming part of upstream Phabricator? @Lydia_Pintscher , @Abraham -- where is WMDE on this?

@chasemp reached out to me about upstream interest -- short answer is we're definitely interested in building the featureset (at least, approximately), but not interested in bringing the extension itself upstream.

The way the extension is implemented is great for getting the job done, but it overcomes cases where integration points are missing by using a lot of force. We think we'd be farther from the end goal of a long-term maintainable implementation by starting with it, since the first step would roughly be tearing it down brick-by-brick to give us a clean foundation that we could start building on. We anticipate a shorter path by starting without any technical debt to clean up.

As a specific illustrative example, the priorities that WMF uses are hardcoded in the extension:

https://github.com/wikimedia/phabricator-extensions-Sprint/commit/ab8acd40ff05152deb7baf8f2f8d26165bbc2e89

Obviously, this particular case is easy to fix, but it's characteristic of the results-oriented approach of the extension -- which is very effective in implementing charts, as the upstream has produced zero charts in the same period of time -- but less concerned with generality and low maintenance costs in the long term. In the upstream, we have to hold these considerations paramount, and we'd have to begin by unraveling and generalizing all the concepts that the extension introduces before we could move forward. Plus, we'd inherit the burden of maintaining backward compatibility.

The maybe-good news is that Phacility is now launched, which should free up more room in our product pipeline, assuming it doesn't spend too much time burning to the ground. However, Conpherence (messaging) is the next major product on our roadmap. I suspect the next Projects iteration is not far behind that, but it's hard to say how not-far it is.

What @epriestley says is reasonable and is the expected response to the inquiry.

The featureset of Sprint is what is valuable. The main features (at the moment) are graphical real-time reporting of board activity, the ability to define duration and metric value scope for a project, creating a unique project type with a project profile field option, allowing the retrieval of a list of typed projects, enabling maniphest task fields and custom board views based on project type association, tabular, sortable, filterable and paginated query result sets, showing blocked and blocker labels in a query set, and customized workboard cards. Promoting the integration of these features would ensure the sustainability of this functionality in the long term. This is what I suggested, and seems to have been misinterpreted somewhat.

It clearly does not make sense for upstream to merge the Sprint extension code base as an application, primarily because it works around and reimplements several key classes (by necessity) rather than modifying them directly, which is something that they would need to do. And I also agree with @epriestley in that it was designed for the specific use case of WMF agile burndown charts, and is not general enough for broad scale distribution.

Additionally, the comparative maintenance costs of developing the Sprint extension downstream seem lower than having them merge it (as is) into Phabricator main. As upstream is able to introduce Sprint-like functionality and features, these costs will become even lower. The benefit of having the ability to readily integrate "essential" prototype Phabricator features is essentially what the Sprint extension brings to the table, and this is definitely an asset and a rationale for keeping it as part of the WMF installation at any rate.

@Eloquence we are currently discussing how much time and effort we can provide. I will have a better overview about that in April. Nevertheless, I'm looking forward to discuss with all of you how we can take out the best for all of us and how to proceed best on this topic. Yes, we will meet at the Hackathon in Lyon too.

@epriestley are you (or anyone else from Phacility) planning to join us at the upcoming Wikimedia hackathon? We're planning to spend time discussing the sprint extension, possible improvements (the scope of which would certainly be influenced by Phacility's plans for implementing similar behavior), etc (T90906).

@Christopher, still haven't heard from you - any idea yet if you will be in Lyon?

Hi all,

as discussed on our last call (with @Awjrichards and team), we need to have phragile "up and running" by the start of the hackathon to discuss and address future requirements and user stories in details. Therefore, we have been in contact with the team "Team practices" and decided together to poke you @greg and @chasemp to help us out with the following that we can deploy phragile on a labs instance and to set it up to use real phabricator data:

The OAuth Server Application has to be activated in Phabricator. Once activated Phragile needs to be registered as an OAuth application. There are two fields to fill out when creating a new OAuth application. "Name" should be "Phragile" and "Redirect URL" should be "http://our-phragile-domain/login" (we don't know yet what the domain will be but it can be changed later on anyway). This will generate an OAuth Client ID and an OAuth Client Secret which Phragile needs in order for the OAuth login mechanism to work.

Thanks,
Abraham

@Abraham, first I think that "Phragile up and running in a Labs instance" should be a task on its own blocking this one.

Then, I also think that you should be able to do all this by yourselves, since it's a Labs instance and you have all the means to complete the task. Chase is in paternity quas-leave these days, Greg and most of his team is about to fly to Europe for the Hackathon & their team offsite. You might get some help from them, but I would not rely on that.

@Qgil the setup and installation in the labs instance will be done by ourself. As described and discussed in our call we need ops support for:

"The OAuth Server Application has to be activated in Phabricator. Once activated Phragile needs to be registered as an OAuth application. There are two fields to fill out when creating a new OAuth application. "Name" should be "Phragile" and "Redirect URL" should be "http://our-phragile-domain/login" (we don't know yet what the domain will be but it can be changed later on anyway). This will generate an OAuth Client ID and an OAuth Client Secret which Phragile needs in order for the OAuth login mechanism to work."

Thanks.

Alright, then please create a new task for this, and associate it to SRE.

I am going to mark this task as resolved since we've had a variety of productive conversations, particularly at the Lyon hackathon, with the relevant folks.