# Problem For new users, the project page is a critical first experience. Right now it isn't well organized or prescriptive in directing users where to start. # Hypothesis We believe that by providing a view of important and useful actions as well as project-relevant continuous onboarding actions within the project page, we'll increase overall engagement with the product and success for our users. # Proposal Create a new section at the top of the project page and surface important actions and project-level continuous onboarding actions that the Conversion team has created. # Implementation Details: - [ ] The panel will have 2 states, one for owners and one for maintainers and developers. Guest and reporters will be excluded. - [ ] The panel is collapsible - The experimental approach will store the collapsed state on the client and not on the user. Upon experiment promotion, it would be an improvement to migrate this to be persisted in the database. # Actions | Panel Actions | URL/Behavior | Tracked as Part of the Experiment? | | ------ | ------ | ------- | | Upload a file | Same as existing `Upload File` option | Yes | | Create a new file | Same as existing `New file` option | Yes | | ~~Start with command line~~ | ~~Open new modal with CLI instructions~~ | ~~Yes~~ | | Invite your team | Open invite modal | Yes | | Create an issue | `/-/issues/new` | Yes | | Create a merge request| `/-/merge_requests/new` | Yes | | Set up CI/CD | `/-/ci/editor` | Yes | | Secure your project | `-/security/configuration` | Yes | | Add code owners | https://docs.gitlab.com/ee/user/project/code_owners.html#set-up-code-owners | Yes | | Add project integrations | `/-/settings/integrations` | Yes | # Experiment Summary <!-- Quick rundown of what is being done --> For a portion of newly created projects, we'll surface the helpful onboarding actions at the top of the project page. We'll track the completion of the actions we are driving in the control vs. candidate with the belief that we'll see stronger engagement in the candidate group. # UX Design https://gitlab.com/gitlab-org/gitlab/-/issues/329433/ [Figma specs](https://www.figma.com/file/cDpL49Tfy9oSRuId9uATpV/Project-overview-improvements?node-id=219%3A3871) | Empty (Owner) | Code added (Owner) | CL instructions modal | Empty (Developer) | Code added (developer) | Collapsed | |---------------|--------------------|-----------------------|-------------------|------------------------|-----------| | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mvc-empty-owner.png) | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mvc-code-added-owner.png) | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mvc-empty-owner--cl-instructions.png) | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mvc-empty-developer.png) | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mvc-code-added-developer.png) | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mvc-empty-owner--collapsed.png) | Clickable area when the section is collapsed:  ### Mobile designs | Empty (Owner) | Empty (Developer) | CL instructions | |---------------|-------------------|-----------------| | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mobile--owner.png) | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mobile--developer.png) | [](https://gitlab.com/gitlab-org/gitlab/-/issues/329433/designs/mobile--cl-modal.png) | # Experiment Design <!-- This should include the contexts that determine the reproducibility (stickiness) of an experiment. This means that if you want the same behavior for a user, the context would be user, or if you want all users when viewing a specific project, the context would be the project being viewed, etc. --> - Stickiness should be at the project level. - Initially limit the change to newly created projects. - Publish the project ID to the `experiment_subjects` table - Pass the project and nanmesapce IDs on the click events so they can be utilized in when they are not dropped at the collector # Rollout strategy <!-- This is currently called A/B test, which isn't accurate for multi-variants. Let's call this rollout strategy. It should outline the percentages for variants and if there's more than one step to this, each of those steps and the timing for those steps (e.g. 30 days after initial rollout). --> 50/50 AB test for newly created projects after the experiment is live # Inclusions and exclusions <!-- These would be the rules for which given context (and are limited to context or resolvable at experiment time details) is included or excluded from the test. An example of this would be to only run an experiment on groups less than N number of days old. --> Exclude projects created before the experiment is live # Segmentation <!-- Rules for always saying context with these criteria always get this variant. For instance, if you want to always give groups less than N number of days old the experiment experience, they are specified here. This is different from the exclusion rules above. --> # Tracking Details ### Events to Evaluate Panel Engagement | Actions | Event | Level | Source | Description | ------ | ------ | ------- |------- |------- | | Assignment| `assignment` | BE | | | View | `panel_viewed` | FE | |include label that determines which version was shown | | Upload a file | `panel_upload_file` | FE | | | | Create a new file | `panel_create_file` | FE | | | | Start with command line | `panel_command_line` | FE | | | | Invite your team | `panel_invite` | FE | | Create an issue | `panel_create_issue` | FE | | | | Create a merge request| `panel_merge_request` | FE | | | Set up CI/CD | `panel_cicd` | FE | | | | Secure your project | `panel_secure` | FE | | | | Add code owners | `panel_add_code_owners` | FE | | | | Add project integrations | `panel_project_integrations` | FE | | | | Collapse panel | `panel_collapse` | FE | | | | Expand panel | `panel_expand` | FE | | |