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.

2. 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.

In T239378#6409869, @Jhernandez wrote:

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.

+1

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.
Thanks!

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 https://www.mediawiki.org/wiki/Phabricator/Help/Managing_mail#Ignore_metadata_changes 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.

In T239378#7497894, @mmodell wrote:

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 opened https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/merge_requests/56

Draft: Do not inherit subscribers and project tags when creating a subtask

[FYI] Email to wikitech-l@: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/YBXFG67H2WXSIGRQE46HVATZGHH24GHO/

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?

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

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.

In T239378#9863764, @matmarex wrote:

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.

In T239378#9883404, @ArielGlenn wrote:

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.

Okay, so it turns out that maybe this is already meant to be happening; and the fact that it isn't might be a bug? Either way, filed as T405084: No notification is sent to a task when a new subtask of it is created & that new subtask's status is "Open" :)