Skip to content

DRAFT: Make first-time contribution doc easier for first-time contributors

What does this MR do and why?

Edit and reorganize Tutorial: Make a GitLab contribution to make it easier for first-time contributors.

This is the first among a series of edits I have planned or in process.

Changes in this MR:

  • test and copy edit first_contribution
    • new heading to describe the two options
    • separated the Gitpod and GDK steps into distinct H3
    • more strongly highlight Gitpod + Community fork
  • repeatable steps for GDK

This is the first in a multi-stage process. Future MRs:

  • suggest quick changes use Community Fork and Web IDE: gitlab-community/gitlab!16 (closed)
  • GDK-in-a-box
  • GDK troubleshooting needs to go somewhere else, even if it's at the end of the page
    • marking as resolved in gitlab-community/gitlab!16 (closed) for now, but I think the greater issue here is that the GDK docs are spread around and could use some consolidation.
  • re-organize into multi-page guide: gitlab-community/gitlab!16 (closed)
  • Contributor landing page?
    • "I want to":
      • correct something in the code (quick change)
      • add a feature (Gitpod or GDK)
      • file an issue
      • assign myself a specific MR
      • find an MR to help with

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Related to #

Edited by Edward Angert

Merge request reports