fab.wmflabs.org had field for agile points that was removed at T64#39 in order to offer the simplest UI for new/casual users -- and also because the current need for it wasn't very clear. Some teams seem to want them back.
When @Qgil was playing with permissions, he wasn't able to make this field visible only to members of the acl*Batch-Editors group, just like the rest of fields for power users. We need to investigate whether this is a limitation of Phabricator and, if so, report it upstream.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Qgil | T824 Phabricator as Wikimedia software project management tool | |||
| Resolved | Qgil | T825 Goal: The majority of WMF developer teams and sprints have moved to Phabricator | |||
| Resolved | • Gilles | T827 Migration of Multimedia to Phabricator | |||
| Resolved | • chasemp | T37 Migrate Mingle data to Phabricator | |||
| Resolved | None | T803 Show task Story Points sums in workboards | |||
| Declined | Qgil | T452 Create/enable custom "Story Points" field for tasks | |||
| Resolved | • chasemp | T199 Import non-test projects from fab.wmflabs.org to the official Wikimedia Phabricator |
qgil wrote on 2014-09-07 08:35:39 (UTC)
To me this task has two blockers:
I would add that some documentation about what these points are and how are we using them would be useful. I recall several users not knowing what to do with them (including myself on my first day using Phabricator).
aklapper wrote on 2014-09-07 12:34:08 (UTC)
Some teams seem to want them back.
Who? We do not offer a custom field for agile points as long as there are no tools to display points (T244). If some teams have some tools to query that custom field in Phabricator, I'd like to be aware of these tools. Or do people copy points of closed tasks into some Google Docs table for their team?
Rush wrote on 2014-09-07 13:09:24 (UTC)
I think maybe at some point it will make sense to have a "type" of task (bug, ops issue, non-technical) idk. There are more advanced custom field options available than how points were done, but I generally agree on the UI stuff. It will get messy quick without being very judicious about ticket fields. Either way, seems like an ongoing discussion.
greg wrote on 2014-09-07 15:44:34 (UTC)
(I edited the title/description based on my understanding that this isn't custom to us since I see it available on upstream Phabricator'x Phab.)
Story points (search for "story points" for a wealth of info on how they're used) are fundamental to how Agile teams work. Without at least the ability to hack something out of Phab (ie: have the story points in the Phab Task edit, like it is upstream, and allow a script to query that for reporting.)
Also, story points are a very important use case was for the burn-down/up charts that are in-progress (right?). Just having a burn-down/up of # of tasks isn't sufficient for Agile (trademark or no) team.
I'd prefer them to be available to those in the Triagers group. I want to be able to create a ticket with story points from the beginning (not having to click edit after creation) and I want my team to be able to edit the story points with as little friction as possible.
greg wrote on 2014-09-07 16:07:11 (UTC)
(I might have been wrong about where the 'customization' lives, feel free to re-title/describe more accurately.)
Looking at the volunteer contributed burn-down chart readme "Story Points" is a required custom field for it to work:
https://github.com/bluehawk/phabricator-sprint
Thus, I think we should have it :)
tobijat wrote on 2014-09-08 12:21:16 (UTC)
I think not having the functionality implemented e.g. in https://github.com/bluehawk/phabricator-sprint in Phabricator would be a blocker for our team (Wikidata) to migrate to Phabricator.
aklapper wrote on 2014-09-08 16:21:05 (UTC)
and allow a script to query that for reporting.
@greg: Is writing such a script on the to-do list of anybody, or would people rather wait for a proper solution in T244 to actually use those Story Points in tasks? I'm still wondering how these points would actually be used, gathered, analyzed without having burndown charts at the beginning.
(Trying to understand what each team is up to, and at least Analytics, Wikidata and Greg's team have interest in burndown and points.)
To quote the Wikidata team, "If it is easy to enable these fields when we want to deploy the phabricator-sprint tool (T244), we do not make this a blocker for the initial migration" so I'm removing the bugzilla-migration project again on this task.
Adding that custom field is rather easy (though we'd like to potentially hide it for average users not intended to set or use it).
Maybe we can have story points editable only by some, in the form of an advanced custom field.
Should the group of people be the acl*Batch-Editors or a specific group e.g. Scrummasters?
I don't particularly have a preference as to which group should have that right, as long as all the members of my team get it, since any of us update points on Mingle in our current workflow.
@Aklapper Workboards currently mention "points". Which I believe just mean the amount of tasks at the moment (i.e. one task = one point). Already displaying story points on the workboards would be very useful, and replicate the core existing use case for story points on Mingle.
Turns out that at least Mobile and Multimedia are not using burndown charts (T153), but they rely on T803: Show task Story Points sums in workboards.
After this explanation of the Sprint extension, it is unclear to me whether the story points are brought by the extension, or whether they need to be enabled to Maniphest separately. Also, whether teams willing points will also use the extension or not, or whether it can be both, or whether the question doesn't matter...
Sorry for the vague questions (that maybe have been answered as well). This reminds me... we will need some basic documentation. a section in https://www.mediawiki.org/wiki/Phabricator/Project_management ?
Sprint is entirely optional for all teams. The only thing that triggers a project as a Sprint is the use of the special character (§) in the project title.
The custom field implementations use the Standard Phabricator Custom Field interface which allows proxying. Proxies allow a field to use some other field's implementation for most of its behavior while still subclassing the application field. For example, the Sprint Project Start Date Field proxies the Standard Custom Field Date, which is used in many other applications. Nothing needs to be enabled in the applications that Sprint depends on (Projects and Maniphest) for this to occur. The benefit of this is that it is impossible for Sprint to break any other uses of the field, because its behavior is subclassed within the application.
The Sprint application context is routed with URLs, like all Phabricator applications. So, any requests passed to /sprint will be handled by the Sprint controller.
In other words, projects interested in story points should use Sprint, even if they would ignore the burndown chart generated?
Maybe someone interested in points-not-charts wants to try this in http://phab08.wmflabs.org and see whether this is a good solution. The advantage is that we would save a "Points" form field to all the rest of projects/users relying on plain Maniphest.
Assuming Yes for now and resolving Declined for a custom field that would be visible in all tasks.
The Sprint extension will land soon here (T1322). Teams interested in story points are encouraged to try it out and see whether this solution works for them. If there is something to be polished, first they should try to improve Sprint itself. There are two main benefits to this approach: