Support the seamless integration between GitLab and 3rd party products and services, expanding GitLab's market opportunities by empowering developers to contribute.
The Ecosystem team is responsible for designing, building, and maintaining:
The following people are permanent members of the Ecosystem Team:
The following members of other functional teams are our stable counterparts:
|Patrick Deuley||Senior Product Manager, Ecosystem|
|Libor Vanc||Senior Product Designer, Ecosystem:Integrations|
|Mike Greiling||Senior Frontend Engineer, Ecosystem|
|Lukas Eipert||Frontend Engineering Manager, Ecosystem|
|Ash McKenzie||Staff Backend Engineer, Ecosystem|
|Arturo Herrero||Senior Backend Engineer, Ecosystem|
|Andy Soiron||Senior Backend Engineer, Ecosystem|
|Justin Ho||Senior Frontend Engineer, 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.
:thumbs_up:to agree, or start a discussion to refine the weight.
|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.