[go: up one dir, main page]
Skip to content

Draft: Official Support of go-gitlab Client Library

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Context

The maintainer of go-gitlab is interested in transferring ownership of the library to GitLab, where GitLab would become the official maintainer. The objective of this issue is to identify if there's a business case for providing support, and if so, who would be DRI or what GitLab may need structurally to provide consistent maintainership.

Questions to be answered

  1. What is the current state of the relationship between go-gitlab and GitLab? How involved are we today in contributing? how many maintainers do we already have? How much effort has this required to date (identify issues as examples)?

  2. What is the impetus for the request to transfer ownership? What led to this? Are there alternative maintainers who may be interested in owning the library? Are there measures we could take to ease the burden without taking ownership officially?

  3. What is the impact/outcome if GitLab is unable to support go-gitlab at this time?

  4. We recently took ownership of GLab * GitLab CLI Tool, which also depends on go-gitlab. What were the factors in this decision? What has been the experience thus far? How much effort has been required? How much is anticipated (such as for major API updates)? What business results have been impacted by this decision? Are there other tools/libraries like GLab that we're already officially supporting in GitLab? Do we have central documentation, handbook pages, or guidance around this?

  5. We also support the GitLab Terraform Provider in some capacity. Can we document our current support scope, effort required, and business impacts?

  6. How many customers/users depend on go-gitlab and how does that compare to other interfaces into our APIs (such as REST, GraphQL, CLI, GLab, and other libraries/SDKs)?

  7. What is the anticipated capacity required to support go-gitlab on a monthly/annual basis (in engineering days)?

  8. What additional support requirements may be needed beyond development alone (such as Documentation, Community Support, Testing, Code Samples)?

  9. What is the added value of GitLab supporting a library like this (vs providing support to maintainers)? Who benefits and how?

  10. What is the scope of support for go-gitlab? Does it include Authentication, Caching, Retries, Analytics, Error Handling/Validation, ..? Would we stop at client library or why not support a full fledged SDK? How far off is it from that?

  11. Is this effort in scope for Ecosystem:Integrations Direction?

  12. Is this in scope for GitLab's Direction as a whole? If so, why aren't we already supporting additional libraries/SDKs wholesale? Why now?

  13. What are the risks/implications of taking ownership?

  14. Where might we anticipate the most significant challenges when supporting a library?

  15. Is this decision easily reversible?

  16. Are there benefits to intentionally allowing the open source community to own libraries like this versus GitLab?

  17. Are there any critical components, systems, processes that need to be in place before supporting a client library? For example, solving API First, REST vs GraphQL, and automated tooling/documentation first? How might supporting go-gitlab detract from those priorities, or how might it align/benefit those efforts?

Participation

To make a decision like this, let's include diverse feedback from different levels of the org, as well as external customers:

  • 2 Engineering Managers
  • 2 Engineering Directors
  • 2 Product Managers (excluding myself)
  • 2 Group Product Managers
  • 3-5 Customers or API Users

Timeline

Currently paused as we're focused on other priorities.

Edited by 🤖 GitLab Bot 🤖