Do you agree with the new description, to be used in a report upstream?

Note: I don't have a strong opinion. It is true that I find the current setup a bit awkward, it is also true that before I was clicking the "Workboard" link just too often.

Generally: Looks good. Thanks!

I'm wondering if performance should also be mentioned. The (unused) Multimedia workboard has nearly 1500 tasks and already takes 10-12 seconds to load in Firefox 35 on my connection.

Also, as I mentioned above, I still think that the focus should be on people getting things done (tasks, workboards) instead of people trying to find out basic stuff (what is this project about).

Many projects haven an unused workboard consisting on a long Backlog column, which is not welcoming at all.

Was wondering if a link to a project should go to the description page instead if the workboard has just one single default column defined, but links to projects going to two different places would be inconsistent and even more confusing. No good idea.

In Phabricator creating projects (tags) is cheap, but not all tags require a workboard.

Was wondering if a boolean "has workboard" checkbox for certain projects (default set to: yes) like "tag projects that don't have teams" could be an idea. But might be complicated to implement (what happens when workboard was in use and gets disabled) plus same problem as above (same link goes to different views depending on project config).

In T89865#1065262, @Qgil wrote:

Do you agree with the new description, to be used in a report upstream?

Added the bullet about long load times due to the workdboard defaulting to all tasks.

That defaulting to all tasks is specific to our instance. I would rather
avoid putting too much stress on arguments on performance because they are
variable (i.e. the Multimedia workboard loads in a couple of seconds in my
laptop). But we can mention then, yes.

In T89865#1065479, @Aklapper wrote:

Was wondering if a boolean "has workboard" checkbox for certain projects (default set to: yes) like "tag projects that don't have teams" could be an idea. But might be complicated to implement (what happens when workboard was in use and gets disabled) plus same problem as above (same link goes to different views depending on project config).

To some extent that's how it works: projects don't have workboards until manually created, and if there is no workboard the profile page is still the default view (the original bug report was incorrect in that regard). There is no way to disable a workboard once it has been enabled, though (which is an antipattern in itself).

I think workboards as a default make sense when the project is small and there is no constant influx of new users unfamiliar with the interface. Which is exactly the kind of use case the Phabricator devs seem to be focusing on, and exactly not the kind of use case Wikimedia has (apart from some small subsets such as sprint projects). So this might be a hard sell upstream. If they could make it configurable somehow, that would be neat.

When you go to the /tag/project-name page , the Workboard icon in the left-hand column isn't highlighted, even though you're seeing the Workboard. I filed T90770, though I'd rather see the change reverted.

In T89865#1066105, @Qgil wrote:

That defaulting to all tasks is specific to our instance.

--> Handled in T90661

Discussion about "the future direction of project pages" is in https://secure.phabricator.com/T5558 so the reasons given there need to be taken into account if/when we upstream this task.

I can add that the new upstream navigation changes imposed several problems for the Sprint extension. Previously, defaulting to the Project Profile provided ready access to the "Action Menu". By going to the board by default, the icon view menu had to be changed in order to provide navigation to Sprint extension features available only on the Action menu. The /tag route is overridden and forced into the Sprint context to do this. Also, URL consistency in the icon nav menu was one reason why the /sprint URL was changed to /project/sprint.

IMO, the Project Profile should be routed from the Project Name URL and the /tag should go to the board. Right now, the Project Name URL goes to the default Project Board View controller, so no Sprint extension features are available there, but the /tag route goes to the Sprint context. The reasoning behind the /tag route going to the board is probably because of the event listener that creates the project tags and column position on the task. Would it make sense to have the /tag go to the Profile when there is a column position next to it? Also note that Open Tasks are no longer shown on the Profile, though, rather the Project Feed is shown instead. Yeah... the controller routing and intra application navigation in Phabricator Projects and Maniphest is not exactly well-defined. The design intent is probably to add the icon nav bar to Maniphest next.

Regarding, the filter all vs. filter open problem with boards, this default can be overridden by adding /query/open to the end of the board URL. Also, any custom query id can be added to show specific task types. I am not sure that I agree that "open tasks" should be the default query for boards. If you do not want to load the closed tasks, just hide the "Done" column, problem solved.

I ended up creating this task upstream: Default landing page for projects should be info + feed.

I felt that asing to revert the change was not enough, because I see the point of the change: project infor pages are very basic and workboards offer more information. This is why I have proposed project info + feeds, which are elements that any project alive has, and may offer interesting information the first time and every time you visit that page.

One other point that should be made clear is that if the consensus is to make the /tag route go somewhere other than the board, then this could easily be done downstream, because of the Sprint extension. No need to revert any upstream changes. In fact, any default routes in Phabricator can be overridden by any application that inherits from the PhabricatorApplication class and implements

getRoutes()

Is there a way to list all open tasks from a project, giving the project name as a parameter? I don't see any way to get a workable URL using search, advanced search or project page.

The current setup has broken the ability to give a list of open tasks from a project given the project name in the URL, see Link to list open tasks from the extension's page displays both open and closed tasks

This is a regression from Bugzilla

The change that corrects the default "all tasks" vs. "open tasks" issue T90661 was merged (https://gerrit.wikimedia.org/r/#/c/193679/2) nearly one month ago. Currently blocked by T89830 Once this is implemented, the https://phabricator.wikimedia.org/tag/$project_name path will default to open tasks, unless it is a Sprint project.

Looks like a rather trivial custom change to me (if I get it right):

diff --git a/src/applications/project/application/PhabricatorProjectApplication.php b/src/applications/project/application/PhabricatorProjectApplication.php
index 0a2ae19..7a09817 100644
--- a/src/applications/project/application/PhabricatorProjectApplication.php
+++ b/src/applications/project/application/PhabricatorProjectApplication.php
@@ -56,7 +56,7 @@ final class PhabricatorProjectApplication extends PhabricatorApplication {
         'feed/(?P<id>[1-9]\d*)/'
           => 'PhabricatorProjectFeedController',
         'view/(?P<id>[1-9]\d*)/'
-          => 'PhabricatorProjectViewController',
+          => 'PhabricatorProjectProfileController',
         'picture/(?P<id>[1-9]\d*)/'
           => 'PhabricatorProjectEditPictureController',
         'icon/(?P<id>[1-9]\d*)/'
@@ -88,7 +88,7 @@ final class PhabricatorProjectApplication extends PhabricatorApplication {
           => 'PhabricatorProjectWatchController',
       ),
       '/tag/' => array(
-        '(?P<slug>[^/]+)/' => 'PhabricatorProjectViewController',
+        '(?P<slug>[^/]+)/' => 'PhabricatorProjectProfileController',
         '(?P<slug>[^/]+)/board/' => 'PhabricatorProjectBoardViewController',
       ),
     );

I can imagine this might change again in upstream in the future, seeing the mockups for Projects v3. We will see.

In https://secure.phabricator.com/T7410#155337, @epriestley wrote:

After https://secure.phabricator.com/D15093, this should be a little better:

• Explicit Default Content: Project default content (profile vs workboard) is now explicit, so you can switch it back to "profile" if it's set to something else.
• Explicit Prompt: Creating a workboard now explicitly prompts you to make the workboard the default content view for the project. This should make that particular effect less surprising and more obvious.
• Hide Workboard Item: You can now hide the workboard menu item completely if you want, reducing the chance anyone will stumble into it.

it's now possible to customize the default project page on a per-project basis.

Actually, this is blocked by T127903 because there is no longer an intuitive way to list reports belonging to a project.

I don't know of a way to bulk edit them other than a manual sql query. That also does not fix newly created projects.

I think it's valid for some teams' projects to default to the workboard (e.g. sprints / "milestones" ) but most projects should surely default to the profile.

I don't know of a way to bulk edit them other than a manual sql query.

Sounds like a plan.

That also does not fix newly created projects.

Future projects should be handled by the upstream bug about unintentional creation of workboards, I guess.

I wonder if the project menu should be reset to have the default default when you disable a workboard and it's the default option.

In T89865#2057977, @Nemo_bis wrote:

Nice. Let's bulk-edit all projects to default to the profile.

I don't see why. I'm happy with our team projects defaulting to workboards. Most if not all sprint projects have very uninteresting profile pages, and definitely more interesting workboards. Etc.

I have been slightly disturbed when the links started to point to the workboard instead of the project profile page. I eventually got used it and in the end most of the time I really want to look at the workboard. If I want to reach the profile page, it is just one click away and the profile icon is conveniently the top one in the left sidebar.

So imho keep it as is, maybe communicate about it being a preference but we already have too much information flowing. Hopefully people willing to change their project will find this task and can self modify.

Thinking about this a bit more, the clever solution would be to take the user to the workboard if they are subscribed to the project, and to the project page otherwise.

In T89865#2494776, @Tgr wrote:

Thinking about this a bit more, the clever solution would be to take the user to the workboard if they are subscribed to the project, and to the project page otherwise.

That would be neat, however, I still think it should be per-project configurable but there should be a way to set the default for newly created projects (there currently isn't a way to do that)