Page MenuHomePhabricator

Subscribing users when they award tokens
Closed, WontfixPublic


Some new users seem to expect that you subscribe to an object when you award it with a token. When I read this idea, I had to check whether this was happening or not (it doesn't). Sounds sensible.

Some other combinations may arise (user actually doesn't want to subscribe; user removes token, what now) but I think they are secondary cases that can always be solved with an extra click to "Unsubscribe".

Event Timeline

qgil raised the priority of this task from to Needs Triage.
qgil updated the task description. (Show Details)
qgil added a project: Tokens.
qgil added a subscriber: qgil.

@chad / @btrahan, do you have opinions here?

I have a weak inclination not to change it: I like that it just does what it says, and that tokens are an explicit, relatively heavyweight action and not every comment and object has a whole pile of tokens. But I'm also almost always subscribed to objects that I award tokens to.

I do think we could improve onboarding to give users a better shot at clicking the button with the right expectations the first time, but this is a general issue and I'm not sure how we can solve it without popping Clippy the first time you try to give someone a token. A soft effort might be to put a line of explanatory text in the dialog with a link to documentation.

Yeah, let's keep this open. I don't want it to subscribe me, but it's completely logical that it should - FB works that way, and anything you add to the timeline does here as well.

Most generally, I like the model of "you touch it and you are automagically subscribed", with "unsubscribe" being sticky through subsequent touches.

So in this case I would have the token subscribe.

I too am almost always subscribed when I give a token to something. I am trying to think of instances where I give a token and I wouldn't want to be subscribed and all I can come up with is the case where I see a diff I think is awesome and about to be committed so <TOKEN TIME> but then it goes back for changes a bunch and I regret having subscribed. That said, I'd probably learn something in this case so I can suffer through it if it happens. :D

For what is worth, in Bugzilla you are included to the CC of a report when you vote it , and in Gerrit you also subscribe to a changeset when you +1/-1 it.

I'm also almost always subscribed to objects that I award tokens to.

This means that heavy users like you omnipresent maintainers would not be bothered by this feature, if you ever notice it. For the new/average user this will mean one click less in most cases.

I'm fine changing the behavior

you touch it and you are automagically subscribed

I think the rule right now is "you add a comment and you are automagically subscribed". We have a few special cases (adding an answer in Ponder, for example), but do not subscribe you for things like moving a task on a workboard, adding a project, fixing a typo in a title, or editing dependencies.

I think this is the right rule? If we adopted a "you touch it and you're subscribed" rule instead I'd tend to agree that tokens should subscribe you, but I don't feel like the weaker rule we have right now is problematic.

epriestley claimed this task.

This doesn't seem to be going anywhere too fast so I'm just going to nuke it while I'm combing through old things rather than letting it collect dust forever.

The current rule, which I think is consistent everywhere, is that adding a comment auto-subscribes you but other actions (like changing the priority of a task or tagging it with projects) do not. So I don't think we have a product inconsistency here.

"Award Token" isn't really "Vote", even though some users use it that way, especially on open source installs. I think it's good that it isn't "Vote", since I think "Thanks" or "Neat" or "I'm so sorry you have to deal with this mess" are more valuable interactions than "Vote" / "+1", and I'm not sure that "Vote" is actually very useful (I think the downstream task raises similar questions). See also some discussion in T3611.

If we do want "Vote", I think we should probably just build "Vote", but we should be clear about what the goals are: it's probably not a prioritization signal, but a mechanism for supporting community interaction, doing some "+1" / "when are you doing this" noise reduction (and trading it for "why haven't you done this yet, it has so many votes!"), making users feel more empowered, or whatever else. I think users generally want "Vote" because they want to feel like they can control priorities more than upstreams want "Vote".

I don't think we have any strong opposition to reconsidering this behavior, but there doesn't seem to be a strong driver for it either. Feel free to file something new if things have changed or there's a new motivation for this (or you want to talk about "Vote" or whatever).