## How to become a contributor and submit your own code
The Kubernetes Helm project accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted.
### Contributor License Agreements
## Contributor License Agreements
We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
...
@@ -15,7 +15,16 @@ Follow either of the two links above to access the appropriate CLA and instructi
...
@@ -15,7 +15,16 @@ Follow either of the two links above to access the appropriate CLA and instructi
***NOTE***: Only original source code from you and other people that have signed the CLA can be accepted into the main repository.
***NOTE***: Only original source code from you and other people that have signed the CLA can be accepted into the main repository.
### Contributing A Patch
## Order of Development
The project uses a combination of milestones and priority labels on GitHub issues to help development flow smoothly. While exceptions may be required on occasion, the team observes the following guidelines:
* PRs should only be submitted for issues in the current milestone. PRs for other milestones will not be reviewed or merged until the milestone for the issue(s) they address has started.
* PRs should be submitted more or less in issue priority order, with the caveat that because different issues may take different amounts of time to work, PRs may arrive out of order at times. However, lower priority PRs may not be reviewed or merged until higher priority PRs have been processed, and the review or merging of lower priority PRs may be interrupted by the arrival of higher priority PRs.
## How to Contribute A Patch
### Overview
1. Submit an issue describing your proposed change to the repo in question.
1. Submit an issue describing your proposed change to the repo in question.
1. The repo owner will respond to your issue promptly.
1. The repo owner will respond to your issue promptly.
...
@@ -23,3 +32,41 @@ Follow either of the two links above to access the appropriate CLA and instructi
...
@@ -23,3 +32,41 @@ Follow either of the two links above to access the appropriate CLA and instructi
1. Fork the desired repo, develop and test your code changes.
1. Fork the desired repo, develop and test your code changes.
1. Submit a pull request.
1. Submit a pull request.
### Design Document
If the change you are proposing is substantial, before opening a pull request, ensure you reference a design document that can be discussed in the open.
### Single Issue
When fixing or implementing a GitHub issue, resist the temptation to refactor nearby code or to fix that potential bug you noticed. Instead, open a new pull request just for that change.
It's hard to reach agreement on the merit of a PR when it isn't focused. Keeping concerns separated allows pull requests to be tested, reviewed, and merged more quickly.
Squash and rebase the commit or commits in your pull request into logical units of work with `git`. Include tests and documentation changes in the same commit, so that a revert would remove all traces of the feature or fix.
Most pull requests will reference a GitHub issue. In the PR description–not in the commit itself–include a line such as "Closes #1234". The issue referenced will then be closed when your PR is merged.
### Include Tests & Documentation
If you change or add functionality, your changes should include the necessary tests to prove that it works. While working on local code changes, always run the tests. Any change that could affect a user's experience also needs a change or addition to the relevant documentation.
Pull requests that do not include sufficient tests or documentation will be rejected.
### Code Standards
Go code should always be run through `gofmt` on the default settings. Lines of code may be up to 99 characters long. Documentation strings and tests are required for all public methods. Use of third-party go packages should be minimal, but when doing so, vendor code using [Glide](http://glide.sh/).
### Merge Approval
Helm collaborators may add "LGTM" (Looks Good To Me) or an equivalent comment to indicate that a PR is acceptable. Any code change (other than a simple typo fix or one-line documentation change) requires at least one LGTM. No pull requests can be merged until at least one Helm collaborator signs off with an LGTM.
If the PR is from a Helm collaborator, then he or she should be the one to merge and close it. This keeps the commit stream clean and gives the collaborator the benefit of revisiting the PR before deciding whether or not to merge the changes.
## Support Channels
Whether you are a user or contributor, official support channels include:
- Slack: #Helm room in the [Kubernetes Slack](http://slack.kubernetes.io/)
Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of.
This document explains the leadership structure of the Kubernetes Helm project, and list the current project maintainers.
## What is a Maintainer?
(Unabashedly stolen from the [Docker](https://github.com/docker/docker/blob/master/MAINTAINERS) project)
There are different types of maintainers, with different responsibilities, but
all maintainers have 3 things in common:
1. They share responsibility in the project's success.
2. They have made a long-term, recurring time investment to improve the project.
3. They spend that time doing whatever needs to be done, not necessarily what
is the most interesting or fun.
## Types of Maintainers
The Helm project includes two types of maintainers: collaborators and core maintainers.
### Helm Collaborators
Helm collaborators are developers who have commit access to the Helm repository.
The duties of a collaborator include:
* Classify and respond to GitHub issues and review pull requests
* Perform code reviews
* Shape the Helm roadmap and lead efforts to accomplish roadmap milestones
* Participate actively in feature development and bug fixing
* Answer questions and help users
### Helm Core Maintainers
Helm core maintainers help shape the direction of the Helm project. In addition to the duties of a Collaborator, Helm Core Maintainers also:
* Run project planning meetings
* Place GitHub issues into GitHub milestones
* Prioritize issues within a milestone
The current core maintainers of Helm (in alphabetical order):
* Jack Greenfield - [@jackgr](https://github.com/jackgr)
* Matt Butcher - [@technosophos](https://github.com/technosophos)
## Project Planning
The Helm core maintainers hold regular planning meetings to set the project direction, milestones, and relative prioritization of issues. Planning meetings are coordinated via the #Helm room in the [Kubernetes Slack](http://slack.kubernetes.io/). In order to solicit feedback from the community, planning meetings are run in public whenever possible.
## Becoming a Maintainer
Generally, potential maintainers are selected by the existing core maintainers based in part on the following criteria:
* Sustained contributions to the project over a period of time (usually months)
* A willingness to help users on GitHub and in the [#Helm Slack room](http://slack.kubernetes.io/)
* A friendly attitude
The Helm core maintainers must unanimously agree before inviting a community member to join as a maintainer, although in many cases the candidate has already been acting in the capacity of a maintainer for some time, and has been consulted on issues, pull requests, etc.
