GitLab Delivery: Self Managed

Overview

Self Managed team is focused on installation and upgrade mechanisms to ensure smooth deployments. This includes system integration, scripting, templating, and related configuration management tooling.

Team members

The following people are members of the team:

Name	Role
Peter Lu	Backend Engineering Manager, Distribution:Deploy
Clemens Beck	Distribution Engineer, Distribution:Deploy
Hossein Pursultani	Senior Distribution Engineer, Distribution:Deploy
Jason Plum	Staff Distribution Engineer, Distribution:Deploy
João Alexandre Prado Tavares Cunha	Senior Distribution Engineer, Distribution:Deploy
Jon Doveston	Distribution Engineer, Distribution:Deploy
Lucas Li	Distribution Engineer, Distribution:Deploy

Working with the community

The installation and upgrade process is the first feature that all system administrators experience when working with GitLab. As a result, the projects managed by the Self Managed team have a high level of engagement by the user-base. The GitLab community is made up of more than just code contributors; users logging issues and feature requests are constantly pushing us forward and helping create a better experience.

We strive for the following in our public projects:

1. Uphold our Community Code of Conduct.
2. Enable GitLab’s mission that everyone can contribute..
3. Show our work in public.
4. Recognize and thank contributors for their work.
5. Respect contributors donated time by providing a timely review turnaround time.

Working with Open Source communities

The open core of GitLab is built on top of thousands of open source dependencies. These dependencies and their communities are important to the GitLab strategy, and working with these dependencies is an essential part of the projects the team maintains.

We strive to:

1. Consider the impact of our work on the open source communities that we benefit from.
2. Promote the importance of these open source communities within GitLab.
3. Raise issue with any decision that goes against our stewardship promises.
4. Find opportunities to contribute back the changes we make.

Public by default

All work carried out by the team is public. Some exceptions apply:

• Work has possible security implications - If during the course of work security concerns are no longer valid, it is expected for this work to become public.
• Work is done with a third party - Only when a third party requests that the work is not public.
• Work has financial implications - Unless financial details can be omitted from the work.
• Work has legal implications - Unless legal details can be omitted from the work.

Some of the team work is carried out on our development server at dev.gitlab.org. Infrastructure overview document lists the reasons.

Unless your work is related to the security, all other work is carried out in projects on GitLab.com. If you need to submit a sensitive issue, please use confidential issues.

If you are unsure whether something needs to remain private, check with the team Engineering Manager.

Work/life harmony

Working all-remote and asynchronous first offer flexibility in how team members approach their workday. Team members must make choices on how best to balance work time with other areas of life.

For new team members, the following resources provide examples on how to focus their time:

• How team members approach their day
• Blog post: A day in life of a remote worker
• The option of a non-linear workday
• GitLab handbook: Work/life Harmony

The following GitLab Handbook areas are key in maintaining a healthy work/life balance.

• Family and Friends First, work second
• Combating burnout, isolation, and anxiety in the remote workplace
• Recognizing Burnout

View page source - Edit this page - please contribute.