Move project removal action under project settings

[gtsiolis]

Problem

Project settings were recently introduced with incremental prebuilds settings in #7031 (Cc @jankeromnes @geropl) but currently the only way to remove a project can happen through the project more actions button on the projects list as the product didn't have project settings when the project removal action was added in #6185.

Proposal

Naturally, such actions are better fit under project settings, so moving this action under project settings seems optimal.

Let's add this below incremental prebuilds section under general settings.

Section title: Remove Project
Section description: Removing this project will also remove all associated data with this project, including workspaces.

Ideally, once we implement #5517, prebuilds and prebuilds configuration could be also removed and disabled. See also #7009. 💡

[jankeromnes]

Should the project removal also have a confirmation prompt (e.g. where it says "Type my-project:"), or can it happen immediately like the current removal feature?

[JanKoehnlein]

@jldec do we need visual design for this or can this be scheduled as is?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[geropl]

@gtsiolis I'm trying to understand what status this is in. Do I understand correctly that:

• the design thinking is done
• we "just" need to execute on it? 🤔
  If yes: Then I'd like to move it from "In progress" to our (grouped) Backlog, so a) it does not clutter groundwork, and b) still remains visible.

[gtsiolis]

@geropl you're right on the comment in #7273 (comment)! Let me also grab this opportunity to break down the design thinking behind the current status from UX perspective in case it helps. 💭

1️⃣ The issue does not have the ~needs visual design label or exist in the product design board, which helps make it clearer that this issue does not require any further design input before picking it up for implementation, unless you think it could use some clarification before opening a PR.

2️⃣ IMO, This is one of the issues that does not necesarily need design specs in Figma as 🅰️ it specs can be clearly expressed using text by reusing existing patterns (see proposal in the issue description) and 🅱️ it allows some room for improvization or creative thinking from engineering perspective for things that could have been also missed from design perspective. In the past, we've picked up many issues without a design spec file or clear proposal in the issue before which is ok, as long as the overhead during the code review is not expected to keep the PR open for long.

3️⃣ From design perspective the first iteration (skateboard) of this is clearly outlined in the proposal in the issue description:

Let's add this below incremental prebuilds section under general settings.

Section title: Remove Project
Section description: Removing this project will also remove all associated data with this project, including workspaces.

4️⃣ The last point in the proposal can be considered out of the scope of the issue or could up for discussion. Open to feedback or thoughts!

Ideally, once we implement #5517, prebuilds and prebuilds configuration could be also removed and disabled.

---

To add some clarification for points 1️⃣ and 2️⃣, this is what the final design could look like. Everyone is encouraged to ask questions for clarifications if a text-based proposal is not clear enough or not easy to visualize beforehand. See relevant section in the product design team page (internal).

BEFORE	AFTER

Also, the confirmation modal on project removal already exists when removing a project from the team page which contains the projects cards. We can safely re-use the same confirmation modal here.

Remove project from team page	Remove project from project settings

---

Looping in (no-action-required) the following product teams that have worked in the past with @gitpod-io/product-design as the above could help add some clarification on how we work:

• @gitpod-io/engineering-webapp
• @gitpod-io/engineering-ide
• @gitpod-io/engineering-self-hosted
• @gitpod-io/engineering-workspace

---

fyi: In the spirit of adding more clarification on point 2️⃣, I've added the following section (internal) about design specifications on the product design team page.

Specifications

When working with design specifications for a solution, the contents of the design file are considered to be the single source of truth (SSOT) of the proposal which can be also exported and uploaded in an issue comment or within the issue description.

In the spirit of our core value to ship skateboards, we lean towards shipping the minimum viable change (MVC) to improve the user's outcome. This includes also trusting each other to pick up issues to work on with minimal design specifications that may contain only a brief outline of the solution using a text-based description by referring to existing and reusable patterns or components. In such cases, designs can be evaluated during code review and help avoid blocking the team from implementing a solution that adds value and can be shipped to users.

[gtsiolis]

Closing this as it has been resolved in #15316. Cc @selfcontained @jldec