Project

• 1: Commitment
• 2: Contributions
• 2.1: Guidelines
• 2.2: Adoption
• 3: Governance
• 4: Community
• 5: Branding

1 - Commitment

Icons

Find all the available artworks and logos for the project in the CNCF Logo repository:

• https://github.com/cncf/artwork/tree/main/projects/capsule

2 - Contributions

All contributions are welcome! If you find a bug or have a feature request, please open an issue or submit a pull request. There’s different ways to contribute to the project:

1. Report Issues

Issues to Capsule help improve the project in multiple ways including the following:

• Report potential bugs
• Request a feature
• Improve documentation

2. Engagement

Engage with the community on Slack and help new users with questions or issues they may have. Spread the word about Capsule and help us grow the community. Add yourself to the Capsule adopters

3. Submit changes

Submit technical changes via pull requests. New contributors may easily view all open issues labeled as good first issues allowing you to get started in an approachable manner. If you already have experience with the project, you may also want to look at the help wanted issues.

Once you wish to get started contributing to the code base, please refer to our development guidelines and read the DEVELOPMENT.md per repository for a how-to. We accept pull requests from forks only.

Before creating a pull request, please ensure that your changes are tested and that the documentation is updated accordingly.

2.1 - Guidelines

The following guidelines outline the semantics and processes which apply to technical contributions to the project.

Supported Versions

Versions follow Semantic Versioning terminology and are expressed as x.y.z:

• where x is the major version
• y is the minor version
• and z is the patch version

Security fixes, may be backported to the three most recent minor releases, depending on severity and feasibility.

Prereleases are marked as -rc.x (release candidate) and may refere to any type of version bump.

Pull Requests

The pull request title is checked according to the described semantics (pull requests don’t require a scope). However pull requests are currently not used to generate the changelog. Check if your pull requests body meets the following criteria:

• reference a previously opened issue: https://docs.github.com/en/github/writing-on-github/autolinked-references-and-urls#issues-and-pull-requests
• splitting changes into several and documented small commits
• limit the git subject to 50 characters and write as the continuation of the sentence “If applied, this commit will …”
• explain what and why in the body, if more than a trivial change, wrapping at 72 characters

If your pull request in a draft state and not ready yet for review, you can prefix the title with [WIP]. This will indicate that work is still ongoing:

[WIP] feat(controller): new cool feature

Create a Pull Request

Head over to the project repository on GitHub and click the “Fork” button. With the forked copy, you can try new ideas and implement changes to the project.

1. Clone the repository to your device:

Get the link of your forked repository, paste it in your device terminal and clone it using the command.

git clone https://hostname/YOUR-USERNAME/YOUR-REPOSITORY

2. Create a branch:

Create a new brach and navigate to the branch using this command.

git checkout -b <new-branch>

3. Stage, Commit, and Push changes:

Now that we have implemented the required changes, use the command below to stage the changes and commit them.

git add .

git commit -s -m "Commit message"

Go ahead and push your changes to GitHub using this command.

git push

Commits

The commit message is checked according to the described semantics. Commits are used to generate the changelog and their author will be referenced in the changelog.

Reorganising commits

To reorganise your commits, do the following (or use your way of doing it):

1. Pull upstream changes

git remote add upstream git@github.com:projectcapsule/capsule.git
git pull upstream main

2. Pick the current upstream HEAD (the commit is marked with (remote/main, main))

git log
....
commit 10bbf39ac1ac3ad4f8485422e54faa9aadf03315 (remote/main, main)
Author: Oliver Bähler <oliverbaehler@hotmail.com>
Date:   Mon Oct 23 10:24:44 2023 +0200

    docs(repo): add sbom reference

    Signed-off-by: Oliver Bähler <oliverbaehler@hotmail.com>

3. Soft reset to the commit of the upstream HEAD

git reset --soft 10bbf39ac1ac3ad4f8485422e54faa9aadf03315

4. Remove staged files (if any)

git restore --staged .

5. Add files manually and create new commits, until all files are included

git add charts/capsule/
git commit -s -m "feat(chart): add nodeselector value"

...

6. Force push the changes to your fork

git push origin main -f

Sign-Off

Developer Certificate of Origin (DCO) Sign off For contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project, we are requiring everyone to acknowledge this by signing their work which indicates you agree to the DCO found here.

To sign your work, just add a line like this at the end of your commit message:

Signed-off-by: Random J Developer random@developer.example.org This can easily be done with the -s command line option to append this automatically to your commit message.

git commit -s -m 'This is my commit message'

Signature

All commits must be signed with a GPG key.

Semantics

The semantics should indicate the change and it’s impact. The general format for commit messages and pull requests is the following:

feat(ui): add `button` component
^    ^    ^
|    |    |__ Subject
|    |_______ Scope
|____________ Type

The commits are checked on pull-request. If the commit message does not follow the format, the workflow will fail. See the Types for the supported types. The scope is not required but helps to provide more context for your changes. Try to use a scope if possible.

Types

The following types are allowed for commits and pull requests:

• chore: housekeeping changes, no production code change
• ci: changes to buillding process/workflows
• docs: changes to documentation
• feat: new features
• fix: bug fixes
• test: test related changes
• sec: security related changes

2.2 - Adoption

Have your tried Capsule or are you using it in your project or company? Please consider adding your project/company to the list of adopters. This helps the Capsule community understand who is using Capsule and how it is being used.

Adding yourself

In the adopters.yaml file you can add yourself as an adopter of the project. You just need to add an entry for your company and upon merging it will automatically be added to our website. To add your organization follow these steps:

1. Fork the projectcapsule/website project to your personal space.

2. Clone it locally with git clone https://github.com/<YOUR-GH-USERNAME>/website.git.

3. We prefer using the logo from an upstream resource instead of collecting logos. If you don’t have a logo to provide you will get a default logo.

4. Open data/adopters.yaml file and add your organization to the list. The file is in the following format:

     # Company/Project Name
   - name: "Adopter Name"
     # Link for name
     link: https://www.adopter.net
     # Logo Source
     logo: https://www.adopter.net/wp-content/uploads/logo.svg
   

   You can just add to the end of the file, we already sort alphabetically by name of organization.

5. Save the file, then do git add -A and commit using git commit -s -m "Add MY-ORG to adopters" See our contribution guidelines.

6. Push the commit with git push origin main.

7. Open a Pull Request to capsule/website and a preview build will turn up.

Thanks a lot for being part of our community - we very much appreciate it!

3 - Governance

The Capsule project is dedicated to creating a multi-tenancy and policy-based framework for Kubernetes. This governance explains how the project is run.

• Values
• Maintainers
  • Becoming a Maintainer
  • Removing a Maintainer
• Meetings
• CNCF Resources
• Code of Conduct
• Security Response Team
• Voting
• Modifying this Charter

Values

The Capsule and its leadership embrace the following values:

• Openness: Communication and decision-making happens in the open and is discoverable for future reference. As much as possible, all discussions and work take place in public Slack channels and open repositories.

• Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits.

• Community over Product or Company: Sustaining and growing our community takes priority over shipping code or sponsors’ organizational goals. Each contributor participates in the project as an individual.

• Community Before Individual Demand: As a community-driven open source project, we emphasize the importance of collaboration and contribution. Maintainers and contributors work together towards the project’s growth, not to serve unilateral user demands. Users pretending features or enhancements for their sole benefit without contributing to the effort are not aligned with our community values.

• Inclusivity: We innovate through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment.

• Participation: Responsibilities within the project are earned through participation, and there is a clear path up the contributor ladder into leadership positions.

Maintainers

Capsule Maintainers have write access to the project GitHub repository. They can merge their own patches or patches from others. The current maintainers can be found in MAINTAINERS.md. Maintainers collectively manage the project’s resources and contributors.

This privilege is granted with some expectation of responsibility: maintainers are people who care about the Capsule project and want to help it grow and improve. A maintainer is not just someone who can make changes, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code and docs.

A maintainer is a contributor to the project’s success and a citizen helping the project succeed. The collective team of all Maintainers is known as the Maintainer Council, which is the governing body for the project.

Becoming a Maintainer

To become a Maintainer you need to demonstrate the following:

• commitment to the project:
  • participate in discussions, contributions, code and documentation reviews,
  • perform reviews for non-trivial pull requests,
  • contribute non-trivial pull requests and have them merged,
• ability to write quality code and/or documentation,
• ability to collaborate with the team,
• understanding of how the team works (policies, processes for testing and code review, etc),
• understanding of the project’s purpose, code base and coding and documentation style.

A new Maintainer must be proposed by an existing maintainer by sending a message to all the other existing Maintainers. A simple majority vote of existing Maintainers approves the application. Maintainers nominations will be evaluated without prejudice to employer or demographics.

Maintainers who are selected will be granted the necessary GitHub rights.

Removing a Maintainer

Maintainers may resign at any time if they feel that they will not be able to continue fulfilling their project duties.

Maintainers may also be removed after being inactive, failure to fulfill their Maintainer responsibilities, violating the Code of Conduct, or other reasons. A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.

Depending on the reason for removal, a Maintainer may be converted to Emeritus status. Emeritus Maintainers will still be consulted on some project matters, and can be rapidly returned to Maintainer status if their availability changes.

Meetings

Time zones permitting, Maintainers are expected to participate in the public developer meeting and/or public discussions.

Maintainers will also have closed meetings in order to discuss security reports or Code of Conduct violations. Such meetings should be scheduled by any Maintainer on receipt of a security issue or CoC report. All current Maintainers must be invited to such closed meetings, except for any Maintainer who is accused of a CoC violation.

CNCF Resources

Any Maintainer may suggest a request for CNCF resources. A simple majority of Maintainers approves the request. The Maintainers may also choose to delegate working with the CNCF to non-Maintainer community members, who will then be added to the CNCF’s Maintainer List for that purpose.

Code of Conduct

Code of Conduct violations by community members will be discussed and resolved in private Maintainer meetings. If a Maintainer is directly involved in the report, the Maintainers will instead designate two Maintainers to work with the CNCF Code of Conduct Committee in resolving it.

Security Response Team

The Maintainers will appoint a Security Response Team to handle security reports. This committee may simply consist of the Maintainer Council themselves. If this responsibility is delegated, the Maintainers will appoint a team of at least two contributors to handle it. The Maintainers will review who is assigned to this at least once a year.

The Security Response Team is responsible for handling all reports of security holes and breaches according to the [security policy](TODO:Link to security.md).

Voting

While most business in Capsule Project is conducted by “lazy consensus”, periodically the Maintainers may need to vote on specific actions or changes. Any Maintainer may demand a vote be taken.

Most votes require a simple majority of all Maintainers to succeed, except where otherwise noted. Two-thirds majority votes mean at least two-thirds of all existing maintainers.

Modifying this Charter

Changes to this Governance and its supporting documents may be approved by a 2/3 vote of the Maintainers.

4 - Community

5 - Branding

Icons

Find all the available artworks and logos for the project in the CNCF Logo repository:

• https://github.com/cncf/artwork/tree/main/projects/capsule