Project
All contributions are welcome! If you find a bug or have a feature request, please open an issue or submit a pull request.
Ways to contribute
1. Report Issues
Issues to Capsule help improve the project in multiple ways including the following:
- Report potential bugs
- Request a feature
- Request a sample policy
2. Engagement
Engage with the community on Slack and help new users with questions or issues they may have.
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.
Once you wish to get started contributing to the code base, please refer to our development guide 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.
When creating a pull request, please visit:
Guidelines
The following guidelines outline the semantics and processes which apply to technical contributions to the project.
3 - 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.
3.1 - Guidelines
Guidelines for submitting changes to the Capsule project
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 refer 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:
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.
- 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
- Create a branch:
Create a new brach and navigate to the branch using this command.
git checkout -b <new-branch>
- 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 commit -s -m "Commit message"
Go ahead and push your changes to GitHub using this command.
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):
- Pull upstream changes
git remote add upstream git@github.com:projectcapsule/capsule.git
git pull upstream main
- 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>
- Soft reset to the commit of the upstream HEAD
git reset --soft 10bbf39ac1ac3ad4f8485422e54faa9aadf03315
- Remove staged files (if any)
- 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"
...
- Force push the changes to your fork
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 changeci: changes to building process/workflowsdocs: changes to documentationfeat: new featuresfix: bug fixestest: test related changessec: security related changes
3.2 - Adoption
Add your project/company to the list of adopters
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:
Fork the projectcapsule/capsule project to your personal space.
Clone it locally with git clone https://github.com/<YOUR-GH-USERNAME>/capsule.git.
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.
Open docs/data/adopters.yaml file and add your organization to the list. The file is in the following format:
```yaml
# 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.
Save the file, then do git add -A and commit using git commit -s -m "chore(docs): add my-org to adopters" See our contribution guidelines.
Push the commit with git push origin main.
Open a Pull Request to projectcapsule/capsule and a preview build will turn up.
Thanks a lot for being part of our community - we very much appreciate it!
3.3 - Addons
Add your addon to the ecosystem
Have you written an operator or some other automation which integrates with the capsule core project? Feel free to add your addon to the capsule ecosystem overview
Adding an addon
In the addons.yaml file you can add an addon to the ecosystem. You just need to add an entry for your addon and upon merging it will automatically be added to our website. To add your organization follow these steps:
Fork the projectcapsule/capsule project to your personal space.
Clone it locally with git clone https://github.com/<YOUR-GH-USERNAME>/capsule.git.
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.
Open docs/data/addons.yaml following format:
# Addon Name
- name: "Example Addon"
# Link for name
link: https://www.adopter.net
# Logo Source
logo: https://www.adopter.net/wp-content/uploads/logo.svg
## Links displayed with icon (Optional)
links:
You can just add to the end of the file, we already sort alphabetically by name of organization.
Save the file, then do git add -A and commit using git commit -s -m "chore(docs): add my-addon to addons" See our contribution guidelines.
Push the commit with git push origin main.
Open a Pull Request to projectcapsule/capsule and a preview build will turn up.
Thanks a lot for being part of our community - we very much appreciate it!
4 - 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
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.
5 - Branding
Branding and logos for the project
Find all the available artworks and logos for the project in the CNCF Logo repository:
6 - Commitment
Commitment for the project
Our commitment is to deliver a robust, stable Tenancy specification that serves as a foundational platform for a wide range of automation use cases in multi-tenant environments. Rather than focusing on niche scenarios, our project addresses the fundamental aspects that are universally required, including:
- Streamlined Permissions Management: Efficiently governing access control across diverse namespaces (tenants).
- Comprehensive Resource Oversight: Facilitating seamless resource management across multiple tenants.
- Exceptional User Experience: Prioritizing intuitive design and ease of use.
- Clear and Consistent API Specification: Empowering developers with a transparent and reliable interface.
- Community-Driven Automation: Enabling and encouraging further automation initiatives from the community.
Please note, this project is offered without any warranty, and support is provided on a best-effort basis.
