This request does not describe a root problem; instead, it asks for a specific feature. See Describing Root Problems for help.

Authored by is precisely in the same place it was previously, which is the first transaction in timeline. As an additional, new feature, it was also placed in the side column.

Assigned to did move. I don't fundamentally believe this information is prominently important on every page view. It's helpful for us, which is why we point to Describing Root Problems to understand the core workflow people are using and encounter issues around. For example, a root problem might be that you want to know the owner of the task when reading the comments. In Differential we annotate who the (author) is in inline comments, maybe a similar feature would be useful here. But this is a guess. We need to understand what problem prompted this task to begin with. Not liking changes doesn't really give us much understanding of what to fix.

Sorry, I read the "Describing Root Problem" and I thought that explaining the main problem (not intuitive for users and lack of visibility for Assigned to and Authored By) was sufficient.
The problem is that users ( at least ours) want to find all essential information (and assigned to seems to be an essential information) in the same place by taking a quick look at the task such as for priority and status.

and assigned to seems to be an essential information

Why?

Mainly because this is one of the main component of a task (ie, what defines a task). But actually, this is something which could be customized on our side. Sorry for bothering you and being unclear about the request. I think you can close this task.

The main reason we ask for root problems or "why" is so we can determine what's the right way to solve the problem. So knowing why that information is useful, how often you need to reference it, and what decisions you make because of it, is important for us to determine a solution.

If the needs are superficial and you're able to easily maintain a local patch, then that might be the best option for now.

@chad, don't worry, I understood that it's important for you to have clear input from users and that's why I apologize for being unclear with my request. Moreover, as you say, this is pretty superficial and we can maintain it on our local install. But as it was the general return from our users (unintuitive UI), I thought it could be reported to upstream.

The design intent was to give more space and prominence to the title of the task, and the discussion, and this is what's important 9/10 visits to a task page. Meta-data like tags, dates, author, assignee were moved as while these are important, you only likely reference them on very rare occasions. I don't believe this pattern in the general case to be unintuitive, since the design solves the problem reasonably well. It's also the same pattern other issue trackers like GitHub use, so it's one people are certainly familiar with. As with anything of course, it's a trade off. Whats best for most installs might not work best for you, and we're happy to try to understand what that might be to make Phabricator better.

In T10775#169974, @clemvangelis wrote:

Sorry, I read the "Describing Root Problem" and I thought that explaining the main problem (not intuitive for users and lack of visibility for Assigned to and Authored By) was sufficient.
The problem is that users ( at least ours) want to find all essential information (and assigned to seems to be an essential information) in the same place by taking a quick look at the task such as for priority and status.

It might be helpful to play the 5 whys game and post the entire sequence of thoughts here.

I want to show author and assign user in the top header of maniphest tasks

why?

Because users want to see the essential information on the top

why?

Because users need to see the assignee to bug them to finish a task

why?

Because assignees often don't finish task they are assigned to

why?

Because they often get assigned too many tasks

Obviously this chain of 'whys' will be wildly different from yours but it will help Evan and Chad to understand your problem a lot better.

@chad: Ok, it makes sense, but in github, the layout is a small fixed one, not a full page one, thus the information is much more compact (at least on a 24" screen) and the "Author" is referenced under the issue title.

@eadler, indeed, it might have been better if I went though all the 5 whys, I will do that next time.

Since it fits other users, this is something we can manage on our local installation, no need to spend more time on this one. Lesson learned, I will be more cautious and precise and if I have to log another feature request.

FWIW I've gotten the same feedback about the new design, and I've had the same reaction as well.

The old format had a lot of useful information in one place. Now it's spread all over.