Re: [teampractices] FYI: Phabricator workaround for manually selecting tasks to bulk-edit

[Max Binder]

As far as I know, you could always Batch Edit from the Maniphest query page.

https://phabricator.wikimedia.org/maniphest/query/advanced/

Then just search for what you want. In your example for a workboard, you
would search for the workboard's title  (rather than hacking the URL). So,
if I want to Batch Edit tasks on the Team-Practices board, I'd do a
Maniphest query for Tags = Team-Practices, then Batch Edit the results, as
selected.

The real gem that you surfaced is selective Batch Editing tasks in a
column, since you can't do a Maniphest query for columns, and even when you
Batch Edit a column via the column dropdown, you can't deselect tasks.
Super useful.

Of course, if you're a not a member of Triagers
, you can't Batch Edit,
anyway. :)

Potential use cases: bulk editing in triage, bulk estimation,
> recategorizing lots of tasks at once, etc.
>

Batch editing hasn't really been updated as new Phab features have been
introduced, so newer things like Story Points (estimation) are not an
option.



On Thu, Oct 6, 2016 at 3:29 PM, Kevin Smith  wrote:

> Cool! Can you (Joel) add it to our phab docs, so I'll be able to find it
> later, if/when I need it? (If not, hopefully someone else will.)
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Thu, Oct 6, 2016 at 5:35 PM, Joel Aufrecht 
> wrote:
>
>> I saw this workaround in passing (Upstream T11286#184572
>> ) and wanted to highlight
>> it.  If you want to batch-edit some but not all tasks in a column or
>> workboard, there is a way to get shift-click power to select and deselect
>> individual items.
>>
>>1.
>>
>>Navigate to the board you want to batch-edit
>>2.
>>
>>At the top of the column on the board that you want to batch-edit,
>>click the dropdown arrow and then Batch Edit Tasks...
>>3.
>>
>>Hack the URL.  From
>>1.
>>
>>   http://local.phacility.com/maniphest/batch/?board=117&batch=
>>   274%2C250%2C265
>>   2.
>>
>>   ...replace batch/?board=X&batch= with ?ids=
>>   3.
>>
>>   http://local.phacility.com/maniphest/?ids=274%2C250%2C265
>>   4.
>>
>>Click Select All at the bottom of the list.
>>5.
>>
>>Shift-click tasks to deselect.
>>
>> When done deselecting, click Batch Edit Selected at the bottom of the
>> list.
>>
>> This also works for all of the tasks on a board (click the *Manage* gear
>> icon at the top right of the board, then *Batch Edit Visible Tasks...*),
>> but all of the columns are collapsed into the single query result list so
>> it's not as useful a workaround.
>>
>> Potential use cases: bulk editing in triage, bulk estimation,
>> recategorizing lots of tasks at once, etc.
>>
>>
>>
>> *-- Joel Aufrecht*
>> Team Practices Group
>> Wikimedia Foundation
>>
>> ___
>> teampractices mailing list
>> teampractices@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] How to best track the work within Phabricator Epic tasks

[Kevin Smith]

If my years of programming taught me anything, it is the evil of
duplication. There needs to be one authoritative source of information. Any
copy is at high risk of being out-of-date or out-of-synch, either of which
make it misleading. For me, misleading information is (much) worse than
none at all.

In approach 1:

   - Sequencing can be handled by creating sub/parent task dependency
   chains among the children. It's ugly, and the new phab terminology really
   sucks for this use case, but it is possible, if it's important. Or we could
   adopt a convention of putting sequence numbers at the start of each subtask
   title, in cases where sequencing matters and is not obvious.
   - I agree that the graphic presentation is horrible, although the more I
   stare at the little spaghetti mazes, the more I start to believe that I
   might be starting to understand them.

I think this issue intersects with:

Should we "explode" tasks pro-actively/early? I am increasingly thinking
the answer is "no".

Should we use phabricator as our primary tool for learning the status and
​next steps of an epic? I'm also leaning toward "no", because the epic
owner/shepherd should serve as a reasonable source of that information.




Kevin Smith
Agile Coach, Wikimedia Foundation


On Thu, Sep 29, 2016 at 11:13 PM, Joel Aufrecht 
wrote:

> TPG is struggling with practices for having lists of sub-tasks within
> Phabricator tasks. So far we have used two approaches, neither fully
> satisfactory, and we are looking for approaches that solve all of the
> problems with none of the drawbacks.
>
> The most common example of this problem is a complex piece of work, e.g.
> an "Epic" task, which has many subcomponents and which may take months to
> complete in full. We generally create a Phabricator task to track this work
> as a whole, tagged as "Epic". Then, we have two different approaches to
> decomposition.
>
>
> *Approach 1: Pure subtasks*
>
> For each divisible piece of work within this Epic, we create a separate
> Phabricator task as a subtask of the Epic. The Epic task itself has a brief
> description. An example of this is T137479: [EPIC] Provide support to
> people in design-related roles 
> .
>
> What works well:
>
>- All divisible work is tracked as subtasks, so they can be properly
>tracked (status is clear, responsibility is clear, history is logged, etc.)
>
> What works poorly:
>
>- All work must be decomposed into sub-tasks (as opposed to being left
>in outline form)
>- The relative order of sub-tasks cannot be modified.
>- The list of subtasks is presented in the Task Graph, which is not as
>familiar or legible as an indented bullet list
>- Sub-tasks may have multiple parents, which is confusing to users
>expecting pure trees.  For example:
>
>
> ​*Approach 2: Manual subtask tree*
>
> The work comprising the Epic is documented in the Phabricator Description
> field as a list or tree of subcomponents, which may be either lines of text
> or links to Phabricator sub-tasks.  Example: T122839: A documented and
> agreed upon definition of ‘core work’ exists
> .
>
> What works well:
>
>- The order of subtasks can be edited
>- Small pieces of work can be documented as lines of text instead of
>complete Phabricator tasks
>- The work breakdown is more legible to those expecting a checklist or
>tree
>- Sub-tasks can be documented using the {T##} shortcut, which
>auto-updates title and status.
>- Changes to the Description are well-highlighted in update emails.
>
> What works poorly:
>
>- The subtasks in Phabricator inevitably get out of sync with the list
>of subtasks in the Description.
>- The status of checkboxes in the description inevitably gets out of
>sync with the status of subtasks
>- The history of text-only tasks in the description is not easily
>accessible in the web interface.
>
> Example:
>
> Should we commit to Approach 1 or 2, or are there other approaches which
> provide the benefits of both?
>
>
>
> *-- Joel Aufrecht*
> Team Practices Group
> Wikimedia Foundation
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices