This problem is more relevant now that project tags and search suggestions point to workboards by default, instead of the default project page as before.

Those workboards created just because where not in the way (unless you explicitly clicked their links). Now I also find them just too often, for no benefit.

(Just for context, we have been discussing this decision to defaulting to workboards for project links -- see the ongoing discussion at https://phabricator.wikimedia.org/T89865 )

Just to make sure we're on the same page, here's the expected behavior:

• Projects default to project information.
• Projects do not have workboards by default.
• If a user explicitly chooses to create a workboard by browsing to the workboard view and clicking a "Create Workboard" button, that creates one.
• Projects with workboards default to the workboard view.

If you're seeing behavior contrary to that, it's a bug.

Since I think that's working correctly, I assume the major issue here is:

• Users who don't realize how this interaction works are clicking the button without understanding the implications, and accidentally adding useless workboards to projects where they don't make much sense, which impacts other users because this becomes the default view.

Is that essentially accurate?

(A secondary issue is that workboards with thousands of cards on them don't, e.g., paginate columns, but it sounds like all such boards are accidental so this is probably isn't a priority to fix.)

Some approaches on this:

• T6502 discusses separating out a workboard permission on projects. This permission would also limit who could create a workboard.
• We can reexamine the prompt text. I think it was written before we added this side effect and presumably isn't as clear as it could be about the consequences.
• T5602 discusses adding flags to disable project features. We could add a "This project doesn't have a workboard" flag. However, I'd like to see the measures above fail to resolve the issue before we pursue such a flag, because all of the T5602 use cases are very weak.

We are very unlikely to add a way to delete workboard or columns without CLI access. Like all other applications/objects, it's intentional that users (including administrators) can not permanently destroy data (except in very rare cases).

My rough hope for the future was allowing Project "apps" to be enabled/disabled, which would make the links go away. So you'd have by default "Calendar" "Tasks" "Workboards" (maybe "Wiki") as enabled, and if you could edit the project, you could turn those items off with a checkbox, and they just wouldn't exist for that project.

In T7410#99080, @epriestley wrote:

If you're seeing behavior contrary to that, it's a bug.

No, we are talking about the expected behavior.

Since I think that's working correctly, I assume the major issue here is:

• Users who don't realize how this interaction works are clicking the button without understanding the implications, and accidentally adding useless workboards to projects where they don't make much sense, which impacts other users because this becomes the default view.

Is that essentially accurate?

Yep.

I'm just going to give our use case for being able to disable workboards. We created workboards on some projects where work was done (let's call it Ops), but after some restructuring (yay) the ops department became split into teams. We still want to preserve the Ops tag to show that the work is ops-related, but we are now using #teamawesome workboards instead. Now issues are showing up as on the (backlog) on the ops-project workboard, while they will actually never be moved on that board. It is mainly a cosmetic thing, but it does cause some confusion for our users as well.
It would be cool if you could disable the workboard - the UI for it could just be that you end up on the workboard page with a text saying "This workboard is disabled" and if you have edit permissions on the project you can enable it again. If the workboard is disabled the column assignments would not show up on Maniphest tasks anymore.
We do not really have a need to remove them from the database, though.

+1 to the ability to delete, disable, or hide workboards.

We have projects which used to track workflow, but are no longer used that way. They still show a workboard, whereas we really want them to show the project description, which explains why there is no workboard.

Perhaps an alternative would be to allow a workboard to have zero columns, and in that case, display the project description instead.

This has nothing to do with creating workboards. Should this request be split out to a new task?

"Making the effects ... more reversible" is the same as "deleting, disabling or hiding workboards"; they are not separate tasks.

I think this bug was unnecessarily morphed into something unrealistically complex. Deletion of workboards would solve most issues and it would be easy to address

it's intentional that users (including administrators) can not permanently destroy data

by setting some limit (default e.g. 0) on the pieces of information one can destroy. If the workboard has all items in a single column, its information content is 0.

its information content is 0.

It's not: the column has a name, position, history, configuration (e.g., maximum points), and triggers after T5474.

It's not: the column has a name, position, history, configuration (e.g., maximum points), and triggers

All such non-default items can be counted. If they're <= N, allow deletion.

Aside from affecting the default view of a project, it also affects individual task pages.

Lots of Wikimedia tasks now have projects associated with them that incorrectly suggest to users that a task is in the backlog. This is due to lots of generic "tag" or "umbrella" type projects now having a default "Backlog" workboard. Task pages reflect this with a confusing " (Backlog)" mention behind each project. This makes it harder to separate signal from noise. E.g. https://phabricator.wikimedia.org/T105162:

Previously this looked much cleaner:

Yep that was my main problem with it and really still is even though I am
now using workboards properly. It's just information that isn't needed imo.

After 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.

There is still no way to hide the "(Backlog)" column flag on tasks if a workboard was created that doesn't make sense (or no longer makes sense). I plan to add a "Disable Workboard" workflow which will mostly pretend no one ever created the workboard in the first place and hide the "(Backlog)" flag, but may not get to that immediately.

@epriestley this is already a vast improvement, thanx for D15093: Migrate existing projects to retain "Workboard" as default item.