Calendar

Partake in one or many of our following public events:

* Events displayed in local time.
Download events as .ics:

Contributing

How can I start contributing?

If you are new to the project, the first thing you should do is gain some understanding of the project. This normally entails doing the following:

  1. Watch a few talks (videos).
  2. Next, run through some tutorials.

If you run into issues or unexpected behaviour, that’s probably the best place to start adding your first contribution.

If you didn’t find anything you’d like to improve while going through the tutorials you can browse the repositories below (some of those repositories may even have “good first issues”):

Component Tech Stack Description
pack Go, Docker CLI providing build and utility functions to end-users.
lifecycle Go, Docker Executables that implement the main specifications and are used by platforms such as pack.
docs Hugo, HTML, JavaScript Main website and documentation.

Depending our your depth of understanding or desires some components may be more ideal than others.

What type of contributions can I make?

Buildpacks welcomes all types of contributions, not just those related to code. We value any help that you can provide, and are more than happy to guide you through the process.

Code contributions are always welcome to any Buildpacks repository.

The following repositories are good starting points for code contributions:

Other, more specialized, repositories include:

This involves documenting any aspect of the project. We have various open issues for you to start off with. Another good starting point would revolve around your comprehension or desired area of expertise.

Some examples where we’d value documentation contributions are:

If you have any other ideas where documentation would be useful, please feel free to open up an issue in the related repository, or drop a message at the #buildpacks-learning-team channel on Slack!

RFCs, or Request For Comments, is the process we employ to review project-wide changes. By proposing changes via RFCs, it allows for the entire community to partake in the brainstorming process of applying changes, considering alternatives, impact, and limitations.

Contributions to the RFC process can take any or all of the following forms:

Triaging issues is the process of looking at newly created issues (or following up on issues). There are many benefits our community gains from our current triage process, such as:

  • The community receives reasonable response times.
  • Minimize the number of open “stale” issues.
  • Ongoing efforts aren’t disrupted.

To learn more about how you can help triage issues, check out our dedicated triage page.

If you’re looking at open issues but unsure where to start, try looking for issues with the “good first issue” or “help wanted” labels!

How do I submit a pull request?

If your contribution requires changes to a project repository, look at the DEVELOPMENT.md file if the repo has one to ensure you have the prerequisites installed. It may also include other necessary steps (such as instructions on running tests), but broadly, you will have to carry out the following steps:

  • Fork the repository.
  • Clone your fork repository.
  • Create a branch for the issue: git checkout -b {{BRANCH_NAME}}
  • Make any changes deemed necessary.
  • Commit your changes with a sign-off: git commit -s

A sign-off is a single line added to your commit messages that certifies that you wrote and/or have the right to the contributed changes. The signature should look as such:

Signed-off-by: John Doe <john.doe@email.com>

Also, git can automatically add the signature by adding the -s flag to the commit command, git commit -s

The full text of the certification is available here.