Enable seamless integration between GitLab and 3rd party products as well as make GitLab products available on cloud service providers’ marketplaces, expanding GitLab market opportunities.
The Ecosystem team is responsible for design, build, and maintain -
The following people are permanent members of the Ecosystem Team:
|Nick Nguyen||Engineering Manager, Ecosystem|
|Arturo Herrero||Senior Backend Engineer, Ecosystem|
|Andy Soiron||Senior Backend Engineer, Ecosystem|
|Justin Ho||Senior Frontend Engineer, Ecosystem|
The following members of other functional teams are our stable counterparts:
|Patrick Deuley||Senior Product Manager, Ecosystem|
Whenever possible, we prefer to communicate asynchronously using issues, merge requests, and Slack. However, face-to-face meetings are useful to establish personal connection and to address items that would be more efficiently discussed synchronously such as blockers.
We use the following issue boards to prioritize and track our work.
As a brand new team with engineers still onboarding, we are still discussing and experimenting with the best way to handle estimation/weighting of issues. This ongoing discussion can be found here. We have adopted the weighting system used by other GitLab teams such as Memory, Geo, and Plan:Project Management. From the 12.4 milestone to 12.6, engineers will assign weights after an issue is completed to help us establish a baseline. After that we will assign weights to backlog items in order to assist with scheduling work.
|1: Trivial||The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required.
Examples are documentation updates, simple regressions, and other bugs that have already been investigated and discussed and can be fixed with a few lines of code, or technical debt that we know exactly how to address, but just haven't found time for yet.
|2: Small||The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution. Few surprises are expected, if any, and no coordination with other teams or people is required.
Examples are simple features, like a new API endpoint to expose existing data or functionality, or regular bugs or performance issues where some investigation has already taken place.
|3: Medium||Features that are well understood and relatively straightforward. A solution will be outlined, and most edge cases will be considered, but some extra investigation will be required to realize the solution. Some surprises are expected, and coordination with other teams or people may be required.
Bugs that are relatively poorly understood and may not yet have a suggested solution. Significant investigation will definitely be required, but the expectation is that once the problem is found, a solution should be relatively straightforward.
Examples are regular features, potentially with a backend and frontend component, or most bugs or performance issues.
|5: Large||Features that are well understood, but known to be hard. A solution will be outlined, and major edge cases will be considered, but extra investigation will definitely be required to realize the solution. Many surprises are expected, and coordination with other teams or people is likely required.
Bugs that are very poorly understood, and will not have a suggested solution. Significant investigation will be required, and once the problem is found, a solution may not be straightforward.
Examples are large features with a backend and frontend component, or bugs or performance issues that have seen some initial investigation but have not yet been reproduced or otherwise "figured out".
Anything larger than 5 should be broken down.