Skip to content

Latest commit

 

History

History
150 lines (91 loc) · 10 KB

CONTRIBUTING.md

File metadata and controls

150 lines (91 loc) · 10 KB
Raw

Contributing to Gardener

Code of conduct

All members of the Gardener community must abide by the CNCF Code of Conduct. Only by respecting each other can we develop a productive, collaborative community. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting [email protected] and/or a Gardener project maintainer.

Contributing

Gardener uses GitHub to manage reviews of pull requests.

  • If you are a new contributor see: Steps to Contribute

  • If you have a trivial fix or improvement, go ahead and create a pull request, addressing (with @...) a suitable maintainer of this repository (see CODEOWNERS of the repository you want to contribute to) in the description of the pull request.

  • If you plan to do something more involved, first discuss your ideas on our mailing list. This will avoid unnecessary work and surely give you and us a good deal of inspiration.

  • Relevant coding style guidelines are the Go Code Review Comments and the Formatting and style section of Peter Bourgon's Go: Best Practices for Production Environments.

Steps to Contribute

Should you wish to work on an issue, please claim it first by commenting on the GitHub issue that you want to work on it. This is to prevent duplicated efforts from contributors on the same issue.

If you have questions about one of the issues, with or without the tag, please comment on them and one of the maintainers will clarify it.

We kindly ask you to follow the Pull Request Checklist to ensure reviews can happen accordingly.

Contributing Code

You are welcome to contribute code to Gardener in order to fix a bug or to implement a new feature.

The following rules govern code contributions:

Contributing Documentation

You are welcome to contribute documentation to Gardener.

The following rules govern documentation contributions:

Developer Certificate of Origin

Due to legal reasons, contributors will be asked to accept a Developer Certificate of Origin (DCO) before they submit the first pull request to this projects, this happens in an automated fashion during the submission process. We use the standard DCO text of the Linux Foundation.

Pull Request Checklist

  • Branch from the master branch and, if needed, rebase to the current master branch before submitting your pull request. If it doesn't merge cleanly with master you may be asked to rebase your changes.

  • Commits should be as small as possible, while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).

  • Test your changes as thoroughly as possible before your commit them. Preferably, automate your test by unit / integration (e.g. Gardener integration testing) tests. If tested manually, provide information about the test scope in the PR description (e.g. “Test passed: Upgrade K8s version from 1.14.5 to 1.15.2 on AWS, Azure, GCP, Alicloud, Openstack.”).

  • Create Work In Progress [WIP] pull requests only if you need a clarification or an explicit review before you can continue your work item.

  • If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review on our mailing list.

  • If you add new features, make sure that they are documented in the Gardener documentation

  • If your changes are relevant for operators, consider to update the ops toolbelt image

  • Post review:

    • If a review requires you to change your commit(s), please test the changes again.
    • Amend the affected commit(s) and force push onto your branch.
    • Set respective comments in your GitHub review to resolved.
    • Create a general PR comment to notify the reviewers that your amendments are ready for another round of review.

Contributing Bigger Changes

If you want to contribute bigger changes to Gardener, such as when introducing new API resources and their corresponding controllers, or implementing an approved Gardener Enhancement Proposal, follow these guidelines:

  • Avoid proposing a big change in one single PR. Instead, split your work into multiple stages which are independently mergeable and create one PR for each stage. For example, if introducing a new API resource and its controller, these stages could be:

    • API resource types, including defaults and generated code.
    • API resource validation.
    • API server storage.
    • Admission plugin(s), if any.
    • Controller(s), including changes to existing controllers. Split this phase further into different functional subsets if appropriate.

  • If you realize later that changes to artifacts introduced in a previous stage are required, by all means make them and explain in the PR why they were needed.

  • Consider splitting a big PR further into multiple commits to allow for more focused reviews. For example, you could add unit tests / documentation in separate commits from the rest of the code. If you have to adapt your PR to review feedback, prefer doing that also in a separate commit to make it easier for reviewers to check how their feedback has been addressed.

  • To make the review process more efficient and avoid too many long discussions in the PR itself, ask for a "main reviewer" to be assigned to your change, then work with this person to make sure he or she understands it in detail, and agree together on any improvements that may be needed. If you can't reach an agreement on certain topics, comment on the PR and invite other people to join the discussion.

  • Even if you have a "main reviewer" assigned, you may still get feedback from other reviewers. In general, these "non-main reviewers" are advised to focus more on the design and overall approach rather than the implementation details. Make sure that you address any concerns on this level appropriately.

Issues and Planning

We use GitHub issues to track bugs and enhancement requests. Please provide as much context as possible when you open an issue. The information you provide must be comprehensive enough to reproduce that issue for the assignee. Therefore, contributors may use but aren't restricted to the issue template provided by the Gardener maintainers.

ZenHub is used for planning:

Security Release Process

See Security Release Process

Community

Slack Channel

#gardener, sign up here

Mailing List

[email protected]

The mailing list is hosted through Google Groups. To receive the lists' emails, join the group, as you would any other Google Group.

Twitter

Follow @GardenerProject on Twitter. Please mention @GardenerProject in your own posts about Gardener.

Accessing community documents

In order to foster real time collaboration there are working documents and notes that are taken in Google Docs, and then transferred to this repository if appropriate.

To gain edit access for these documents, you must subscribe to the gardener mailing list, as these documents are shared automatically with anyone who subscribes to that list.

Bi-Weekly Meetings

We have a PUBLIC and RECORDED bi-weekly meeting. We meet every other Friday at 10:00 CET over Zoom. Find recordings in the Gardener Youtube channel. Let us know if you want to participate and live in a timezone where 10:00 CET is in the night, we can also schedule meetings on Thursday 17:00 CET.

See the meeting calendar on the web at calendar.google.com, or paste this iCal url into any iCal client.

If you have a topic you'd like to present or would like to see discussed, please propose a specific date on the Gardener Community Meeting Agenda. Find minutes in the same document. Please upload slides or other documents you presented to the Gardener Community Meeting folder. Subscribe to the gardener mailing list to get edit permissions.