Remove configuration step from new project onboarding flow

[jldec]

User experience testing has shown that most new users are not ready to learn about configuring their repo with a .gitpod.yml before opening their first workspace.

We should remove that step from the new project onboarding flow, but still give users access to the configuration page in the dashboard whenever they want to.

The suggested new project onboarding sequence is reduced to the following steps:

1. Select repo (and authorize GitHub app if necessary)
2. Select team or personal account (unless user or team context is already known)
3. Open workspace

Questions:

1. We dicusssed whether to keep auto-inferring a .gitpod.yml and triggering a prebuild (without showing the configuration page) and placing the file into the repo without committing it. This feels like a nice-to-have, given that new users are unlikely to understand it well enough the first time they open a workspace. Note that complications with this approach would also apply to Always Infer .gitpod.yml #6921.

2. There was a suggestion to show a page to announce successful creation of the project, with buttons to [Open Workspace] or go [Back to Dashboard]. This seems quite reasonable, and also useful to keep in mind for other future options like [Create another Project] or even an option to [Configure], but I would not make it a necessary part of this issue.

Related to #5785

[jldec]

/schedule

[roboquat]

@jldec: Issue scheduled in the meta team (WIP: 0)

In response to this:

/schedule

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[AlexTugarev]

@jldec, after re-reading this: Q2 is more of an alternative to the whole auto-inferring story, where we would not even try to automate anything. it would be the fastest way to start a workspace, though it would not contain any configuration file contributed. to try help users with the configuration we could refer to the docs on this "project created" page, perhaps even mentioning gp init.

[jankeromnes]

I'm very much in favour of entirely skipping the configuration page in the onboarding flow, but keeping the auto-inferred .gitpod.yml and dropping it untracked inside new Project workspaces (as we already do today).

I see no value in removing the auto-inferrence today.

[jldec]

I see no value in removing the auto-inferrence today.

Possible value of removing auto-inference

1. Some users are not left wondering why there may have been a prebuild once but then it didn't happen again
2. We move on to other issues ;) - this is relevant if there are complications with the headless auto-inference which may take longer to resolve.
3. No waiting for auto-inference, especially on repos where inference doesn't find anything
4. No waiting for prebuilds or looking at prebuild logs which sometimes feel stuck

Regarding the extra page at the end of project creation (Q2) - i think we'll need this going forward, because it's so useful to tell users what just happened and where they can go after that - I have created #7098 for that, and would prioritize separately from this.

[jankeromnes]

1. Some users are not left wondering why there may have been a prebuild once but then it didn't happen again

I don't think there is a case where there is a prebuild once and then not again. Either there are never any prebuilds (e.g. if we remove auto-inferrence), or there are always prebuilds on every change of the repository (current situation).

2. We move on to other issues ;) - this is relevant if there are complications with the headless auto-inference which may take longer to resolve.

Thankfully there is no complication there.

3. No waiting for auto-inference, especially on repos where inference doesn't find anything

Inference now happens in the background, as soon as a user selects a repository, and by the time they finish the project wizard, the config is already inferred. If you try Alex's PR, you likely won't notice any waiting.

4. No waiting for prebuilds or looking at prebuild logs which sometimes feel stuck

Interesting point. I think immediately starting a prebuild is helpful, but it's true that we could also skip this, and let users enable prebuilds later (e.g. via the UI or the IDE).

[jldec]

Thank you @jankeromnes and @AlexTugarev
I'm happy with those counterpoints :)

Also thanks for all the work in #7102 to resolve this.