mirror of
https://github.com/kubesphere/website.git
synced 2025-12-26 00:12:48 +00:00
rayzhou2017
GitHub
commit
55a36dd18c
10
README.md
10
README.md
|
|
@ -2,16 +2,16 @@
|
|||
|
||||
Welcome to the KubeSphere community!
|
||||
|
||||
If you are looking for information on how to join us, you are in the right place. Read on to find out how you can get involved, contribute to KubeSphere code and documentation, propose new features, and stay in touch with the latest KubeSphere community news. Let's get started!
|
||||
If you are looking for information on how to join us, you are in the right place. Read on to find out how you can get involved, contribute to KubeSphere code and documentation, propose new features and designs, and stay in touch with the latest KubeSphere community news. Let's get started!
|
||||
|
||||
## Contribution rules
|
||||
## Contribution Rules
|
||||
|
||||
Before you start contributing, read our [Code of Conduct](code-of-conduct.md) and learn about our community working model to understand the way KubeSphere community works. Get familiar with the contributing rules, recommended [Git workflow](./developer-guide/guides/Development-workflow), and issues workflow we use in KubeSphere so you can apply them later in practice as an active contributor.
|
||||
Before you start contributing, read our [Code of Conduct](code-of-conduct.md) and learn about the community working model to understand the way KubeSphere community works. Get familiar with the contributing rules, recommended [development workflow](./developer-guide/development/development-workflow.md), and issues workflow we use in KubeSphere so you can apply them later in practice as an active contributor.
|
||||
|
||||
## Special Interest Group
|
||||
|
||||
Through SIGs, the KubeSphere community members collaborate and contribute to topics of long-term interest for KubeSphere and its community. Generally, SIGs can be either vertically focused on particular components and features, and can span multiple functional and technical domains. There are some SIGs in KubeSphere community, see [KubeSphere Special Interest Group](sigs.md) for details.
|
||||
Through SIGs, the KubeSphere community members collaborate and contribute to topics of long-term interest for KubeSphere and its community. Generally, SIGs can be either vertically focused on particular components and features, or span multiple functional and technical domains. There are some SIGs in KubeSphere community. Please read [KubeSphere Special Interest Group](sigs.md) for details.
|
||||
|
||||
## Working Group
|
||||
|
||||
Working Group (WG) facilitate discussions and work on short-lived, concrete topics that either result from the work of SIG groups or which the community members initiate directly. Each SIG can propose a new WG based on the detailed requirements and issues.
|
||||
Working Group (WG) facilitates discussions and work on short-lived, concrete topics that either result from the work of SIG groups or the community members initiate directly. Each SIG can propose a new WG based on the detailed requirements and issues.
|
||||
|
|
|
|||
14
cla.md
14
cla.md
|
|
@ -1,26 +1,26 @@
|
|||
# KubeSphere Contributor License Agreement
|
||||
|
||||
This KubeSphere Contributor License Agreement (CLA) applies to any contribution you make to any KubeSphere open source projects. If you are representing your employing organization to sign this agreement, please warrant that you have the authority to grant the agreement.
|
||||
This KubeSphere Contributor License Agreement (CLA) applies to any contribution you make to any KubeSphere open source projects. If you are representing your employer to sign this agreement, please warrant you have the authority to grant the agreement.
|
||||
|
||||
## Definitions
|
||||
|
||||
- "we", "our" and "us" means KubeSphere.
|
||||
- "You" and "your" means you or the organization you are on behalf of.
|
||||
- "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by you or the organization you represent to KubeSphere for inclusion in, or documentation of, any of the products owned or managed by KubeSphere.
|
||||
- "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work that is intentionally submitted by you or the organization you represent to KubeSphere for inclusion in, or documentation of, any of the products owned or managed by KubeSphere.
|
||||
|
||||
## Grant of Copyright License
|
||||
|
||||
All rights of your Contribution submitted to KubeSphere in any manner are granted to KubeSphere and recipients of software distributed by KubeSphere. You waive any rights that my affect our ownership of the copyright and grant to us a perpetual, worldwide, transferable, non-exclusive, no-charge, royalty-free, irrevocable, and sublicensable license to use, reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Contributions and any derivative works.
|
||||
All rights of your contribution submitted to KubeSphere in any manner are granted to KubeSphere and recipients of software distributed by KubeSphere. You waive any rights that affect our ownership of the copyright and grant to us a perpetual, worldwide, transferable, non-exclusive, no-charge, royalty-free, irrevocable and sublicensable license to use, reproduce, prepare derivative works, publicly display and perform, sublicense, and distribute contributions and any derivative works.
|
||||
|
||||
## Grant of Patent License
|
||||
|
||||
With respect to any patents you own or that you can license without payment to any third party, you grant to us and to any recipient of software distributed by us, a perpetual, worldwide, transferable, non-exclusive, no-charge, royalty-free, irrevocable patent license to make, have make, use, sell, offer to sell, import, and otherwise transfer the Contribution in whole or in part, alone or included in any product under any patent you own, or license from a third party, that is necessarily infringed by the Contribution or by combination of the Contribution with any Work.
|
||||
With respect to any patents you own or that you can license without payment to any third party, you grant to us and to any recipient of software distributed by us, a perpetual, worldwide, transferable, non-exclusive, no-charge, royalty-free, irrevocable patent license to make, have make, use, sell, offer to sell, import, and otherwise transfer the contribution in whole or in part, alone or included in any product under any patent you own, or license from a third party, that is necessarily infringed by the contribution or by combination of the contribution with any Work.
|
||||
|
||||
## Your Representations and Warranties
|
||||
|
||||
You represent and warrant that:
|
||||
|
||||
- You represent that each of Your Contributions is Your original
|
||||
- You represent that each of your contributions is your original
|
||||
creation that you can legally grant the rights set out in this agreement.
|
||||
- the Contribution you submit and licenses you granted does not and will not, infringe the rights of any third party.
|
||||
- you are not aware of any pending or threatened claims, suits, actions, or charges pertaining to the contributions. You also warrant to notify KubeSphere immediately if you become aware of any such actual or potential claims, suits, actions, allegations or charges.
|
||||
- The contribution you submit and licenses you grant do not and will not, infringe the rights of any third party.
|
||||
- You are not aware of any pending or threatened claims, suits, actions, or charges pertaining to the contributions. You also warrant to notify KubeSphere immediately if you become aware of any such actual or potential claims, suits, actions, allegations or charges.
|
||||
|
|
|
|||
|
|
@ -2,16 +2,16 @@
|
|||
|
||||
This document makes a reference to the rules of behavior for all contributors and maintainers in the community. All members agree to follow them to foster the growth of the community of tolerance, respect, and mutual understanding.
|
||||
|
||||
In the attempt to adopt the best practices from the most renowned open-source and cloud-native projects, and work closely with the Cloud Native Computing Foundation (CNCF), our community members are following the rules outlined in the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
|
||||
In the attempt to adopt the best practices from the most well-known open-source and cloud-native projects, and work closely with the Cloud Native Computing Foundation (CNCF), our community members follow the rules outlined in the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
|
||||
|
||||
# Best practices of committing code
|
||||
## Best Practices of Committing Code
|
||||
|
||||
Besides following above conduct from CNCF, we also hope every contributor in this project could help us to improve the quality of code, something you should know before checking in any new code:
|
||||
- As gopher, make sure you already read [the conduct of Go language](https://golang.org/conduct) and [the instruction of writting Go](https://golang.org/doc/effective_go.html).
|
||||
- Fork the project under your account and make the changes you want there.
|
||||
- Execute 'go fmt' for every piece of new code.
|
||||
- Every pulling request(PR) would be better constructed with only one commit, this could help code reviewer to go through your code efficiently, also helpful for every follower of this project to understand what happens in this PR. If you need to make any further code change to address the comments from reviewers, which means some new commits will be generated under this PR, you need to use 'git rebase' to combine those commits together.
|
||||
- Every PR should only solve one problem or provide one feature, don't put several different fixes into one PR.
|
||||
- At lease two code reviewers should involve into code reviewing process.
|
||||
- Please introduce new third-party packages as little as possible to reduce the vendor dependency of this project. For example, don't import a full unit converting package but only use one function from it. For this case, you'd better write that function by yourself.
|
||||
- more.
|
||||
Besides following the conduct above from CNCF, we also hope every contributor in this project could help us to improve the quality of code. Something you should know before checking in any new code lists below:
|
||||
|
||||
- As gopher, make sure you already read [the conduct of Go language](https://golang.org/conduct) and [the instruction of writing Go](https://golang.org/doc/effective_go.html).
|
||||
- Fork the project under your GitHub account and make the changes you want there.
|
||||
- Execute 'go fmt' for every piece of new code.
|
||||
- Every pulling request (PR) would be better constructed with only one commit, which could help code reviewer to go through your code efficiently, also helpful for every follower of this project to understand what happens in this PR. If you need to make any further code change to address the comments from reviewers, which means some new commits will be generated under this PR, you need to use 'git rebase' to combine those commits together.
|
||||
- Every PR should only solve one problem or provide one feature. Don't put several different fixes into one PR.
|
||||
- At lease two code reviewers should involve into code reviewing process.
|
||||
- Please introduce new third-party packages as little as possible to reduce the vendor dependency of this project. For example, don't import a full unit converting package but only use one function from it. For this case, you'd better write that function by yourself.
|
||||
|
|
|
|||
|
|
@ -1,41 +1,42 @@
|
|||
# Proposal Template for New Feature
|
||||
|
||||
> There are some good examples for new proposals:
|
||||
> - [Proposal for OpenEBS Volume (jiva) Snapshots using extended kubernetes Snapshot APIs](https://github.com/openebs/openebs/blob/master/contribute/design/openebs-jiva-snapshot-design.md)
|
||||
>- [Support extended-resource assignment to a Container](https://github.com/kubesphere/kubesphere/issues/1851)
|
||||
There are some good examples for new proposals:
|
||||
|
||||
Here is a Proposal Template for New Feature
|
||||
- [Proposal for OpenEBS Volume (jiva) Snapshots using Extended Kubernetes Snapshot APIs](https://github.com/openebs/openebs/blob/master/contribute/design/openebs-jiva-snapshot-design.md)
|
||||
- [Support Extended-resource Assignment to a Container](https://github.com/kubesphere/kubesphere/issues/1851)
|
||||
|
||||
Here is a proposal template for new feature.
|
||||
|
||||
## Background
|
||||
|
||||
<4-8 sentences about why this is needed>
|
||||
< 4-8 sentences about why this is needed >
|
||||
|
||||
## Proposal
|
||||
## Solution
|
||||
|
||||
<4-8 description of the proposed solution>
|
||||
< 4-8 sentences of the proposed solution >
|
||||
|
||||
## User Experience
|
||||
|
||||
### Use Cases
|
||||
|
||||
<enumerated list of use cases for this feature>
|
||||
< enumerated list of use cases for this feature >
|
||||
|
||||
<in depth description of user experience>
|
||||
< in depth description of user experience >
|
||||
|
||||
<*include full examples and references*>
|
||||
< include full examples and references >
|
||||
|
||||
## Implementation
|
||||
|
||||
<in depth description of how the feature will be implemented. In some cases this may be very simple.>
|
||||
< in depth description of how the feature will be implemented. In some cases this may be very simple. >
|
||||
|
||||
### High level overview
|
||||
### High Level Overview
|
||||
|
||||
<draw a diagram to describe your idea, it could be an architecture diagram>
|
||||
< draw a diagram to describe your idea, it could be an architecture diagram >
|
||||
|
||||
### API
|
||||
|
||||
<enumerated list of APIs and designs for this feature>
|
||||
< enumerated list of APIs and designs for this feature >
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
<short description of alternative solutions to be considered, you can attach some references to help us understand the Alternatives>
|
||||
< short description of alternative solutions to be considered, you can attach some references to help us understand the alternatives >
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# Design Documentation
|
||||
|
||||
This is the design documentation for each SIG.
|
||||
This is the design documentation for observability SIG.
|
||||
|
|
|
|||
|
|
@ -6,13 +6,14 @@ This document walks you through how to get started with building KubeSphere in y
|
|||
|
||||
### Go
|
||||
|
||||
KubeSphere development is based on [Kubernetes](https://github.com/kubernetes/kubernetes), both of them are written in [Go](http://golang.org/). If you don't have a Go development environment, please [set it up](http://golang.org/doc/code.html).
|
||||
KubeSphere development is based on [Kubernetes](https://github.com/kubernetes/kubernetes). Both of them are written in [Go](http://golang.org/). If you don't have a Go development environment, please [set it up](http://golang.org/doc/code.html) first.
|
||||
|
||||
| Kubernetes | requires Go |
|
||||
|----------------|-------------|
|
||||
| 1.13+ | >= 1.12 |
|
||||
|
||||
> Tips:
|
||||
>
|
||||
> - Ensure your GOPATH and PATH have been configured in accordance with the Go
|
||||
environment instructions.
|
||||
> - It's recommended to install [macOS GNU tools](https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x) when using MacOS for development.
|
||||
|
|
@ -21,8 +22,7 @@ environment instructions.
|
|||
|
||||
KubeSphere components are often deployed as containers in Kubernetes. If you need to rebuild the KubeSphere components in the Kubernetes cluster, you'll need to [install Docker](https://docs.docker.com/install/) in advance.
|
||||
|
||||
|
||||
### Dependency management
|
||||
### Dependency Management
|
||||
|
||||
KubeSphere uses [Go Modules](https://github.com/golang/go/wiki/Modules) to manage dependencies in the `vendor/` tree.
|
||||
|
||||
|
|
@ -30,17 +30,13 @@ KubeSphere uses [Go Modules](https://github.com/golang/go/wiki/Modules) to manag
|
|||
> In the CRD development process, you need to use tools to automatically generate code. The tools used by KubeSphere still need to rely on `GOPATH`.
|
||||
> For Chinese contributors who are going to pull the go module, we recommend you to use [goproxy.cn](https://goproxy.cn) as the proxy.
|
||||
|
||||
## Building KubeSphere Core on a local OS/shell environment
|
||||
## Building KubeSphere Core on a Local OS/shell Environment
|
||||
|
||||
### For Quick Taste Binary
|
||||
|
||||
When you go get KubeSphere, you can choose the version you want to get: `go get kubesphere.io/kubesphere@version-you-want`
|
||||
|
||||
>For modules stored in source control repositories, the version suffix can
|
||||
also be a commit hash, branch identifier, or other syntax known to the
|
||||
source control system, as in 'go get golang.org/x/text@master'.
|
||||
The version suffix @latest explicitly requests the default behavior
|
||||
described above.
|
||||
For modules stored in source control repositories, the version suffix can also be a commit hash, branch identifier, or other syntax known to the source control system, as in 'go get golang.org/x/text@master'. The version suffix @latest explicitly requests the default behavior described above.
|
||||
|
||||
> Note: Before getting KubeSphere, you need to synchronize the contents of the `replace` section of the go.mod file of the KubeSphere you want to version.
|
||||
|
||||
|
|
@ -85,8 +81,7 @@ docker build -f build/ks-controller-manager/Dockerfile -t $REPO/ks-controller-ma
|
|||
docker build -f ./pkg/db/Dockerfile -t $REPO/ks-devops:flyway-$TAG ./pkg/db/
|
||||
```
|
||||
|
||||
### For KubeSphere Core local development building.
|
||||
|
||||
### For KubeSphere Core Local Development Building
|
||||
|
||||
1. Create a `kubesphere` work directory under `GOPATH` and clone the source code.
|
||||
|
||||
|
|
|
|||
18
sigs.md
18
sigs.md
|
|
@ -1,32 +1,32 @@
|
|||
# KubeSphere Special Interest Groups
|
||||
|
||||
Most community activity is organized into Special Interest Group (SIGs).
|
||||
Most community activities are organized into a variety of Special Interest Group (SIGs).
|
||||
|
||||
## Why Special Interest Groups?
|
||||
## Why Special Interest Groups
|
||||
|
||||
KubeSphere SIGs are organizations responsible for the design and implementation of large architectural aspects of the overall KubeSphere project. SIGs operate with a fair amount of autonomy within the broader scope of the project.
|
||||
KubeSphere SIGs are organizations responsible for the design and implementation of some relatively large architectural aspects of the overall KubeSphere project. SIGs operate with a fair amount of autonomy within the broader scope of the project.
|
||||
|
||||
Generally, SIGs focus on specific technologies and features. For example, the storage SIG primarily focuses on design, integration and development for the Kubernetes-based storage within KubeSphere.
|
||||
|
||||
## Running a SIG
|
||||
## Run a SIG
|
||||
|
||||
Leads are responsible for running a SIG. Running the group involves a few activities:
|
||||
|
||||
- **Meetings**. Prepare the agenda and run the regular SIG meetings. Ensure the meetings are recorded, and properly archived on YouTube.
|
||||
|
||||
- **Operation**. Operate the related Slack channel and GitHub issue, make sure the questions and proposals are answered.
|
||||
- **Operation**. Operate the related Slack channel and GitHub issue, make sure the questions and proposals are answered in time.
|
||||
|
||||
- **Notes**. Ensure that meeting notes are kept up to date. Provide a link to the recorded meeting in the notes. The lead may delegate note-taking duties.
|
||||
|
||||
- **Roadmap**. Establish and maintain a roadmap for the SIG outlining the areas of focus for the SIG over the next 3 months.
|
||||
- **Roadmap**. Establish and maintain a roadmap for the SIG outlining the areas of focus for the SIG over the next three months.
|
||||
|
||||
### Be open
|
||||
### Be Open
|
||||
|
||||
The community design process is done in the open. SIGs should communicate primarily through the public tools, through design documents in the SIG’s folder, through GitHub issues, and GitHub PRs. Avoid private emails or messages when possible.
|
||||
|
||||
### Making decisions
|
||||
### Make Decisions
|
||||
|
||||
In general, SIGs operate in a highly cooperative environment. SIGs discuss designs in the open and take input from the community at large when making technical choices. The SIG leads are ultimately responsible for setting the direction of the SIG and making the technical choices affecting the SIG.
|
||||
In general, SIGs operate in a highly cooperative environment. The members of a SIG discuss designs in the open and take input from the community at large when making technical choices. The SIG leads are ultimately responsible for setting the direction of the SIG and making the technical choices affecting the SIG.
|
||||
|
||||
## SIGs
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue