This guide is targeted at developers looking to contribute to Feast:

• Project Structure
• Making a Pull Request
• Feast Data Storage Format
• Feast Protobuf API
• Maintainer Guide

Learn How the Feast Contributing Process works.

{% hint style="info" %} See also the CONTRIBUTING.md in the corresponding GitHub repository (e.g. main repo doc) {% endhint %}

Our preference is the use of git rebase instead of git merge : git pull -r

Commits have to be signed before they are allowed to be merged into the Feast codebase:

# Include -s flag to signoff
git commit -s -m "My first commit"

• Fill in the description based on the default template configured when you first open the PR
  • What this PR does/why we need it
  • Which issue(s) this PR fixes
  • Does this PR introduce a user-facing change
• Include kind label when opening the PR
• Add WIP: to PR name if more work needs to be done prior to review
• Avoid force-pushing as it makes reviewing difficult

Managing CI-test failures

• GitHub runner tests
  • Click checks tab to analyse failed tests
• Prow tests
  • Visit Prow status page to analyse failed tests

Feast data storage contracts are documented in the following locations:

• Feast Offline Storage Format: Used by BigQuery, Snowflake (Future), Redshift (Future).
• Feast Online Storage Format: Used by Redis, Google Datastore.

Feast Protobuf API defines the common API used by Feast's Components:

• Feast Protobuf API specifications are written in proto3 in the Main Feast Repository.
• Changes to the API should be proposed via a GitHub Issue for discussion first.

The language specific bindings have to be regenerated when changes are made to the Feast Protobuf API: