Integrations Think Big / Think Small Exercise

(Think Big) If we wanted to add 10, 20, or 100 new native integrations per year, what would we need to do differently?

Over the past few years, the Ecosystem:Integrations team has touched roughly 5-6 integrations. We've spent a significant effort on Jira and Slack and we continue to focus on those integrations. However, we know that long-term we want to scale our team to build a more expansive ecosystem. What would you envision us doing differently to grow our Ecosystem to support 10, 20, or 100 native integrations per year?

(Think Small) What is the first smallest possible thing we can do to achieve this?

We've discussed the DSL for making it easier for developers internal/external to contribute to our integrations - this is an awesome start! How might we expand on these ideas and start small to achieve our Think Big objectives?

General Feedback

If you have any other thoughts/discussion, share that in a separate section of your comment.

Instructions

• See discussion in meeting notes or view the recording.
• Consider 3-5 ideas to share for Think Big and then for Think Small.
• Create your own thread with your ideas and engage on 1-2 other comments (minimum) to let others know where you agree or where you may have different opinions and engage in some open/thoughtful dialog.
• Please share your response by May 6th EOW.
• Feel free to have a little fun with it!

Comment Template:

## Think Big
1.
1.
1.
1.
1.

## Think Small
1.
1.
1.
1.
1.

## General Feedback
1.
1.

Summary of Feedback / Conclusions

Think Big

• A common theme is that for us to truly scale, we can't be entirely responsible for building and supporting each new integration. We would need to enable and incentivize contributors and/or revisit some of our policies on 3rd party marketplaces and plugins.
• We identified that there could be multiple classes of integrations - 1. Native integrations that are deeply integrated into the GitLab Product 2. GitLab Apps (I'll use this term as a placeholder), which would be lower maintenance "integrations-as-data".
• We all agree there's a large barrier to entry for contributors, a primary reason cited is the requirement for developers to know Ruby, but also the fact they must interact with our code to define an integration. The DSL, Rails Generators, and integrations-as-data appear to be examples of making it easier to interact with our code or entirely abstract it, but there could be other opportunities to consider based on the problem statement.
• There are also opportunities when it comes to the DX/UX for contributors and consumers. One example is how GitHub or Bitbucket integrations can easily be configured via a UI. We could develop a guided workflow for contributors, such as integration partners, that would be an incentive and ease the burden of effort for initiating the process. For consumers, there's opportunity to improve the experience of using our integrations via a catalog/search function. We could likely increase the awareness around our integrations by exploring this further.

Think Small

• In the short term, there are opportunities to improve our Development Efficiency. We could automate our development with Rails generators, rake tasks, linters, and test automation tools.
• We could enable webhooks to support custom payloads, to speed up development of basic webhook integrations.
• While not mentioned here, we are already focused on developing a DSL for our integrations, that will abstract some of the complexity for contributors who want to build GitLab integrations, as well as improving our own efficiency.
• If we are able to focus in on a particular category of integrations (such as issue trackers) in the short term, we could learn more about the patterns and identify efficiencies more quickly than if we are context switching.

Proposed Actions

• Share out discussion issue on Avoiding Marketplaces & Plugins - @g.hickman
• Develop an MVC proposal for integrations-as-data approach - @alexkalderimis @sgregory2
• Develop MVC proposal for adding custom payload support to webhooks - @toupeira 👉 #362504 (closed)
• Add a discussion / demo of rails generators to a future bi-weekly meeting - volunteers?