Page MenuHomePhabricator

Quoting Phabricator Maniphest comments auto-subscribes users who have removed themselves from tasks
Closed, DuplicatePublic

Description

Quoting Phabricator Maniphest comments auto-subscribes users who have removed themselves from the task. You can look at the history of https://phabricator.wikimedia.org/T49694 to see an example with the user "matmarex".

Cross-reference: https://phabricator.wikimedia.org/T142920.

Event Timeline

I don't consider this to be a bug and any fix would likely lead to additional user confusion over "magic".

I also don't necessarily consider this a bug (I think a human explicitly @mention-ing a user definitely should add them again, and that quoting someone is pretty close to mentioning them, and that reasonable users could probably expect either behavior, and perhaps that the "add them again" behavior is more obvious or more expected) but T11035 discusses this and some other behaviors which have varying amounts of grey area.

I expect to address the rest of the ambiguous stuff first, then look at the technical implications of this behavior and product implications as it relates to making mentions more of an explicit signal for mail/notifications (T4654).

In T11471#190079, @chad wrote:

I don't consider this to be a bug and any fix would likely lead to additional user confusion over "magic".

I also don't necessarily consider this a bug (I think a human explicitly @mention-ing a user definitely should add them again, and that quoting someone is pretty close to mentioning them, and that reasonable users could probably expect either behavior, and perhaps that the "add them again" behavior is more obvious or more expected) but T11035 discusses this and some other behaviors which have varying amounts of grey area.

I get the sense that you all may be trying to rationalize magical behavior and that seems futile. If Phabricator Maniphest is going to insist on having magical behavior, automatically subscribing mentioned users, then any time the magic isn't sufficiently magical, it's a bug, in my opinion.

In this case, a user explicitly says "I don't want to be subscribed to this task" and the built-in quote feature in Maniphest inserts syntax into the text area that will automatically re-subscribe this user.

Maniphest's magical and implicit behavior is wrongly overriding the explicit request it previously received from a user to not be subscribed to the task. The robot is directly defying the orders given to it by a human being.

An alternate approach would be to make all task subscriptions explicit (i.e., kill the magic altogether).

For Maniphest comments, an in-between approach might be to display a message near the comment text area saying "note: your comment will add the following subscribers: matmarex [x]" where clicking the [x] link would stop the action for that comment. This approach still kind of sucks, though, because the user still ends up fighting the software even when the software has already been specifically instructed to not subscribe this user. That is, it relies on the commenter to notice and fix the bad default.

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

diff --git a/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php b/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php
index 1a3dd1c..16c08cd 100644
--- a/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php
+++ b/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php
@@ -1367,6 +1367,9 @@ abstract class PhabricatorApplicationTransactionEditor
     array $xactions,
     array $changes) {
 
+    // Do not subscribe @mention'd users.
+    return null;
+
     if (!($object instanceof PhabricatorSubscribableInterface)) {
       return null;
     }

We've only seen negative feedback about this behavior from one install, but use it frequently on this install and believe it is a useful feature overall, even if it isn't always perfect. As a general rule, we don't make upstream changes which only benefit one install. But if this feature is unusually disruptive on your install, the cost of maintaining that patch might be smaller than the cost of having the feature.

If you don't like the @mention-implies-CC behavior

MZMcBride's comment was broader than this, its point was about "having magical behavior". There are other instance of this broader "design decision", such as subscribing unassigned users, so it would be nice to know whether you take notice of the broader point.

Personally, I'd also be grateful if the "only benefit one install" broken record would stop, especially as AFAIK there is no other FLOSS install of Phabricator as big as Wikimedia's and the only opposing use case you mention is your own individual usage. (The second biggest user is Blender, I think, which seems to be one order of magnitude smaller.

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

[...]

Thank you for this patch.

We've only seen negative feedback about this behavior from one install, but use it frequently on this install and believe it is a useful feature overall, even if it isn't always perfect.

I understand and appreciate that Wikimedia's Phabricator installation is special. In particular, our users are a lot less homogenous, as opposed to work colleagues who might be using a much smaller Phabricator installation. The reason I took time to file a task here is that I believe this is a real bug, at least for Wikimedia's Phabricator installation.

It's very important that people be able to unsubscribe from tasks if they're especially frustrated or if they've left the Wikimedia Foundation or if they're taking a break from the Wikimedia movement. Or even they don't have a good reason and just want to unsubscribe, that's okay too. The why is unimportant to me; what's important is respecting someone's decision to take a break from a task. The fact that the quote feature unconditionally adds mentioned users, without regard for previous un-subscriptions and without the ability to prevent this action (you can only clean up after) is really irksome.

As a general rule, we don't make upstream changes which only benefit one install.

If you're willing to bet an amount of money that makes it worth my time, I imagine I could find one or two features that only benefit this installation. ;-)

But if this feature is unusually disruptive on your install, the cost of maintaining that patch might be smaller than the cost of having the feature.

I've been mulling it over. It looks like one of the drawbacks of this patch is that a user who writes "@nevermadeawareofthistask: could you take a look at this?" in a Maniphest comment would then have to remember to explicitly subscribe the user. Given that it's been about two years of having the current "mention implies CC" behavior, this might be annoying for some.

When a user writes a Maniphest comment, I think fully and correctly populating the "Change Subscribers" field, including its new/upcoming additions, would be a good and unobjectionable feature. This would allow the currently unconditional additions to be removed manually prior to form submission. This would still be tedious, but at least I could make a comment without having to either mangle the quote or go back after commenting to perform a separate manual action unsubscribing the user that I didn't intend to add.

Thanks again for the patch and for considering the underlying bug we're facing.

When a user writes a Maniphest comment, I think fully and correctly populating the "Change Subscribers" field, including its new/upcoming additions, would be a good and unobjectionable feature. This would allow the currently unconditional additions to be removed manually prior to form submission. This would still be tedious, but at least I could make a comment without having to either mangle the quote or go back after commenting to perform a separate manual action unsubscribing the user that I didn't intend to add.

We could populate this based on the preview, but I'm not sure it solves the core problem, which is a user wants to be completely not bothered, or maybe "mute", a certain task. I think there possible is some value for adding "leave me subscribed, but no longer give me object level notifications" for objects. Which say allows you to still track things you're interested in, but not receive push updates about them.

(I believe we already show any changes that pressing the submit button will make to subscribers accurately in the preview. This wasn't always true prior to EditEngine and I think the preview/actual effect would sometimes disagree in weird cases, but I believe the preview is now always fully accurate. However, it's quite easy to miss.)