Page MenuHomePhabricator

Disable parent task metadata by default for new sub tasks
Open, LowPublic

Assigned To
Authored By
Nov 28 2019, 2:43 AM
Referenced Files
F55002105: image.png
Jun 7 2024, 7:51 AM
F55002171: image.png
Jun 7 2024, 7:51 AM
"Like" token, awarded by TBurmeister."Like" token, awarded by fnegri."Like" token, awarded by MusikAnimal."Like" token, awarded by Volker_E."Like" token, awarded by Tgr."Like" token, awarded by Milimetric."Like" token, awarded by BPirkle."Like" token, awarded by Novem_Linguae."Like" token, awarded by CDanis."Like" token, awarded by bd808."Like" token, awarded by sbassett."Like" token, awarded by VPuffetMichel."Dislike" token, awarded by thiemowmde."Like" token, awarded by FJoseph-WMF."Like" token, awarded by Daimona."Like" token, awarded by jsn.sherman."Like" token, awarded by Bawolff."Stroopwafel" token, awarded by dcaro."Like" token, awarded by Kaartic."Like" token, awarded by Mvolz."Like" token, awarded by Michael."Like" token, awarded by Dreamy_Jazz."Like" token, awarded by Sportzpikachu."Like" token, awarded by Marostegui."Dislike" token, awarded by MoritzMuehlenhoff."Stroopwafel" token, awarded by MBinder_WMF."Like" token, awarded by JJMC89.


It seems very rare, if ever, that people create sub tasks with the intention of tagging all the same projects, assignee and subscribers.

There are a number of things we know we never want to inherit:

But perhaps it makes more sense, at least until there is a better option, to go for the other extreme and perhaps disable this feature entirely?

Note that when creating a task, one can still add any tags that are desired. And it will still become a sub task by default, and notify subscribers of the parent task. Also, resolution of the sub task notifies the parent task as well.


TitleReferenceAuthorSource BranchDest Branch
Draft: Do not inherit subscribers and project tags when creating a subtaskrepos/phabricator/phabricator!56aklapperT239378subtaskRmTagsCCwmf/stable
Customize query in GitLab

Event Timeline

Ok it's fairly simple to implement this, I've got a commit ready to go but I want to be sure that there is broad consensus that this is wanted before I go ahead with deploying it.

Hmm, I'm unsure what could or should be the behavior which is "most wanted" by the majority of users, plus more predictable / less surprising (as software trying to be smart often leads to surprising results). I don't believe that removing all project tags is a good idea, though I'd also say that you often do not want to carry over certain project tags like Epic or Patch-For-Review, or all subscribers.

I'm wondering whether a blinking™ banner "Please do review the assignee, subscriber and project tags first!" when using the Edit Related Tasks...Create Subtask path (is that detectable?) would be clearer (leaving it to a human to give it a thought) and also simplify a potential custom downstream patch (and lower its long-term maintenance costs).

For the records, we currently have H136 (Remove Patch-For-Review from newly created tasks) and H363 (If Patch-For-Review && Patch-Needs-Improvement, remove Patch-Needs-Improvement) in place when it comes to stripping/replacing some tags via Herald, but that's it AFAIK.

I agree there are cases where there's one or two tags you want to "keep" the same.

I suppose the question is what will be more efficient and less wasteful on the person creating the task and on all other people involved in the project:

  1. Inherit by default. Add warnings. Read warnings. Don't get warning fatigue. Everyone has to conciously decide what tags to remove (friction, default is to keep). Any sense of FOMO, uncertainty, doubt or good will will round towards keeping. Same for subscribers, keeping information from others by actively x-ing out their name is not something I think most people will easily feel comfortable doing.. "mistakes" are amplified to many workboards and personal notifications, including for all future activity on the task. Requires tolerance, corrections, and educating against the natural forces. All of which then produces additional notifications as people each correct for their own area.
  1. Don't inherit by default. As task creator you know what its about and will naturally enter the tags you think are relevant, just like when creating any other task. Usually only one or two for new tasks. Quick and easy.

Subscribers can generally just empty. Note that parent task subscribers are notifiied always of opening and closing of subtasks regardless.

What's a good way to proceed here, e.g. what's a simple and efficient way to determine the right outcome. Do we hold a poll? Do we invest engineering resources to analyse past events to deduce user intent? Do we flip the switch and see if anyone complains vs thanks us? Do we send a survey to all creators of recent subtasks that kept stuff and ask if they intended to do what they did?

I was talking with Andre the other day about this and he pointed me to this task.

I want to show support for Don't inherit by default, every time making a subtask I have to remove almost all subscribers and projects every single time to the point where starting blank would be a lot more useful.

Anecdotally I've also been added to plenty of tasks as a subscriber just because I was subscribed to a parent task and the people making subtasks didn't really pay attention to the subscribers, resulting in noise and wasted time unsubscribing.

Aklapper triaged this task as Lowest priority.May 30 2021, 9:36 AM

I was talking with Andre the other day about this and he pointed me to this task.

I want to show support for Don't inherit by default, every time making a subtask I have to remove almost all subscribers and projects every single time to the point where starting blank would be a lot more useful.


This may be moot now that Phacility is EOL, but in the true spirit of Phabbing, a workaround for mitigating all that tag/subscriber removal could be to make the task separately, and then add the parent to it. I don't think this is a nice user experience, and I think it's non-intuitive, but if you're doing this often enough then the repetition may prove useful. :)

That said, if it's a simple fix, I'm on board, too!

I'd also recommend jut blanking all the fields and maybe opting in specific projects if someone complains about them. It would be far less disruptive than the current behavior.

+1 to the proposal that seems to have unanimous support so far, for not including the Subscribers from the parent task. A few non-developer people have asked me over the years, why they were suddenly subscribed to dozens of new tasks and flooded with email.

I'd suggest that sending an email to wikitech-l@ would be the best way to determine if anyone has strong concerns that outweigh the known benefits. Perhaps something like:

There is a proposal to change the way "Sub-tasks" work in our Phabricator, so that when they are created they no longer automatically replicate the "Subscribers" list from the "Parent" task. 

This would help reduce email overload for many of us, in the frequent cases when a large/epic task is more fully detailed into dozens (in some cases hundreds) of smaller tasks. 

If you have any concerns about this, please read the comments in T239378 and then comment yourself. 
If you support it, either add a Token or ignore this request.

I'm not sure about whether to include/remove the Parent task's #projects or assignees. I lean hesitantly towards removing the assignee, but leaving the projects.

It might also be good to add information into explaining which types of notification we need to enable, in order to get notified about subtask creation - (I think my current setup, per that screenshot, ignores these. I'm not sure if I need to change Other task activity not listed above occurs or One of a task's subtasks changes status.) - Or to specify exactly what types of things will be added/removed with that former setting, which I vaguely recall as being associated only with Tokens.

Implementing this would require some code changes, so in my understanding this would fall into the Release-Engineering-Team realm.

The easiest thing to do would be all or nothing. Cherry-picking some of the fields to copy might be more involved.

When you click create subtask, you eventually end up on a page with a url like maniphest/task/edit/form/1/?parent=239378&template=239378&status=open

If you remove template=NNN from the url you can still make a subtask but with none of the fields copied. So the easy solution would be to change the url that Phabricator directs you to and simply remove the template parameter.

If you remove template=NNN from the url you can still make a subtask but with none of the fields copied. So the easy solution would be to change the url that Phabricator directs you to and simply remove the template parameter.

With this you also lose the tags in the form, but in my experience they always need some sort of tweaking, so personally I believe the pros of not inheriting the subscribers outweigh the cons of losing the parent tags in the form. +1 from me.

+1 for disabling entirely. In my experience, the sub tasks generally need fewer or different tags. And the awareness and understanding of the (unwanted) tags is usually inversely correlated with the author of the subtask. E.g. a parent task created mainly by/for team X, where other teams and vertical support layers add additional tags specific to it, and them team X creates a sub task and might not feel comfortable to "remove" these tags. The author would know which tags need to be present, but might not explicitly know which tags don't need to be present.

Note that for transparancy and awareness, Phabricator already notifies the parent task (once) during the subtask creation regardless of subscribers and tags etc, so in rare cases where it is desired for other teams to track/monitor/organize subtasks in a similar or different way, they can still do so.

+1 for disabling too, it makes having a meta-task communicated to a lot of different teams a hindrance, because you then have to remove most of these tags every time a subtask is created.

I'll use the workaround of removing the template= parameter from the URL in the meantime.

Aklapper raised the priority of this task from Lowest to Low.

This would be an excellent change. However, can we instead get an email notification on the parent task when a subtask is created? Currently Phabricator only sends an email when a subtask is added using the "Edit Subtasks" menu, but not when one is created using the "Create Subtask" menu, presumably because all subscribers would get a notification about it already, and now they won't.

I'm in favour for not copying subscribers, but I think except for a few meta tags (epic, etc) copying the project tasks is more useful than not.

-1. But I think it's fine to have a non default preference for this. So anyone who does want to get these mails could turn this on.

I'm generally in favor, especially when it comes to the subscribers. Torn with the project tags. There are some you most defenitly don't want to copy over, but some you most probably want to keep. 🤔

Can we add another subtype for "Generic task (copy tags and subscribers from parents)" so you can choose?

image.png (960×1 px, 103 KB)

Or small JS plugin that adds a button on the form for "Clear tags, subscribers, and assignee" ?

image.png (1×1 px, 287 KB)

I don't mind if subscribers aren't copied, as long as there's an easy way for subscribers to the parent task to be notified about children created if they like, with a one click add or something. Basically, I don't want to have to actively monitor a pile of parent tasks to see if any child tasks of interest were created that I want also to subscribe to.