Buildpacks
/
community
mirror of https://github.com/buildpacks/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
community/contributors/guide.md

8.1 KiB
Raw Permalink Blame History

Contributor's Guide

The start of your involvement with the Cloud Native Buildpacks.

Contributors

+-------------------------+       +-----------------------+       +--------------+
|                         |       |                       |       |              |
|  Community Contributor  | +---> |  Project Contributor  | +---> |  Maintainer  |
|                         |       |                       |       |              |
+-------------------------+       +-----------------------+       +--------------+

Contributors can be broken down into the following tiers.

  1. Community Contributor
  2. Project Contributor
  3. Maintainer

Community Contributor

This is anyone that interacts with this project, whether it be by creating an issue, opening a PR, adding a comment, etc. You are all, in some way, contributing to a better project.

Project Contributor

These contributors are recognized as providing sizable contributions to the project.

Additional Responsibilities:

  • Maintain active participation in project.

Additional Capabilities:

  • Added to GitHub organization team.
  • Ability to edit, label, assign issues.
  • Write access to branches on project repos.
  • Access to infrastructure.

Maintainer

Maintainers are responsible for advancing the objectives and outcomes of the team they are inducted into. For detailed information, see the Maintainer's Guide.

Additional Responsibilities:

Additional Capabilities:

  • Publish releases.
  • Ability to configure repositories.
  • Invitation to leadership events.

Contributions

Contribution to this project goes beyond the notion of code contributions. We value any help that you may be able to provide.

Component

Components developed outside of the Cloud Native Buildpacks project can be accepted following the process defined in this RFC.

  • Component-level contributions must be proposed as project-wide RFCs
  • Proposed contributions must primarily support the goals and use cases of the project and may not contain unrelated functionality that would not otherwise be accepted via the RFC process.
    • Qualifying examples:
      1. A Github Action that performs buildpack builds
      2. A Concourse resource that creates builder images
      3. A v2 Heroku buildpack that runs Cloud Native Buildpack (v3) builds on platforms that only support older v2 buildpacks.
    • Non-qualifying examples:
      1. A generic CI/CD tool that includes functionality to run buildpack builds, but primarily supports use cases outside of the project (e.g., Tekton)
  • If a proposed contribution provides functionality that is already provided by the project, such functionality must be provided for use in a non-overlapping context, or the proposal should include a plan for consolidation.
    • Qualifying examples:
      1. Buildpack language bindings for a language other than those already supported by the project (such as Go)
      2. An alternative implementation of the buildpack lifecycle launcher in Rust, with a documented plan to deprecate the original Go version
    • Non-qualifying examples:
      1. An alternative implementation of the lifecycle in Rust that would exist concurrently with the Go version in perpetuity
  • If a proposed contribution is an adapter or integration with another service or technology, that technology must be notable and/or widely used (at the TOC’s discretion).
  • If a component is proposed for donation by one or more TOC members individually, those TOC members must abstain from voting over its acceptance.
  • If a component is proposed for donation by one or more TOC members’ employer or employers, those TOC members must abstain from voting over its acceptance. Supermajority consensus of non-abstaining TOC members is still required.
  • Component-level contributions are subject legal review by the Cloud Native Computing Foundation / Linux Foundation. Adherance to these guidances does not guarantee acceptance. The investigation of this is to be done by the TOC before acceptance.

Code

Code contributions to any project repo are always welcomed.

The following repositories are good starting points for code contributions:

Other, more specialized, repositories include:

Docs

This involves documenting any aspect of the project. A good starting point for contributions to documentation would revolve around your comprehension or desired area of expertise.

A few examples of places where documentation would be valuable:

RFCs

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:

Triage

Triaging issues is the process of looking at newly created issues (or following up on issues). There are many benefits our community gain from our current triage process, to name a few:

  1. The community receives reasonable response times.
  2. Minimize the number of open "stale" issues.
  3. Ongoing efforts aren't disrupted.

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

FAQs

  • How do I become a project contributor?

    The process for becoming a Project Contributor simply requires that you actively contribute to the project. There is no set amount of contributions that are expected, but the more involved you are in the project the more votes that would be tipped in your favor.

    Once you've got a decent amount of contributions, you may self-nominate, or be nominated by another team member to become a Project Contributor. The maintainers of said relevant sub-teams will then vote for your election into becoming a Project Contributor.