Skip to content

Latest commit

 

History

History
157 lines (108 loc) · 6.31 KB

CONTRIBUTING.md

File metadata and controls

157 lines (108 loc) · 6.31 KB
Raw

How to Contribute

We'd love to accept your patches and contributions to this project. To learn more about the project structure and organization, please refer to Project Governance information. There are just a few small guidelines you need to follow.

Developer Certificate of Origin (DCO)

Contributors of this project should state that they agree with the terms published at https://developercertificate.org/ for their contribution. To do this when creating a commit with the Git CLI, a sign-off can be added with the -s option. The sign-off is stored as part of the commit message itself.

Contributing large features

Larger features and all the features that affect the interface (CLI or API) of kpt components need to have a reviewed and merged design document. It is OK to start with a prototype in your private fork but if you intend for your feature to be shipped in kpt please create a design document with this design template.

You should create a copy of the template and submit a PR for comments and review by maintainers. Once the PR is merged the design is considered approved. The actual code change PRs should link to the design documents, even though it is well understood that the design can drift during implementation.

Code reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

Community Guidelines

This project follows Google's Open Source Community Guidelines and a Code of Conduct.

Community Discussion Groups

Join following groups/channels to discuss ideas with other kpt contributors.

  1. For developers join our email list
  2. You can add this Google calendar to get access to all our meetings. If you'd like to be automatically added to all meetings please join this list. Note, our meetings are open to anyone and you do not need an agenda to come. You may be asked for an introduction. For your first meeting, we would suggest you either start with Office Hours or the SIG meeting.
  3. Join our Slack channel

Style Guides

Contributions are required to follow these style guides:

Contributing to kpt

The kpt toolchain has several components such as kpt CLI, package orchestrator, function catalog, function SDKs, Backstage UI plugin and config sync. Each component has their own development process. Refer to the pointers below to learn more:

Attend Meetings

  • All SIGs have a regular scheduled meeting for feature/roadmap management and planning. For example if you are interested in discussing the roadmap for Config Sync you should attend the Kpt SIG Config Sync meeting
  • Sub-projects are focused on more tactical items and other sub-project lifecycle items. Sub-projects generally have standups associated with them.
  • Working Groups are nimble. Focused a lot on experimentation. Attend if you'd like to see demos and discuss future looking user experiences.
  • We regularly have an office hours where we invite the entire community to attend.
  • Meeting notes will be kept for all meetings.
  • We will not record meetings unless someone explictly asks for one and there are no objections by attendees. If a meeting is recorded a link to it will be left in the notes.

Meeting Notes

Links to meeting notes. Some may require access to mailing lists above. If in doubt join kpt-contribx

Coming soon

  • SIG Config as Data
  • SIG Config Sync

kpt CLI

Building the Source

  1. Clone the project

    git clone https://github.com/GoogleContainerTools/kpt
cd kpt

  2. Build kpt to $(go env GOPATH)/bin/kpt

    make

  3. Run test

    make all

Package Orchestrator

Package orchestrator code has been moved to the Nephio project: https://github.com/nephio-project/porch

Function Catalog

Function catalog has its own repository. Refer to the documentation in the kpt-functions-catalog repo.

Config Sync

Config Sync has its own repository. Refer to the documentation in the config-sync repo.

Documentation

If you are updating the documentation, please do it in separate PRs from code changes and PR description should start with Docs:.

Run the docs locally

Make docs changes and test them by running the site in a docker container with make site-run-server.

It's usually a good idea to test locally for the following:

  • Broken links
  • Rendering static content

Update docs

Docs are under site/ and use docsify to present the source markdown files. The sidebar is automatically updated for the site at deployment time.

Docs Hygiene

The kpt website uses markdownlint to lint docs for formatting and style. Use prettier with the "prettier.proseWrap": "always" setting to auto-format docs in VSCode.

This includes:

  • Lint docs with markdownlint to standardize them and make them easier to update.
  • Run the kpt website through the W3 Link Checker in recursive mode and fix warnings and errors.