Skip to content

Latest commit

 

History

History
54 lines (35 loc) · 4.22 KB

CONTRIBUTING.md

File metadata and controls

54 lines (35 loc) · 4.22 KB

Contributing Guide

First and foremost, thank you for contributing to this project led by the CNCF Environmental Sustainability TAG! We really appreciate your time and willingness to contribute. The Green Reviews Working Group is an entirely volunteer-led open-source project where we innovate in the open in the hopes of making this architectural reference available to everyone who operates in a cloud-native environment.

Read on to learn more about the project and how to contribute. As always, please don't hesitate to ask if anything is unclear. We value questions, guidance, and suggestions - they help us build the right thing.

Finding Work

Here are some suggestions for how to find work to contribute to the project.

First, make sure you're up to speed with the project by looking through the resources in the Getting Started guide.

Then, familiarise yourself with the current work and priorities, or find someone who would be willing to pair with you:

When you feel ready to contribute:

  • Check the Backlog in the issue board. More pressing issues are labeled with good first issue or help wanted.
  • If you would like to make a feature request or raise a bug, feel free to open an issue.
  • If all else fails, you could reach out to the Green Review WG leads directly with any queries. However, the public communication channels listed above are preferred so that we can load-balance the work.

We encourage all communication to remain public by going through the communications channels listed above so that everyone can stay informed!

Opening a Pull Request

Recommendations for a faster Pull Request review:

Proposals

For larger feature requests, please submit a design proposal in docs/proposals/. This is similar to a Kubernetes Enhancement Proposal (KEP) or a Architecture Decision Record (ADR).

First, create a copy of the template found in the proposal directory, docs/proposals/proposal-000-template.md. Rename the file to the next number in the sequence and add a name for the proposal e.g. proposal-001-my-feature.md. Fill in the required fields, then open a PR for review.

The initial PR can be a barebone PR with the goals/non-goals sections clarified that can be merged quickly and iterated on.

Initial merging of the PR does not mean that the proposal is approved. The status of the PR is defined in the Status section. Any KEP marked as provisional is a working document and subject to change.

A proposal that is accepted is a living document. Even the most well-planned ideas may change at some point.