Evaluate developer documentation and guardrails for contributing to the charts project
Overview
When other teams at GitLab introduce a new feature or service that requires changes to GitLab's configuration files, the Distribution team has experienced that they get MRs from other teams for Omnibus, but not for the Helm charts.
Problem
There are a number of problems with this.
- The Distribution team becomes responsible for doing the work to support the feature in the charts
- There is potential for the Distribution team to become a bottleneck for adding features that are important to other teams and end users
- There may be a lag between a capability being available in Omnibus installs and that same capability being available in Helm-based installs
- Helm users are disadvantaged by the lag, which may impede adoption of the Helm install method
Proposal
- Make it easier for other teams to contribute changes to the charts by identifying ways to improve the developer documentation and enable contributions
- Make it safer for other teams to contribute changes to the charts by implementing more checks and guardrails for code contributions
This would be a great exercise for a newer member of the Distribution team who has a fresh perspective on the developer docs and has recently experienced making their first contribution to the Charts project. The Database team recently submitted an MR for the charts and may also have feedback on the developer docs.
Value
- Developers across GitLab have the opportunity to build Kubernetes and Helm expertise
- Eliminates the lag for functionality being added to the Helm charts
- Frees up the Distribution team to focus on bigger improvements to the Helm charts
- In addition to making it easier for other GitLab teams to contribute, it would make it easier for the broader community to contribute
Reference
Edited by 🤖 GitLab Bot 🤖