@Peachey88 do you know where it is happening please.

https://phabricator.wikimedia.org/T134098#2254616 is the most recent, I have seen it elsewhere.

Thanks, doesn't look like it is todo with importing refs/changes/ seems to be related to when you included the task id in irc in !log.

This only happens if the task is un-owned when you close it. What is the use-case for closing tasks but leaving them owned by nobody? That makes it difficult to search for tasks closed by a given user.

@mmodell if so it should be changed due to resolved tasks don't need to be assigned in theory since they are completed (hopefully).

What is the use-case for closing tasks but leaving them owned by nobody? That makes it difficult to search for tasks closed by a given user.

When signing-off on a task! Work has been done and no-one owns the task anymore.

Unlike before, you can override it by also adding a "Claim" action and emptying the field, and the preview shows exactly what will happen. I don't mind the current behavior myself.

Premising I'm sorry for @thiemowmde, here some inspirational notes:

1. If a person is working on something, that person should claim that Task. Not doing this is a communication problem that should not be encouraged in this giant movement.
2. Note that it's not necessary a manual intervention to claim a Task. If a commit has Closes T123, it automatically closes that Task, claiming that Task to the commit author.

Note that, if, in this exact moment, I mark as "Change Status" to Resolved here, I see this preview:

The non-obvious part: this is really a preview, and it shows that, to be nice, it automatically mark yourself as Task assignee (since, believe me, 98% of time time people wants this exact behavior)

But the good news is that you really have not to do what the system wants. You can Add Action → Assign / Claim and set an empty value. And this is the result:

This is a great margin of user experience improvement (patches are welcome in https://we.phorge.it) but I hope this explanation could help.

With these premises probably this Task title should be more feature oriented, like:

Better clarify that Resolving an unassigned Task, by default assigns you to the Task - and simplify how to avoid it

or something like that. The current title is a bit problematic since it seems like a bug, but this is really a feature that people working on software usually want to. Surely the way is not to disable this completely.

If a person is working on something, that person should claim that Task. Not doing this is a communication problem that should not be encouraged in this giant movement.

I wrote that above, yes. How does it help? Closing a task is pretty much the opposite of "I'm going to work on it".

you really have not to do what the system wants. You can Add Action → Assign / Claim and set an empty value.

I wrote that above as well. I really think it would be more effective to first read what was written before. Thank you.

98% of time time people wants this exact behavior

No, they don't.

@thiemowmde

Closing a task is pretty much the opposite of "I'm going to work on it".

I understand that you are opinionated, and I understand your workflow, but please understand that probably the majority of maintainers in GitHub, GitLab and ClickUp (not just Phabricator) very probably strongly disagree with the above opinion. Since, yes, flagging something as resolved, usually means "I've done something to resolve this".

Surely it's still 100% useful to allow workflows like:

I was walking down the street, I see somebody forgot to close this, let's mark as resolved, even if I don't know who resolved, surely it's not me"

Again, please understand that for reasons that can be understood, that is useful, and I 100% agree that it should be simplified and improved, but probably there is a reason if that was not the default.

In short, there are stakeholders against our personal opinions, and they are probably not interested in U-turning this feature.

I just suggest: let's try to propose a minimally collaborative compromise. For example, what do you think with the already-proposed title?

"Better clarify that Resolving an unassigned Task, by default assigns you to the Task - and simplify how to avoid it"

I really don't get why these users don't just use the "Closed By" filter, do the Assign / Claim click like everybody else, or set up a bot that does this. So many options. On the other hand the only option I have is to submit an empty form field to force the software to not do something. That's heavily counterintuitive, tedious, and puts the burden on the wrong group of users.

• The best idea I currently have is to add an action Change Status → Resolve & Claim and make Resolved behave sane again.
• Actually showing the "Assign / Claim" form field as if I clicked Assign / Claim would be tremendously helpful as well. This not only reflects what actually happens, it's much easier to get rid of it with the on the very right.

The best idea I currently have is to add an action Change Status → Resolve & Claim and make Resolved behave sane again.

That is exactly the kind of very useful ideas that can be proposed, thanks

In any case, I would also simply like other people to take care of their tasks and not leave them open forever, since it is not nice to expect @thiemowmde to cleanup for them, and mark their abandoned Tasks as "Resolved by an unknown else". That is really my best workaround in your support to save your time.

but please understand that probably the majority of maintainers in GitHub, GitLab and ClickUp (not just Phabricator) very probably strongly disagree with the above opinion

GitHub does not assign unassigned issues on closing.
GitLab does not assign unassigned issues on closing.

It is very common to not assign a parent task to someone when the work happens in the subtasks. Sometimes, as Thiemo mentioned, work on a task is done as a group. And many other good reasons for why a task did not happen to have an assignee.

Also, as Thiemo mentioned, the point of an assignee is to show who is going to work on it. By definition, a task that is resolved will not see any more work done.

From @Aklapper 's comment above (T134106#2254789) it sounds like it might be easy to fix by updating our config? Though that comment is 6 years old, not sure how things changed since then. If that is possible, it would seem to be the simplest fix to this "feature".

EDIT: based on T84833#2047465 and T84833#2047475, it would seem that was the intended resolution of T84833? Maybe we can just return to it/actually implement it.

(Uh! how many things I learned in one day)

First of all, the good news: we need exactly zero lines of source code to change Wikimedia Phabricator 🎉

@Aklapper can you be so kind to copy-paste the content from this page, somewhere?

https://phabricator.wikimedia.org/config/edit/maniphest.statuses/

I don't feel strongly about this either way, but I do enjoy the current behaviour. Without this feature, we should perhaps codify awareness and responsibility over how notifications are received (Help page) and set the minimum expectations for people in different roles could deal with those. Today we benefit from this feature in ways that's perhaps hard to measure or realize, through encouraging what I believe is good behaviour for the greater good. For myself, the feature feels accurate 99% of the time. Other times it's usually still generally accurate, with other potential assignees equally (in)accurate. Both with the feature on and with the feature off, when a task passes through three different persons, it'll remain by default with the assignee. Surely nobody's status or pay is dependent on what tasks are assigned to them post-closure?

In T84833#933376, @chasemp wrote:

In T84833#933373, @Dereckson wrote:

Hypothesis: the person who closes a task as invalid or stalled takes the responsibility of this status, and so is the correct assignee of the task.

this is pretty much my thinking as well

Exactly. I don't see assignment as credit, rather I see it as a temporal contact person for visibility and follow-up.

I'd much rather see tasks assigned than left unassigned, so as to reduce the friction and time required before responsibility is taken after re-opening as it'll be on someone's plate, someone who'll see it in their workflow, that knows how to handle it or can handover to someone who does. In what circumstance does one feel comfortable closing a task, yet feel one can't or shouldn't be the contact person for potential follow-up? Is that not an okay thing to crowdsource a little bit among those who are familiar with the task? (Familiar enough to close it.) On rare cases I do close a task that I neither planned nor implemented, to help someone who forgot to close it. In that case, the presence of this feature does not increase my effort. I still change the status to Resolved, I still set the assignee to a person. If anything, the presence of this feature reminds me to do the second step, as the "Preview" explicitly shows a suggested "assignee change" (defaulting to myself), which reminds me to set this to another person when needed.

The potential communication gap and overhead incurred dealing with unassigned re-opened tasks, seems a tangible downside to me. And even so, I'm happy to hand those over. I've closed a fair number of tasks over the years, yet this happens less than once a year, and takes 2 seconds to handover.

I'm curious whether those that feel more strongly about this would be comfortable sharing examples of a cost, effort, confusion, or suboptimal situation that ocurred as result of having a task you closed task assigned to you? (A task you would not choose to claim manually.)

In T134106#8826864, @valerio.bozzolan wrote:

https://phabricator.wikimedia.org/config/edit/maniphest.statuses/

{
  "open": {
    "claim": false,
    "name": "Open",
    "special": "default"
  },
  "resolved": {
    "claim": true,
    "closed": true,
    "name": "Resolved",
    "name.full": "Closed, Resolved",
    "prefixes": [
      "fixes",
      "closes"
    ],
    "special": "closed",
    "suffixes": [
      "as resolved",
      "as fixed"
    ],
    "transaction.icon": "fa-check-square-o",
    "transaction.color": "green"
  },
  …
}

Removing "Regression" tag.

T84833 was resolved in 2016 after the comment form was improved to allow setting assignees (previously it required a post-closure task edit), and the Preview was improved to show transparently what will happen before you submit. It also introduced claim-configurability which we disabled for the "invalid" and "declined" states. I don't think we actually disabled the underlying feature for resolved tasks. If we did, it would've been for only a month or so in 2016 as this task was filed shortly after that one closed.

The Wikimedia Phabricator configuration only makes a user "claim" a task when the user sets the task status to "resolved". It's one line of config.

Phabricator auto-claiming tasks when closing as resolved by default (read: upstream) makes sense to me.
In Wikimedia Phabricator, resolved is supposed to mean that "a code change that fixes the task has been merged".
Thus someone (or someones) had "assigned" themselves to work on that task by writing a code change.
I'd say it's valid to assume that the person who "resolves" a ticket is often a person who wrote the code change (or part of the code change), or a QA person who verified the code change to fix the issue, or a manager cleaning up a past sprint workboard, etc. In any case, a person who somehow feels "responsible" for closing that task.
And if someone else reopened a task, that reopened task appears on the list of tasks assigned to you (which is the default view when you go to the Tasks section) so it's more likely that you (being "responsible") will spot that the task got reopened for some reason. Assuming that users use their list of tasks assigned to them (citation needed). They are very welcome to reassign the task after spotting that it got reopened, as part of their responsibilities.

That said, basically:

• If something wasn't resolved, don't use the resolved status.
• People who work on ultimately resolving a task, or who are responsible that a task got worked on, ideally set a task assignee.
• Keeping the current configuration or not both has its pros and cons. I personally don't yet see great reasons to change the current behavior.

Premising that I see a wide margin of possible side-improvements. Just a few:

1. for experts, when fixing the auto-assign, decrease the number if weird related warnings
   • https://we.phorge.it/T15164
2. for newcomers, visual improvements to raise awareness
3. for everyone, decrease the number of clicks needed to undo an unwanted auto-claim

About 2. and 3. I think, for example, instead of just seeing a preview, could be nice to also seeing the real input box of Assign / Claim box already expanded and prefilled (to respect the preview).

For 2. and 3. there is not an upstream Task in https://we.phorge.it but it's reasonable to assume a whishlist for that would be generally appreciated, with high probabilities of being approved in main branch 💫

In T134106#8828782, @valerio.bozzolan wrote:

But, with or without that, PLEASE SET A DAMN ASSIGNEE ihih

(Not because I want it, but because Phabricator/Phorge will kill a baby puppy animal every single time we otherwise, so...)

@valerio.bozzolan: UI changes sound rather off-topic here. And comments like T134106#8828784 are just noise which add no value to the conversation. Can you please move that to upstream instead? Thanks!