qgil wrote on 2014-04-30 15:35:02 (UTC)

I asked upstream, if only to know their opinion.

qgil wrote on 2014-05-06 01:13:05 (UTC)

Probably a simpler option is to create a Phabricator backend for Scrumbugz. The interaction between Scrumbugz and Bugzilla is pretty simple, and its tables and graphics seem to be effective to organize the scrum process. It is written in Python. The Wikidata team seems to be happy with it.

If someone wants to check the project and Phabricator's Conduit API...

aklapper wrote on 2014-05-13 08:57:53 (UTC)

@chjohnson: We need input here especially from the Wikidata team which uses Scrumbugz:
Could you imagine to adapt to Phabricator's UI in Burnup Rate and Fact?
If you think it is not sufficient, would a number of custom changes (which ones?) to Phab's Burnup Rate functionality help you, in order to not reinvent the wheel with a separate Burndown functionality?

And if that's all not feasible, the last option would be connecting Scrumbugz to Phabricator, as pointed out by Quim already.

In any case, we need to agree on a way forward here.

chjohnson wrote on 2014-05-13 12:28:11 (UTC)

Implementing a new Agile application in Phabricator is the way forward. Adapting Scrumbugz to work with Phabricator is working in the wrong direction. The way that I see it, an full-blown Agile application to match Scrumbugz would require several features beyond the rather rudimentary "Burn Rate" report. The PHP code for the "Burn Rate" report is pretty bad actually. https://scrutinizer-ci.com/g/ChristopherHJohnson/phabricator/code-structure/master/class/%2Bglobal%5CManiphestReportController and I do not consider it entirely reusable.

A new app would include the ability to create sprints, assign tasks to a sprint and move in-progress/incomplete tasks to a new sprint. It would reflect granular statuses including assigned, patch to review, resolved, verified and all of the additional custom fields that should be part of the Bugzilla migration anyway. It would define task flags that identify tasks as part of the current sprint, in the ready backlog, or in the backlog. It would show burndown graphs of the current sprint and previous sprints, with archive snapshots. And, it would extend the current point assignment field of the tasks with tabular metric analysis.

qgil wrote on 2014-05-13 12:58:15 (UTC)

Many of these points must be discussed at T166: Prohibit editing of initial description in tasks. Let's focus on the burndown chart functionality here, assuming that we will start working with projects as they are today. Let's assume we have the "Wikidata Sprint 2" project, which follows "Wiidata Sprint 1" and precedes "Wikidata Sprint 3".

I wonder whether @Swidmann would be interested on this task. If so, the next step would be to sync with upstream, something that I can help with.

Swidmann wrote on 2014-05-14 11:39:09 (UTC)

@Qgil: Yes, I'm interested in this task, i just assigned this to me if this is for everyone ok

qgil wrote on 2014-05-14 13:56:17 (UTC)

@Swidmann, this is great news! I'm going to ask the Phabricator maintainers how they want to proceed. Please register at http://secure.phabricator.com

Swidmann wrote on 2014-05-14 14:43:09 (UTC)

@Qgil "Swidmann" registered as "Swidmann" at http://secure.phabricator.com

qgil wrote on 2014-07-22 20:10:06 (UTC)

Just a note: there is som progress at https://secure.phabricator.com/T5051 and @Swidmann has gone a little further, as commented here.

qgil wrote on 2014-08-13 12:48:15 (UTC)

Another contributor has worked on https://github.com/bluehawk/phabricator-sprint. It is supposed to be a prototype that works. any venturous tester / team willing to give it a try?

tobijat wrote on 2014-09-08 12:11:18 (UTC)

@Qgil will there be one of the tools mentioned here available when wikimedia's phabricator get's live and bugzilla goes into read-only? Because if not, our team (Wikibase/Wikidata) loses the possibility to manage sprints based on tasks/bugs defined in bugzilla/phabricator. Basically, our main requirements (currently covered nicely by Bugzilla and Scrumbugz) are:

• define sprints
• define timeframe for sprints (start data / end date)
• define story points for tasks
• add tasks to sprints
• remove tasks from sprints
• see total number of story points per sprint
• see remaining number of story points per sprint
• see burndown chart
  • for a given timeframe (e.g. sprint)
  • see how many points have been closed on a specific day
  • see a line for the “ideal” burndown
  • see burndown charts of past sprints (to compare and evaluate)

I've found T244 and https://secure.phabricator.com/T5051 but I was not able to find any concrete plans how much of this functionality will be available by the time Bugzilla will be closed down. Any hints on that?

qgil wrote on 2014-09-08 12:49:40 (UTC)

Hi @tobijat, according to the current plan, the only functionality available by Day 1 is what Maniphest provides out of the box: you can create projects for sprints, and assign tasks to those projects. Definition of dates, calculation of story points, and charts will not be supported.

Now, how can we improve this plan? One possibility:

• The teams needing this functionality could start working on this. Maybe here in Labs (as soon as the non-testing content is migrated to Wikimedia Phabricator, planned for this week) or in a test installation somewhere.
• You could try https://github.com/bluehawk/phabricator-sprint and see whether it fits your needs or not yet.
• Perhaps you could get help from @mmodell (now CCed) as soon as he is done with his Day 1 tasks? For what is worth, he works in a team that (afaik) needs this functionality as well. Maybe @Swidmann can help as well (ping?)

@mmodell and @Rush would be the gatekeepers of this new feature. As soon as you think it's ready, and as soon as they think it's ready, it could be installed in Wikimedia Phabricator.

Looking at the state of things, it looks like you are going to be able to finish your sprints in September, and it looks like the tool could be ready for the November sprints latest. Having it ready for October looks a bit challenging, but maybe feasible if you coordinate efforts?

aklapper wrote on 2014-09-08 16:14:52 (UTC)

For the records, in an email the Wikidata team expressed interest in playing with https://github.com/bluehawk/phabricator-sprint on a Labs instance to evaluate it. (Thanks for giving that a shot!) If it fits the needs we could potentially deploy that extension in the Phabricator production instance, at some point after migrating the Bugzilla content.

I can imagine that WMF's Analytics team might also be interested in this.

The Wikidata team has installed Burndown in http://phab.wmflabs.org/burndown/view/1/ (seems to have problems loading right now)

We are discussing the path of testing and installation in production in this thread: https://lists.wikimedia.org/pipermail/wikitech-l/2014-September/078676.html

In T153#4921, @Qgil wrote:

The Wikidata team has installed Burndown in http://phab.wmflabs.org/burndown/view/1/ (seems to have problems loading right now)

For what is worth, I still haven't been able to load it.

I just found http://git.wikimedia.org/summary/?r=phabricator/extensions/BurnDownCharts.git , which at least can serve as recipient.

The burndown aka "Sprint" library extension is progressing steadily. The new repo (with a license file) is on gerrit in https://gerrit.wikimedia.org/r/#/admin/projects/phabricator/extensions/Sprint

I have been working with ops/puppet and the installation patch is basically ready to be merged. It is abstracted so that it can be enabled on the main role very easily. We are currently enabling it only on labs.

I am also in the process of making changes to meet the requirements of our team, so we will want to wait to implement it in production until we can fully test it first.
I just now added a bit of code to enable the Public policy to the Sprint burndown chart.

Joe Q Public should now be able to see it here: https://phab08.wmflabs.org/burndown/view/1/

The puppet mods for Sprint were merged so it can now be viewed and tested on https://phab-01.wmflabs.org. I am getting familiar with Phabricator internals and have some ideas for enhancing and fixing what we have now. The implementation is constrained by needing custom fields in both Projects and Maniphest. The storage interfaces are separate for each application and making single view mash-ups is not very straightforward.

Another problem is the google jsapi implementation for the charts. Using a local js library, like Raphael or Flot, loaded with celerity would be better. If the goal is to make it look and feel like Scrumbugz, it needs more js.. https://secure.phabricator.com/book/phabcontrib/article/adding_new_css_and_js/ explains how to merge new js libs from the CLI.

In T153#8447, @Christopher wrote:

Another problem is the google jsapi implementation for the charts. Using a local js library, like Raphael or Flot, loaded with celerity would be better.

Yes, that sounds like a blocker for production from both a licensing (Google Charts does not seem to be open source) and privacy standpoint.

Maybe one of the Analytics team's visualization tools could be helpful here.

In T153#13719, @Mattflaschen wrote:

Yes, that sounds like a blocker for production from both a licensing (Google Charts does not seem to be open source) and privacy standpoint.

Ouch.

The blocker with the google charts is resolved. See changes here https://gerrit.wikimedia.org/r/#/c/168824/
I decided to use D3 for the chart library and a wrapper called C3. Both are loaded with celerity and configured with javelin.
The implementation is still not complete, but I think that the first result is satisfactory and not that different from the Google Chart.

You can see the first iteration here; https://phab08.wmflabs.org/sprint/view/4/

The new js libraries should be put under the phabricator/webroot/rsrc/externals/sprint directory and then "/bin/celerity map" should be run. I guess this should go in a new phabricator branch?

Progress report on having extensions load their own resources outside of webroot. It is possible. There are two very minor changes that have to be made upstream to fix a hard code source_name argument for Javelin initBehavior, and I pointed this out to epriestly here https://secure.phabricator.com/T6422. Also, in order to generate the map with "celerity map", the library needs to be loaded in the scripts/__init_script__.php

Reference https://gerrit.wikimedia.org/r/#/c/170018/

Added patch upstream https://secure.phabricator.com/D10780 for allowing library sourced Javelin behaviors.

https://secure.phabricator.com/T6467 is resolved. Patch was merged.

Next task is to have operations merge the update tag script that allows library versioned deployment from puppet.

Comment relating to upstream pull tag references for the phabricator/phabricator repo. Currently, the tag is "wmoauth" that references arcpatch-D9203. In order for Sprint to be synched with the upstream commit that enables the locally sourced resources, a new tag should be created that references arcpatch-D10780. This tag then has to be referenced in the phabricator role along with a new tag for the Sprint extension. The phab_update_tag script change is done, so pushes to Sprint are now possible after the new tags are added and the role manifest is merged into operations/puppet. The Sprint tag will be "0.5.4".

In T153#15599, @Christopher wrote:

You can see the first iteration here; https://phab08.wmflabs.org/sprint/view/4/

That looks great. I look forward to using it for real.

@Christopher, since you are requesting T1322: Deploy Phabricator Sprint Extension in Production, I guess we can close this task as Resolved?

While the Sprint app is deployed in production, users can test it in https://phab08.wmflabs.org/sprint/report/