The Wikidata team relies on Scrumbugz, which will go away at the same time than Bugzilla. They will start a bi-weekly sprint without Scrumbugz on 24 Nov. If possible, we would like to have Sprint enabled in production by the time they start their next sprint on 8 Dec.

There seems to be an interest among some WMF teams in using Sprint as well.

What is the process here? We need a security review, I guess.

@Qgil, do you mean https://github.com/bluehawk/phabricator-sprint?

@csteipp no, that code has nothing to do with where we are now. please check it here: https://github.com/wikimedia/phabricator-extensions-Sprint

Please tag a local phabricator repo with arcpatch-D10780. Sprint 0.5.4 depends on this.

In T1322#23339, @Christopher wrote:

Please tag a local phabricator repo with arcpatch-D10780. Sprint 0.5.4 depends on this.

Hey Christopher.

I'm guessing you mean? https://secure.phabricator.com/D10780. So to include that outside of upstream we would need mukunda to patch his (already included outside of upstream) patch for the mediawiki auth provider. I'm not sure if that's worth the complication or not. Does this require arc liberate etc?

As a general rule I would prefer to keep our tagging related to issues TXXX or whatever. I have been doing this, and now we tried not doing it with the mwoauth tag and it's less useful and less tied into the overall process.

paging @mmodell

In T1322#23509, @chasemp wrote:

In T1322#23339, @Christopher wrote:

Please tag a local phabricator repo with arcpatch-D10780. Sprint 0.5.4 depends on this.

As a general rule I would prefer to keep our tagging related to issues TXXX or whatever. I have been doing this, and now we tried not doing it with the mwoauth tag and it's less useful and less tied into the overall process.

Not meant to confuse, I just meant let's keep our local tags related to our local issue numbers (this is not anything that anyone other than the phab team needs to do I think)

Third reply from me :)

Realized I'm confused and it creates new questions, https://secure.phabricator.com/D10780 is merged upstream now, why would we arc-patch it locally?

The protocol should be that the local repo is tagged with an upstream commit. The commit is D10780, and the tag should be "arcpatch-D10780".

Nothing more needs to be done as long as the local repo is a mirror from upstream, which does not appear to be the case currently. Puppet will always refresh from a tag, so there is no risk in having a fresh mirror, right?

Ok, thanks @Qgil and @Christopher for making it clear: this task is the best / fastest way for my team to implement Agile in Phabricator. That said, how can I help, what's stopping us from deploying Sprint?

@csteipp is extremely busy these days but he did the security review for this extension:

tl;dr, looks ok.

It looks like they need to do some cleanup (whitespace, dead code),
but their handling of the dangerous stuff looks ok.

@mmodell will have a look at the code as well.

As discussed previously, our intention is to have Sprint deployed within two weeks after the Bugzilla migration. We need to find a good spot to sync our Phabricator instance with upstream, which will allow the deployment of this extension.

There are a few things to do OPS side, but I am confused about the general state of this task. This task depends on T153: Burndown charts for Phabricator projects which in turn depends on T452: Create/enable custom "Story Points" field for tasks but that task is not closed. So it seems T153 should never have been resolved, and I don't know if T452 is actually a blocker?

From reading it seems maybe the blockers are just outdated, but I'm not entirely sure

Yes, sorry, outdated blocker removed. The Sprint extension has everything it needs to be deployed here. It brings its own story points.

OK cool -- side note -- should it be impossible to close a task with an open blocker?

Side reply -- I would not touch the current flexible behavior. Blockers are not scientific. :)

The roadmap says this is happening on Wednesday. I would highly recommend deploying the latest tag -- 0.6.0.7.
Please review it at https://phab08.wmflabs.org/sprint/

I will make the puppet manifest change patch on Monday if it is ok.

I am posting current known issues and bugs here: https://phab08.wmflabs.org/tag/sprint_extension_bugs/
In the meantime, if there is something urgent that you notice, let me know and I can try to fix it before deployment.

In T1322#823360, @Christopher wrote:

I am posting current known issues and bugs here: https://phab08.wmflabs.org/tag/sprint_extension_bugs/

Why not in a project here?

Deployment change is up for review here: https://gerrit.wikimedia.org/r/#/c/178194/

There were a few more recent commits including fixing crumbs and sort fields, so please note that the current tag is now 0.6.1.0.

Can someone define what these settings should be in production?

The same policies as we have for regular Projects and regular Maniphest here in production. The changes compared with the screenshot are:

• Default View policy: Public
• Can Create Projects: Project-Creators
• Can Edit Task Policies: same Custom policy as our Maniphest
• Batch Edits: Triagers

Sweet -- is there documentation for this extension? I don't see it on my current sprints, but I expect I have to turn it on...

There is https://www.mediawiki.org/wiki/Phabricator/Project_management#Sprints -- there you will find what to do to activate it in your next sprints.

The graph rendering is pretty slow (~10 seconds to open a graph) -- not a
blocker but it would be nice to make faster.

This task is closed. Could you create a new task under Phabricator-Sprint-Extension, please? This is the best way not to forget about it.

done -- thanks Grace