# Contributing guide

Thank you for your interest in improving rules_cc! This guide will walk you
through the expectations and contribution process for this project.

# Expectations

## Sign the Contributor License Agreement

To contribute to this project, you must sign the Contributor License Agreement.
You (or your employer) retain the copyright to your contribution; this simply
gives us permission to use and redistribute your contributions as part of the
project. You generally only need to submit a CLA once, so if you've already
submitted one (even if it was for a different project), you probably don't need
to do it again.

Visit <https://cla.developers.google.com/> to see your current agreements on
file or to sign a new one.

## Follow Community Guidelines

We expect everyone who interacts with this project to follow [Google's Open
Source Community Guidelines](https://opensource.google.com/conduct/).

# Creating a change

## Ensure your solution is complete

Before proposing a change, ensure your solution includes relevant test coverage
and documentation. Additionally, all code is expected to adhere to the following
language-specific style guides:

* [Google C/C++ style guide](https://google.github.io/styleguide/cppguide.html)
* [Bazel .bzl style guide](https://bazel.build/rules/bzl-style)
* [Bazel BUILD style guide](https://bazel.build/build/style-guide)

## Create a pull request

To propose your changes, [create a pull request from your fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).

When you do this, maintainers will automatically be notified of your proposed changes.

## Fix any breakages

An initial set of checks are run by the GitHub actions in this project. If any
failures are relevant to your changes, promptly address them to ensure a
smoother code review experience.

A second set of checks are run after a Google developer begins the
Google-specific import process (when the `import/copybara` check turns green).
These checks are not visible to open source contributors, so please be patient
and reach out if you need assistance identifying next steps.

## Address review feedback

All incoming changes require review, which is done through GitHub's [pull
request review
UI](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)

After you address any feedback from maintainers, [re-request
review](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review).

## Await merge

After a change is reviewed and approved by a maintainer, it must be separately
approved by two separate Google engineers through Google's code import process.
During this process, additional tests are run and new breakages may be
identified. If a change is approved but not merged, it is likely caught in this
stage of the process.

There are two stages to this:

* import/copybara - When this is yellow, the import process is not yet started.
  When it is green, this means the import process has started.
* feedback/copybara - This check indicates whether or not Google-internal checks
  pass.

When all of Google's internal checks are satisfied,
[Copybara](https://github.com/google/copybara) will merge the change into both
repositories, closing the associated PR. This does not mean your change is
rejected, it's just the mechanism Copybara uses to communicate that the change
has merged.