Page MenuHomePhabricator

Show assigning action when changing state on a task to closed, for explicitness and potential opt-out
Closed, WontfixPublic

Description

Right now on our install we have a few states:

Resolved
Stalled
Invalid
Declined
Open

When a user moves a task between states they will become the defacto assignee. In general (personally) I can see the general wisdom in this default, but there have arisen a few situations where arguably showing the input with a prefilled in user (like when you go to normally Reassign/Claim a task) would make sense.

Yesterday I stalled an issue for someone because it had no assignee yet, and then suddenly I was on the hook :) It was an easy fix, but I think it probably would have made sense to show the hint that I was taking on the issue as I was shifting state on the issue.

One of our users requested this upstream issue so they could submit a patch to this effect.

https://phabricator.wikimedia.org/T84833#949424

Event Timeline

chasemp updated the task description. (Show Details)Jan 8 2015, 7:06 PM
chasemp added projects: Wikimedia, Maniphest.
chasemp added a subscriber: chasemp.
chasemp created this task.
chasemp assigned this task to matmarex.
chasemp raised the priority of this task from to Normal.
chad added a subscriber: chad.Jan 8 2015, 7:09 PM

I would expect any close action to do this, is stalled an open or closed state?

chasemp added a comment.EditedJan 8 2015, 7:15 PM

Yep and the behavior I think is OK with us, but we are thinking that the "hint" of the dialogue showing the behavior would align things more with users expectations (at least seemingly ours). Right now unless you know it's going to assign it to you because of past experience I don't think there is any clue as you are changing state?

(Also a dialogue like the regular Reassign/Claim one would allow a user as they are stalling a task to set a more appropriate user at the same time

Like:

Stalling -> assign to next weeks triage person instead of me)

chasemp added a comment.EditedJan 8 2015, 7:21 PM

I am wrong :) Stalled is an open state, and I did not assign me on that issue for this reason. It was moving an issue to 'invalid' state that did the auto-assign (but that is just my anecdotal example of this process)

So, moving an issue to a "closed" state triggers this. The reasoning still stands but I wanted to clarify. It is kind of a bummer right now when I want to close something as "invalid" I see it in my assigned tasks and I didn't get a chance to leave a blank assignee as these are junk tasks.

Once it's closed and I've "auto claimed it" I can still go back in and place the issue up for grabs. It could be argued that this is encouraging good behavior, and in some cases it is, but I don't think it's doing so more than an explicit input with a default would.

chad closed this task as Wontfix.Jan 8 2015, 8:21 PM

"The comment/action box is confusing" is a common concern raised, but we don't have explicit plans to redesign on the roadmap (there are some attempts in Pholio). It would be nice to address it this year, though. Feedback is noted. I don't think we have plans to pursue any changes outside of a redesign comment box so we'll just punt for now.

aklapper renamed this task from Show assigning action when changing state on a task for explicitness and potential opt-out to Show assigning action when changing state on a task to closed, for explicitness and potential opt-out.Jan 8 2015, 8:22 PM
aklapper reopened this task as Open.

@chad would you accept a patch for this? @matmarex has indicated he would like to submit one.

chad added a comment.Jan 8 2015, 9:10 PM

There are a number of issues here both with the task and it's suggested resolution. But first, it's frustrating to me personally that I can't make the decision to address later and not spend time on the issue now. When anyone wants to have a long debate about something in Phabricator, it has a very real impact on the product as spending hours debating each day means the product moves forward that much slower (design time specifically, is 1:1, each hour writing this opinion up is one less hour thinking about roadmapped issues).

On design/product philosophy:

  • Phabricator itself is a productivity tool first, and specifically built for people who spend large amounts of time in it. Increasing their productivity is one of our core design philosophies.
  • Continually altering Phabricator to be more accessible, understandable is a low priority (but understandable).
  • Changes which might affect productivity are to be well scrutinized.

On Phacility:

  • We have extremely limited resources to think about the right solution to every problem that comes in.
  • Because of this we prefer to group problems and present a single solution.
  • Continually addressing minor issues without looking at the big picture reduces the ability of Phabricator to move quickly, and often duplicates work.

On Feature Requests

  • We really need the right to close or 'address later' features or issues encountered without fear of being drug into a long debate. It's not for the upstream should suffice in most cases.
  • Feature requests from Wikimedia have dominated the roadmap and production time all last year. We did not ship Phacility likely because of this, at least in my opinion.
  • We are about to personally fund Phacility again (and likely the last time) so we're going to be much stingier with roadmap alterations. We are very serious about making Phacility successful, and with that success, every Phabricator install will greatly benefit.

That all said, yes the comment box needs work. But it's not on the slate to fix now. (This includes reviewing patches). Therefore, time is more optimally spent adding comments and criticism to the current designs rather than ship little things here and there. M164 is the current Pholio mock for feedback.

The correct fix at least in my opinion would be to properly show the action in the preview box. Having the dropdown appear when you close a task for clarity isn't needed 99% of the time. This leads me to feel like it's added clutter, forcing my attention, all when you simply want to close a task and move on. I don't want to add an additional decision to the user in this case.

chasemp closed this task as Resolved.Jan 8 2015, 9:32 PM

@chad, I'm sorry that was frustrating for you man. I think your response is fair in both cases. I wasn't sure if the punt was for the effort to do the thing, or for the thing itself. That's why I was wondering if a patch was welcome. Not to push any usability agenda really, just as a "hey if you guys are limited on time could we help this along?"

I hope that makes sense.

chad added a comment.Jan 8 2015, 9:34 PM

Thanks! And for the record I feel like a huge asshat, but also felt maybe explaining some behind the scenes stuff was maybe helpful. I hope nothing is taken personal. We do need the feedback to make the right decisions moving forward.

In T6905#90607, @chad wrote:

Thanks! And for the record I feel like a huge asshat, but also felt maybe explaining some behind the scenes stuff was maybe helpful. I hope nothing is taken personal. We do need the feedback to make the right decisions moving forward.

Something happened and I thought huh dunno if I'm silly or the world...

Macro derpdog:

Then I made a ticket with errors in my own feature request...

Macro double-facepalm:

And then you were like no way man aint nobody got time for that...

Macro daftpunk:

And I was like, oh man maybe our peeps could own this engineering...

Macro whatcouldgowrongindoorpooledition:

And then you were like, don't tell me how to put pools in basements. I know damn well how to basement a pool...

Macro uglyhack:

And then I was like..oh man...bummer

Macro accidentalbigdiff:

Macro runaway:

And then you were like (artistic license here)

Macro dancingpicard:

But no worries man I was mostly like:

Macro nyancat:

And I think we are here...

Macro ilovethissomuch:

Long story short, I'll be in SF in a few weeks. I'll buy you a beer.

Also sorry if my reopening of this task created part of the frustration. My action wasn't intentional; looks like Phabricator does not warn me if another user changes the status in the meantime. :-/

scfc changed the task status from Resolved to Wontfix.Jan 9 2015, 4:07 AM