Contrib.social

GitLab Collaboration Workflow: Enable GitLab issues and forking into the 'issue' namespace, with shared access across the community

Open on Drupal.org →
Created on 23 November 2021, over 3 years ago
Updated 15 May 2023, almost 2 years ago

Problem/Motivation

The core of the GitLab Acceleration initiative is unlocking our self-hosted GitLab’s full feature set on git.drupalcode.org to provide collaboration tools that match the expectations of developers familiar with tools like GitHub.com and GitLab.com. The scope of this issue is to enable GitLab issues, and establish a fork/merge-request workflow for Drupal projects.

However, we also want to preserve Drupal’s culture of collaboration. In the Drupal project we encourage developers to work together on issues, and strive to avoid the proliferation of many forks and work being siloed in different places.

Requirements

  • People should be able to begin the collaboration process from any of the places these contribution tools allows:
    • Beginning with an issue
    • Beginning with GitLab’s WebIDE while browsing a repository
    • Beginning with a fork
    • Beginning with someone else's issue/fork/merge request
  • People should be able to collaborate on a single solution (the same fork/branch/merge request)
    • When more than one person wants to collaborate on the same solution, they should not be required to each make separate forks and separate merge requests
    • People should not have to wait for a maintainer or collaborator to grant access to update an issue, propose a code change, or to perform other work toward resolving issues
    • Maintainers must be able to collaborate on the merge requests to their projects (not just whether or not to merge, but the underlying fork/branch the merge is coming from)

Preferred Solution: Shared Issue Workspace

Resolved blocker: Bug in Gitlab with forking into shared namespaces with the Developer role.

  • All users will have permissions to fork a project into the issue forks group on git.drupalcode.org. GitLab’s UI is designed for using forks - for example, if you do not have access to edit a file, GitLab prompts to create a fork
  • All users will be granted the 'Developer' role within the issue forks group, granting them access to collaborate by default (unlike GitHub.com or GitLab.com where the fork owner must grant access to collaborators) 📌 Give everyone with git.drupalcode.org commit access to all issue forks Closed: won't fix
  • GitLab issues will be enabled for the canonical projects. A migration script will be written to migrate existing issues from Drupal.org to GitLab issues ✨ Move issues from www.drupal.org to git.drupalcode.org Postponed
  • GitLab issues will be disabled for the forks. This is to encourage users to open issues in the canonical project queue.

Alternate Solution: Personal Namespaces

  • All users will have permissions to fork a project into the issue forks their personal namespace on
    git.drupalcode.org. GitLab’s UI is designed for using forks - for example, if you do not have access to edit
    a file, GitLab prompts to create a fork
  • When a fork is created in a personal namespace, an automated process will grant all users on
    git.drupalcode.org the GitLab 'Developer' role on that fork, so they can collaborate.
    • Unlike on GitLab or GitHub, these forks will be collaborative by default
    • The fork owner may choose to remove that access
  • GitLab issues will be enabled for the canonical projects
    • A migration script will be written to migrate existing issues from Drupal.org to GitLab issues
    • Metadata will be migrated into labels in GitLab.
  • GitLab issues will be disabled for the personal forks
    • This is to encourage users to open issues in the canonical project queue.
  • Project pages and packaging remain on Drupal.org
    • This should help prevent a fork from being promoted as the canonical source for a Drupal project
    • It also ensures we're only advertising the canonical projects to Packagist/Composer.

Definitions

  • Canonical project - a project on Drupal.org that has releases, maintainers, a canonical GitLab project, etc. 
    • Canonical projects are the only ones that appear on Drupal.org project listings and in the composer endpoints. 
  • Group - a collection of projects in Gitlab with its own namespace
    • Groups can define common labels, permissions and other settings for the projects they contain. 
    • Canonical projects live in the 'project' namespace: git.drupalcode.org/project. 
    • Issue forks live in the 'issue' namespace: git.drupalcode.org/issue
      These are forks of the canonical projects where contributors collaborate.
  • Issue forks - a fork of a project created in the Issue group on

Implementation

📌 Give everyone with git.drupalcode.org commit access to all issue forks Closed: won't fix can be done at any point, sooner is better, to get the current Drupal.org issue workflow closer to the future workflow.

#3317273: Set up a Drupal.org GitLab issues bot → to handle comments commanding the bot to create an issue fork, and giving people information about how to contribute to issue forks.

🌱 Plan
Status

Active

Component

GitLab

Created by

🇺🇸United States irinaz

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024