Page MenuHomePhabricator

Decide what to do with tracking bugs
Closed, ResolvedPublic

Assigned To
Authored By
TTO
Nov 24 2014, 12:52 AM
Referenced Files
None
Tokens
"The World Burns" token, awarded by Ricordisamoa."Grey Medal" token, awarded by Liuxinyu970226."Doubloon" token, awarded by Ciencia_Al_Poder."Baby Tequila" token, awarded by Nemo_bis.

Description

There are a lot of them, see T4007 and the Tracking-Neverending tag.

I suppose they should eventually all be closed and replaced with tags or projects.

See also T266.

Event Timeline

TTO raised the priority of this task from to Needs Triage.
TTO updated the task description. (Show Details)
TTO changed Security from none to None.
TTO subscribed.
Jdforrester-WMF subscribed.

In VisualEditor I'm in the process of converting them all into projects, which is quite painful without the bulk edit right. :-)

Qgil triaged this task as Low priority.Nov 24 2014, 7:46 AM
Qgil subscribed.

I'm not sure if this needs a "generic solution". I'm curious to see which tracking tasks will actually see activity (adding and removing items) and which ones were and are mostly forgotten.

In general and when still actively used, tracking tasks sound like something to convert into tag projects (as tracking tasks were a workaround in Bugzilla to emulate keywords; keywords needed to be set up by a Bugzilla admin who might have asked questions why something is actually needed, while some folks loved to just go ahead and categorize items).

I think we could decide the deprecation of the Tracking tag, but without getting too obsessed about it. The idea is that tracking tasks are either converted to projects or to regular tasks with blockers, having a chance to have more projects associated with them now.

Tracking-Neverending includes a list of recent changes, which is useful to see which tracking tasks are seeing activity. We could start with these.

For instance, T37707: Complete unification of all accounts to SUL has Tracking and an own project, so Tracking could be safely removed there.

T54385 is a less clear candidate for an own project, but it seems that its scope fall almost entirely within Wikidata/Wikibase. We could ask @Lydia_Pintscher what does she prefer to do with it.

@Qgil: I think that is the wrong ticket id you linked? We have a few tasks in Wikidata that are not worth their own project like T73519 but would still be good to mark as tracking somehow. The tag works fine for that for me.

I wonder if there's a sane way to get all the tasks under "Blocked by" on (e.g. T2745 for T78670) into a "Maniphest search query" format to then use the "Batch editing" mode and mass-add a newly created project tag. I am afraid there isn't, which will make converting really cumbersome.

https://phabricator.wikimedia.org/maniphest/query/advanced/ does not offer a field "Blocking: T9876543" either.

Even if I had a list, "Batch editing" does not offer a "Remove Blocker bug T9876543" either so I guess I'd just leave that as is, and add a comment to the tracking bug that it's replaced by a project tag and close it as invalid.

Meh.

So what about this guideline:

  • Subtasks and blockers of real tasks are totally fine.
  • If someone wants to convert a tracking task in a project, they just need to follow the regular process to request a new project, announcing the proposal in the own tracking task.
  • New tracking tasks are discouraged. If we find one, let's propose the promoter(s) to create a project instead.

I wonder if there's a sane way to get all the tasks under "Blocked by" on (e.g. T2745 for T78670) into a "Maniphest search query" format to then use the "Batch editing" mode and mass-add a newly created project tag. I am afraid there isn't, which will make converting really cumbersome.

https://phabricator.wikimedia.org/maniphest/query/advanced/ does not offer a field "Blocking: T9876543" either.

Even if I had a list, "Batch editing" does not offer a "Remove Blocker bug T9876543" either so I guess I'd just leave that as is, and add a comment to the tracking bug that it's replaced by a project tag and close it as invalid.

Meh.

Yeah, I filed this upstream but I'm on my phone right now so can't find it. Consequently all the VisualEditor tracking bugs are waiting for me to have some time and being bored as hell. :-)

In T75703#936981, @Qgil wrote:

So what about this guideline:

  • Subtasks and blockers of real tasks are totally fine.
  • If someone wants to convert a tracking task in a project, they just need to follow the regular process to request a new project, announcing the proposal in the own tracking task.
  • New tracking tasks are discouraged. If we find one, let's propose the promoter(s) to create a project instead.

Sounds good. Note that the line between real tasks and tracking bugs can get a little blurry, though — e.g. "Get Xyz ready to go" or "Release Abc version 1.0", so some judgement may be needed.

  1. Select all the blocking tasks
  2. Paste in Gedit or equivalent
  3. Save as csv
  4. Open in Calc or equivalent, using "space" as separator
  5. Copy the column with the reference numbers
  6. Paste it in Gedit or equivalent
  7. Ctrl-H to substitute all colons by commas
  8. Copy the list of task numbers with commas
  9. Paste it in "Task IDs" field in Maniphest advanced search and hit "Search"

Sounds complicated but it takes just a couple of minutes. See an example from T2745 to https://phabricator.wikimedia.org/maniphest/query/bKU3kGuAWKFB/#R (278 tasks)

Adding a bug to a tracking bug in bugzilla was easy, because there were 2 ways of doing that: from the tracking bug or from the bug itself. And it was a matter of adding the bug number in the comma-separated list of bug numbers.

Now in Phabricator I find it a lot harder to do. You can only do that from the tracking task, which usually contains tons of blocked tasks (see T2384). It presents you a search to type the task number or description, and below the interminable list of blocked tasks, and you need to scroll until the end of the list to add the new task. I find it crappy enough to comment this situation.

This situation could be alleviated if Phabricator allowed to edit the blocking tasks from the inverse perspective (add the tracking task from the child task itself) as Bugzilla allowed.

Converting tracking tasks into projects would be more helpful

Now in Phabricator I find it a lot harder to do.

See T33.

In T75703#936981, @Qgil wrote:

So what about this guideline:

  • Subtasks and blockers of real tasks are totally fine.
  • If someone wants to convert a tracking task in a project, they just need to follow the regular process to request a new project, announcing the proposal in the own tracking task.
  • New tracking tasks are discouraged. If we find one, let's propose the promoter(s) to create a project instead.

+1. Should move these bullet points plus the workaround in T75703#937036 to some wikipage.
Probably some subpage of https://www.mediawiki.org/wiki/Phabricator/Project_management and linking from "Tasks cannot be worked on yet" (covers dependencies) or "Scope of tasks" (covers subtasks)?

Should also note that the actual work (mass-add new project to open and closed tasks; close old tracking bug by editing description saying "This task is not used anymore for tracking. Tickets have been moved to project #Foobar") to convert a tracking task to a project could be done by the requester having batch-edit permissions.
Might also want to mention advantages: Workboard for project.

After moving this to a wikipage I consider this task done.

Copying my steps from T86232#1034556:

  • Requested project has been created: MediaWiki-jQuery-Tablesorter
  • Dependency tasks of tracking task 33601 have been added to the new project.
  • Subscribers of 33601 have been added as project members to the new project.
  • Tracking task 33601 has been closed and its summary updated. Also added new summary as a comment as mail notification settings differ among folks.
Aklapper raised the priority of this task from Low to Medium.Feb 25 2015, 7:36 PM