Epic: Improve Community Contributor Experience

This epic is a placeholder that captures the improvements we'd like to do as part of making it easier for everyone to contribute to Gitpod.

Objective 🥅

Guide community contributors step-by-step from opening a pull request to merging a contribution, while leveraging a combination of automation (see gitbot, etc) and interactions with the Gitpod team members that would streamline the community contribution process.

Problem to solve ❗

1. Docs: There's no CONTRIBUTING.md file for the main repository (gitpod-io/gitpod) and this makes it difficult to discover how and where one can start for contributing to Gitpod.
2. Welcoming: Even if someone jumps right into opening a pull request for fixing a bug or a typo, there's no welcoming message that describes the process or where to reach out for getting help, a code review, or forwarding the contribution to the right team.
3. Preview Environments: There's a security risk in providing everyone access to the same clusters that handle preview environments for the Gitpod team. This is a common issue with other similar projects and communities like GitLab.
4. DRIs: Incoming community contributions can sometimes go unnoticed for longer periods as there are no DRIs (Directly Responsible Individuals) for helping with community contributions. See https://github.com/pulls?q=is%3Aopen+is%3Apr+archived%3Afalse+label%3A%22community-contribution%22+user%3Agitpod-io+.
5. Labels and Workflows: Introducing appropriate labels and triage automations that surface community contributions or looping in appropriate team members to help out is needed in order to improve visibility of PRs and scale how we handle incoming community contributions in the long run.
6. Contributor License: All contributions subject to the CLA (Contributor License Agreement). Individual contributions are subject to the Individual CLA while corporate contributions are subject to the Corporate CLA. However, signing the CLA is a) still a manual process as it requires back and forth between team members and the community contributor and b) not visible to other team members that may want to merge a contribution.

Proposal 🗺️

The following items contain a brief overview of ideas that have been discussed before and could potentially improve the community contributor experience for Gitpod as a first iteration. Thanks everyone for opening the associated issues linked below.

• 1. Introduce a basic CONTRIBUTING.md doc that guides community member on how to contribute using minikube, a tool that lets you run Kubernetes locally. See https://github.com/gitpod-io/gitpod/issues/5258.
• 2. Document the areas someone can contribute to. This could include highlighting the main repository, documentation, template projects, and more. See https://github.com/gitpod-io/gitpod/issues/5618.
• 3. Introduce a welcoming messaging that is automatically posted on community contributions (PRs). This could include how and where to ask for help, etc.
• 4. Improve PR visibility for community contributions. The first iteration of this could include automatically adding the "community contribution" label on PRs from community contributors. See https://github.com/gitpod-io/gitbot/issues/34.
• 5. Investigate if it's possible and secure to give access to preview environments to community contributors by separating preview environments from the werft cluster. See https://github.com/gitpod-io/security/issues/9 (internal).
• 6. Automate CLA signing from individuals and corporations to limit back and forth between team members and community contributors regarding CLA. See https://github.com/gitpod-io/gitpod/pull/6318 and https://github.com/gitpod-io/ops/issues/130 (internal).
• 7. Add contributing guidelines with a local kubernetes cluster or minikube. See https://github.com/gitpod-io/gitpod/issues/6563.
• 8. Create a way to install a basic version of self-hosted Gitpod on a local machine for trial purposes. See https://github.com/gitpod-io/gitpod/issues/9075.

Next steps

Next steps ideas could include:

1. Introducing a volunteer role for our team that is responsible for helping contributors to get their pull requests to meet some contribution acceptance criteria, help find and assign pull requests to available reviewers, pick up and finish stale contributions, and more.
2. Automatically forwarding new PRs from the community internally in dedicated slack channel(s) to improve PR visibility within the team.
3. Regularly surface pending or stale community contributions internally in dedicated slack channel(s) to improve PR visibility within the team.
4. Now that the new product engineering structure is in place and we do automatically associate team labels in PRs[1], each team could document a process for going through community PRs.
5. ...

Start by reviewing the linked issues for CONTRIBUTING.md, contribution-area documentation, Gitbot labeling, preview-environment security, CLA automation, and local self-hosted installation. This epic has no single implementation entry point; done would require completing and coordinating the selected contributor-experience improvements across the referenced repositories and workflows.