Cloud Native Buildpacks is better because of our contributors and maintainers. It is because of you that we can bring great software to the community. See below for further details on the several ways you can get more involved with the project.
You can follow the work we do, be part of on-going discussions, and examine our improvement ideas on each respective repo’s GitHub issues page.
If you’re a newcomer, check out the good first issue label in each repository, take pack for example.
If you are ready to jump in and add code, tests, or help with documentation, follow the guidelines in the contributing documentation in the respective repository.
Join any of our several channels within the Cloud Native Computing Foundation’s Slack workspace and talk to us and over 1,000 other community members:
Working Group Meetings are held every 1st and 3rd Thursday at 10am Pacific Time (convert to your time zone) and every 2nd and 4th Thursday at 7am Pacific Time (convert to your time zone).
.ics:
Attend working group meetings to hear the latest development updates, provide feedback, ask questions, meet the maintainers, and get to know other members of the community.
Join our Mailing List to get updates on the project and invitations to working group meetings.
Topics should be added to the agenda in the public Google Doc the day prior to the meeting. The list of topics will be finalized by the meeting organizers. If any scheduled topics are covered in less than the allotted time, additional topics may be covered.
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 -sA 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}}As our adopters and contributors have grown substantially over the last several years, we created a new GitHub organization to allow us to foster partner projects. The Buildpacks Community organization is a vendor-neutral Github organization where the community provides trusted Cloud Native Buildpacks tooling, platforms, and integrations.
For a project to be admitted to the Buildpacks community organization, it must meet several criteria, but the first step is to create a Github issue in the Buildpacks Community repository. Once it is mature enough to be part of the core Buildpacks organization, the project maintainers can request for the project to be graduated into the core Buildpacks organization. Kpack was the first project to be donated into this new org and you can read more about the first major community project donation here.
If you want to know more and how you can donate your own project, you can find all the details in the RFC.