Partake in one or many of our following public events:
.ics
:
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:
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.
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:
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!
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:
git checkout -b {{BRANCH_NAME}}
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.
git push origin {{BRANCH_NAME}}