init contribution and developer guides

Signed-off-by: FeynmanZhou <pengfeizhou@yunify.com>

README.md

@@ -1,2 +1,17 @@
-# community
-KubeSphere Community 
+# KubeSphere Community
+
+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!
+
+## 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.
+
+## 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.
+
+## 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.

cla.md

@@ -0,0 +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.
+
+## 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.
+
+## 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.
+
+## 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.
+
+## Your Representations and Warranties
+
+You represent and warrant that:
+
+- 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.

code-of-conduct.md

@@ -0,0 +1,17 @@
+# KubeSphere Code of Conduct
+
+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).  
+
+# 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.

contribution/design-proposal-template.md

@@ -0,0 +1,41 @@
+# 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)
+
+Here is a Proposal Template for New Feature
+
+## Background
+
+<4-8 sentences about why this is needed>
+
+## Proposal
+
+<4-8 description of the proposed solution>
+
+## User Experience
+
+### Use Cases
+
+<enumerated list of use cases for this feature>
+
+<in depth description of user experience>
+
+<*include full examples and references*>
+
+## Implementation
+
+<in depth description of how the feature will be implemented. In some cases this may be very simple.>
+
+### High level overview
+
+<draw a diagram to describe your idea, it could be an architecture diagram>
+
+### API
+
+<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>

contribution/design/README.md

@@ -0,0 +1,3 @@
+# Design Documentation
+
+This is the design documentation for each SIG.

contribution/design/sig-observability/README.md

@@ -0,0 +1,3 @@
+# Design Documentation
+
+This is the design documentation for each SIG.

developer-guide/concepts-and-designs/README.md

@@ -0,0 +1,64 @@
+# Concepts and Designs
+
+Concepts and Designs help you to learn and understand the KubeSphere and the landscape.
+
+## What is Kubesphere ?
+
+- [Overview and Core concepts](overview.md). Provides a high-level description and introduction, including the problems the project solves.
+ 
+- Project Goals. Provides the goals, which KubeSphere is trying to focus and provide features about them.
+
+After you read the above documents, you should understand the KubeSphere basic goals. Now, you can choose which following parts you are interested, then dive in.
+
+### KubeSphere Core 
+
+### KubeSphere Installer 
+
+### KubeSphere UI 
+
+TODO: UI opensource is on the way
+
+### KubeSphere Application Management 
+
+TODO(@pengcong)
+
+### KubeSphere Service Mesh 
+
+TODO(@zryfish)
+
+## Porter
+
+TODO(@magicsong)
+
+### KubeSphere Networking 
+
+TODO
+
+### KubeSphere DevOps 
+
+Read [DevOps Pipeline Overview](devops-pipeline-overview.md).
+
+### KubeSphere S2I/B2I 
+
+Read [S2I/B2I Overview](s2i_b2i_overview.md)
+
+### KubeSphere Monitoring 
+
+- [Overview](kubesphere-monitoring.md#Overview): Explains the architecture and key components behind the monitoring system.
+- [Setup](kubesphere-monitoring.md#Setup): Introduces manifests related to Prometheus setup.
+
+### KubeSphere Logging 
+
+- [Overview](kubesphere-logging.md#Overview): Explains the architecture and key components behind the logging system.
+- [Log Collection and Forward](kubesphere-logging.md#Log-Collection-and-Forward): Introduces logging agent and the sidecar-based solution for collecting application logs on disk.
+- [Log Store and Management](kubesphere-logging.md#Log-Store-and-Management): Introduces long-term log storage and management.
+- [Log Search, Export and Visualization](kubesphere-logging.md#Log-Search,-Export-and-Visualization): Introduces log query and reporting.
+
+### KubeSphere Altering 
+
+TODO
+
+### KubeSphere Notification 
+
+TODO
+

developer-guide/concepts-and-designs/overview.md

@@ -0,0 +1,34 @@
+# Overview
+
+KubeSphere is a multi-tenant cluster management platform which is based on Kubernetes. KubeSphere provides easy-to-use UI to reduce your learning cost for employing the container management platform and make it easier to develop, test and maintain your daily work. It's aimed to resolve the problems relating to Kubernetes’ storage, network, security and its usability.
+
+In addition, the platform has integrated and optimized a range of functional modules which are suitable for containers. KubeSphere provides enterprises with a complete solution for development, automation operation and maintenance, microservice governance, multi-tanency management. Besides, our platform is also able to manage workload, container cluster, service and network, application orchestration as well as database mirroring and storage.
+
+<table>
+  <tr>
+      <td width="50%" align="center"><b>KubeSphere Dashboard</b></td>
+      <td width="50%" align="center"><b>Project Resources</b></td>
+  </tr>
+  <tr>
+     <td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925003707.png"/></td>
+     <td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925003504.png"/></td>
+  </tr>
+  <tr>
+      <td width="50%" align="center"><b>CI/CD Pipeline</b></td>
+      <td width="50%" align="center"><b>Application Template</b></td>
+  </tr>
+  <tr>
+     <td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925000712.png"/></td>
+     <td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925231623.png"/></td>
+  </tr>
+</table>
+
+
+
+## Architecture
+
+
+
+KubeSphere adopts the separation of front and back ends, also realizes a cloud native design, the back ends' service components can communicate with external systems through the REST API, see [API documentation](https://kubesphere.io/docs/v2.0/api/kubesphere) for more details. All component are included in the architecture diagram below. KubeSphere can run anywhere from on-premise datacenter to any cloud to edge. In addition, it can be deployed on any Kubernetes distribution.
+
+![](https://pek3b.qingstor.com/kubesphere-docs/png/20190810073322.png)

developer-guide/concepts-and-designs/sig-devops/devops-pipeline-overview.md

@@ -0,0 +1,73 @@
+# KubeSphere DevOps Pipeline Overview
+
+KubeSphere DevOps Pipeline is aimed to meet the complex CI/CD requirements on Kubernetes.
+
+With the KubeSphere DevOps Pipeline, you can quickly construct a complete CI/CD workflow and architecture by manipulating with the KubeSphere console.
+
+
+## DevOps Pipeline Capabilities
+
+* Build, Deploy, Launch services in Kubernetes 
+* Use Kubernetes dynamic agent to release the ability of Kubernetes to dynamically expand
+* In SCM Pipeline and Out of SCM Pipeline 
+* Easy-to-use graphical pipeline editing panel 
+* Multi-tenant isolation
+
+
+### DevOps Pipeline API
+
+The KubeSphere DevOps Pipeline API will encapsulate the following APIs to provide a standardized REST API:
+
+- Jenkins Core API
+- Jenkins BlueOcean API
+- Sonarqube API
+- Other Plugins API
+
+KubeSphere apiserver will provide multi-tenant API, pipeline API, credential API, code quality analysis API, etc.
+
+![ks-devops-api](../../images/devops-api.png)
+
+
+### Multi-tenant isolation
+
+In the current version (v2.1.0), multi-tenancy in the DevOps part is done with the ability of the [role-strategy-plugin](https://github.com/jenkinsci/role-strategy-plugin) plugin. KubeSphere will automatically synchronize permission rules in this plugin.
+
+In the future, KubeSphere DevOps will authentication based on [OPA](https://www.openpolicyagent.org/).
+
+### Integration with Jenkins
+
+KubeSphere integrates with standard Jenkins, customizing plugins and configurations.
+
+#### Distribution of plugins
+
+To meet the needs of users in private cloud environments, KubeSphere uses the built-in nginx as a jenkins update center. The jenkins update center is provided as a Docker image + [Helm Chart](https://github.com/kubesphere/ks-installer/tree/master/roles/ks-devops/jenkins-update-center).
+
+#### Jenkins configuration
+
+KubeSphere uses Docker Image, Jenkins update Center and Helm Chart to distribute Jenkins。
+
+The list of plugins and configuration required by Jenkins will be provided by [Helm Chart](https://github.com/kubesphere/ks-installer/tree/master/roles/ks-devops/jenkins).
+
+We use [Groovy Script](https://wiki.jenkins.io/display/JENKINS/Groovy+Hook+Script) and [JCasC](https://github.com/jenkinsci/configuration-as-code-plugin) to initialize Jenkins.
+
+
+### Pipeline Builder Image And Jenkins PodTemplate
+
+Jenkins does not include any agent configuration by default, KubeSphere provides some default agents (including docker image and podTemplate configuration).
+
+The default agent image will be built based on the [builder base](https://github.com/kubesphere/builder-base), you can search the keyword of repository `builder xxx`  in KubeSphere [github](https://github.com/kubesphere/).
+
+### In SCM Pipeline and Out of SCM Pipeline 
+
+KubeSphere's pipeline syntax will be fully compatible with Jenkins' pipeline syntax. Jenkinsfile found in SCM will be supported with Jenkins plugin.
+
+We will provide a plug-in SCM API, allowing users to graphically edit Jenkinsfile, Dockerfile and other configurations in SCM on KubeSphere.
+
+### Sonarqube Integration
+
+KubeSphere will retrieve Jenkins pipelines that have performed Sonarqube code analysis. And provide API to access analysis report.
+
+
+### More
+
+If you have more questions, you can create an issue on [github](https://github.com/kubesphere/kubesphere)

developer-guide/concepts-and-designs/sig-devops/s2i_b2i_overview.md

@@ -0,0 +1,34 @@
+# KubeSphere S2I/B2I overview
+
+## What is S2I/B2I
+
+Kubesphere S2I(Source-to-Image) / B2I(Binary-to-Image) provides easy CI/CD functionalities, help developers to publish their service to Kubernetes without writing Dockefile.
+
+## Workflow Example
+
+![](https://pek3b.qingstor.com/kubesphere-docs/png/20191223103533.png)
+
+## Principle
+
+All resources of S2I/B2I will be installed in namespace `kubesphere-devops-system` by enable devops component.
+
+In S2I, all resources and CI/CD steps are defined with [Custom Resource Defintion](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD). You can operate all s2i resources by call k8s api directly.
+
+There are two mudules included in the S2I component:
+
+1. S2I Operator: A Kubernetes CRD controller that provides easy Kubernetes-style resources for declaring CI/CD-style pipelines
+2. S2IRun: It is the instance that executes the s2i build process in containers.
+
+Besides, the S2I stack includes following CRD resources:
+
+1. s2ibuildertemplates: defines information about S2I builder image.
+2. s2ibuilders: all configuration information used in building are stored in this CRD.
+3. s2iruns: defines an action about build
+
+Here is a graph that describes the relationship about all CRD within S2I architecture:
+
+​![](../../images/s2i_arch.png)
+
+Also you can install S2I component in any kubernetes cluster without KubeSphere.
+
+Want to see more about s2i, please jump to [S2I Operator](https://github.com/kubesphere/s2ioperator) and [S2IRun](https://github.com/kubesphere/s2irun)

developer-guide/concepts-and-designs/sig-observability/kubesphere-logging.md

@@ -0,0 +1,46 @@
+# KubeSphere Logging
+
+## Overview
+
+The KubeSphere logging system comprises many components that work together to achieve centralized log management. Once you enable the logging module during installation, a few components will be deployed or created within the namespace `kubesphere-logging-system`:
+
+- Fluent Bit: log collector deployed on each node.
+- Fluent-bit Operator: automates tasks for operating Fluent bit instances.
+- Logsidecar Injector: injects sidecar into pods for streaming on-disk files to stdout.
+- Elasticsearch Cluster: log storage backend.
+- Curator: performs stale log cleanup.
+
+The diagram below presents the overall logging architecture:
+
+![](../../images/kubesphere-logging-overview.png)
+
+The following sections will detail the design and functionality of each component. 
+
+## Log Collection and Forward
+
+There are two types of logs produced by containers:
+
+- stdout and stderr: written to `.log` files in the host's directory `/var/log/containers` by default.
+- application logs: files on the pod's volume, file locations may vary. 
+
+Fluent Bit serves as the logging agent. It can access host's container log directory and streams log files to stdout. In KubeSphere, we forked and modified the origin Fluent Bit project fluent/fluent-bit. The difference between fluent/fluent-bit and [kubesphere/fluent-bit](https://github.com/kubesphere/fluent-bit) is that we add a reload interface to support dynamic configuration (see issue [#365](https://github.com/fluent/fluent-bit/issues/365)).
+ 
+As shown in the diagram below, Fluent-bit controller implements the reload interface and is responsible for the life cycle of fluent-bit process.
+
+![](../../images/kubesphere-logging-fluentbit.png) 
+
+The approach to collect container logs on a pod's volume is using a log forwarder sidecar. The sidecar container forwards on-disk application logs to its own stdout. In this way, KubeSphere manages log collection in a unified manner. Besides, [Logsidecar Injector](https://github.com/kubesphere/logsidecar-injector) comes to automate sidecar injection. It takes advantages of `MutatingAdmissionWebhook` to control log forwarder sidecar injection during pod creation.
+
+Though Fluent Bit sends log to Elasticsearch by default in KubeSphere, you may change its output via editing the custom resource defined by the CustomResourceDefinition `fluentbits.logging.kubesphere.io`. The custom resource holds Fluent Bit input/filter/output configurations. Once changes detected, [Fluent-bit operator](https://github.com/kubesphere/fluentbit-operator) will trigger reloading and the new configuration will be used. The Operator pattern is the encouraged way to implement declarative configuration in Kubernetes. 
+
+## Log Store and Management
+
+Fluent Bit supports a bunch of [output plugins](https://docs.fluentbit.io/manual/output) that you can choose from to configure how logs will be stored or forwarded. On KubeSphere console, you can easily setup [elasticsearch](https://docs.fluentbit.io/manual/output/elasticsearch), [kafka](https://docs.fluentbit.io/manual/output/kafka) and [fluentd](https://docs.fluentbit.io/manual/output/forward) as outputs.
+
+Take Elasticsearch output for example. The default configuration writes that indices will be created daily with the prefix `ks-logstash-log`. It uses builtin Elasticsearch cluster whose address is `elasticsearch-logging-data.kubesphere-logging-system.svc`. For more details, please explore the custom resource `fluent-bit` (`kubectl get fluentbits.logging.kubesphere.io -n kubesphere-logging-system fluent-bit -oyaml`) .
+
+To clean up stale logs, the Elasticsearch curator cronjob performs a daily check at the cluster level. See [Curator](https://www.elastic.co/guide/en/elasticsearch/client/curator/current/index.html) for more information.
+
+## Log Search, Export and Visualization
+
+KubeSphere wraps Elasticsearch Search and Scroll APIs to support multi-tenancy. Users can use KubeSphere console to search and analyze logs as well as exporting logs to files. 

developer-guide/concepts-and-designs/sig-observability/kubesphere-monitoring.md

@@ -0,0 +1,36 @@
+# KubeSphere Monitoring
+
+## Overview
+
+The KubeSphere monitoring system comprises many components that work together to achieve overall monitoring functionality. KubeSphere defaults to installing the monitoring module. It will deploy  or create a few components within the namespace `kubesphere-monitoring-system`:
+
+- Prometheus Operator: automates tasks for operating Prometheus instances.
+- Prometheus: scrapes metrics and provides monitoring service.
+- Kube-state-metrics: exposes metrics for kubernetes objects like deployment, pod, namespace, etc.
+- Node-exporter: exposes node metrics.
+
+Besides, the monitoring stack includes CRD resources:
+
+- ServiceMonitor: declaratively specifies how groups of services should be monitored.
+- Prometheus: defines a desired Prometheus deployment.
+- PrometheusRule: defines a desired Prometheus rule file.
+
+In KubeSphere, Prometheus will monitor the following services by default: 
+
+- kube-state-metrics
+- node-exporter
+- kubelet
+- s2i-operator
+- etcd
+- coredns
+- kube-apiserver
+- kube-scheduler
+- kube-controller-manager
+
+## Setup
+
+The [contrib/kube-prometheus](https://github.com/kubesphere/prometheus-operator/tree/ks-v0.27.0/contrib/kube-prometheus) folder provides manifests for setting up the monitoring stack. The [kubernetes-mixin/rules](https://github.com/kubesphere/kubernetes-mixin/blob/ks-v0.27.0/rules/rules.libsonnet) project provides recording rule templates. KubeSphere monitoring backend serves as Prometheus client performing metrics query.
+
+The diagram below presents the overall monitoring architecture:
+
+![](../../images/kubesphere-monitoring-architecture.png)

developer-guide/development/README.md

@@ -0,0 +1,91 @@
+# Guides
+There are many ways that you can help the KubeSphere community.
+
+- Go through our documents, point out or fix unclear things. Translate the documents to other languages.
+- Install our [releases](https://kubesphere.io/en/install), try to manage your `kubernetes` cluster with `kubesphere`, and feedback to us about
+what you think.
+- Read our source codes, Ask questions for details.
+- Find kubesphere bugs, [submit issue](https://github.com/kubesphere/kubesphere/issues), and try to fix it.
+- Find kubesphere installer bugs, [submit issue](https://github.com/kubesphere/ks-installer/issues), and try to fix it.
+- Find [help wanted issues](https://github.com/kubesphere/kubesphere/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22),
+which are good for you to start.
+- Submit issue or start discussion through [GitHub issue](https://github.com/kubesphere/kubesphere/issues/new).
+- See all forum discussion through [website](https://kubesphere.io/forum/).
+
+## Contact Us
+All the following channels are open to the community, you could choose the way you like.
+* Submit an [issue](https://github.com/kubesphere/kubesphere/issues)
+* See all forum discussion through [website](https://kubesphere.io/forum/).
+* Join us at [Slack Channel](https://join.slack.com/t/kubesphere/shared_invite/enQtNTE3MDIxNzUxNzQ0LTZkNTdkYWNiYTVkMTM5ZThhODY1MjAyZmVlYWEwZmQ3ODQ1NmM1MGVkNWEzZTRhNzk0MzM5MmY4NDc3ZWVhMjE).
+
+## For code developer
+
+1. Learn about kubesphere's Concepts And Designs and how to build kubesphere locally  
+For developers, first step, read [Concepts And Designs](../concepts-and-designs/README.md) and [Compiling Guide](How-to-build.md).
+Concepts And Designs describes the role of each component in kubesphere and the relationship between them.
+Compiling Guide teaches developer how to build the project in local and set up the environment.
+
+2. Understand the workflow of kubesphere development.  
+Read [Development Workflow](Development-workflow.md).
+
+3. Learn KubeSphere code layout
+
+Read [KubeSphere Code Layout](Kubesphere-code-layout.md).
+
+4. Understand the best practices for submitting PR and our code of conduct  
+Read [best practices for submitting PR](pull-requests.md).  
+Read [code of conduct](code-of-conduct.md).
+
+
+### KubeSphere Installer developer
+
+### UI developer
+
+TODO: UI opensource is on the way
+
+### KubeSphere Application Management developer
+
+TODO(@pengcong)
+
+### KubeSphere Service Mesh developer
+
+TODO(@zryfish)
+
+### Porter developer
+
+TODO(@magicsong)
+
+### KubeSphere Networking developer
+
+### KubeSphere DevOps developer
+
+Users who are interested in DevOps Pipeline, you can read the documentation according to the [guidelines above](README.md#for-code-developer).
+
+The function of KubeSphere DevOps is mainly provided by KubeSphere apiserver.
+
+### KubeSphere S2I/B2I developer
+
+1. If users who are interested in S2I/B2I, please read [S2I/B2I](https://github.com/kubesphere/s2ioperator#source-to-image-operator) to get start it.
+
+2. For developers who want to contribute, see [Development Guide for S2I/B2I](https://github.com/kubesphere/s2ioperator/blob/master/docs/DEVELOPMENT.md)
+
+### KubeSphere Monitoring developer
+
+1. Read kubesphere's [Concepts And Designs for Monitoring](../concepts-and-designs/kubesphere-monitoring.md). Understand KubeSphere's monitoring stack.
+2. For Prometheus and its wider eco-system setup, go to [kube-prometheus](https://github.com/kubesphere/prometheus-operator/tree/ks-v0.27.0/contrib/kube-prometheus).
+3. For KubeSphere builtin metric rules, see [metrics_rules.go](https://github.com/kubesphere/kubesphere/blob/master/pkg/models/metrics/metrics_rules.go) and [kubernetes-mixin](https://github.com/kubesphere/kubernetes-mixin/blob/ks-v0.27.0/rules/rules.libsonnet).
+4. For developers who are interested in KubeSphere monitoring backend, read [Development Guide for Monitoring](kubesphere-monitoring-development-guide.md) and [API doc](https://kubesphere.com.cn/docs/v2.1/api/kubesphere#tag/Cluster-Metrics).
+
+### KubeSphere Logging developer
+
+1. Read kubesphere's [Concepts And Designs for Logging](../concepts-and-designs/kubesphere-logging.md). Understand KubeSphere's logging stack.
+2. Find the component you are interested in and start from its own repo: [Fluent Bit](https://github.com/kubesphere/fluent-bit), [Fluent-bit Operator](https://github.com/kubesphere/fluentbit-operator) and [Logsidecar Injector](https://github.com/kubesphere/logsidecar-injector).
+3. For developers who are interested in KubeSphere logging backend, read [Development Guide for Logging](kubesphere-logging-devlopment-guide.md) and [API doc](https://kubesphere.com.cn/docs/v2.1/api/kubesphere#tag/Log-Query).
+
+### KubeSphere Altering developer
+
+TODO
+
+### KubeSphere Notification developer
+
+TODO

developer-guide/development/development-workflow.md

@@ -0,0 +1,109 @@
+# Development Workflow
+
+![ks-workflow](/docs/images/ks-workflow.png)
+
+## 1 Fork in the cloud
+
+1. Visit https://github.com/kubesphere/kubesphere
+2. Click `Fork` button to establish a cloud-based fork.
+
+## 2 Clone fork to local storage
+
+Per Go's [workspace instructions](https://golang.org/doc/code.html#Workspaces), place KubeSphere' code on your `GOPATH` using the following cloning procedure.
+
+1. Define a local working directory:
+
+```bash
+$ export working_dir=$GOPATH/src/kubesphere.io
+$ export user={your github profile name}
+```
+
+2. Create your clone locally:
+
+```bash
+$ mkdir -p $working_dir
+$ cd $working_dir
+$ git clone https://github.com/$user/kubesphere.git
+$ cd $working_dir/kubesphere
+$ git remote add upstream https://github.com/kubesphere/kubesphere.git
+
+# Never push to upstream master
+$ git remote set-url --push upstream no_push
+
+# Confirm that your remotes make sense:
+$ git remote -v
+```
+
+## 3 Keep your branch in sync
+
+```bash
+git fetch upstream
+git checkout master
+git rebase upstream/master
+```
+
+## 4 Add new features or fix issues
+
+Branch from it:
+
+```bash
+$ git checkout -b myfeature
+```
+
+Then edit code on the myfeature branch.
+
+**Test and build**
+
+Currently, make rules only contain simple checks such as vet, unit test, will add e2e tests soon.
+
+**Using KubeBuilder**
+
+- For Linux OS, you can download and execute this [KubeBuilder script](https://raw.githubusercontent.com/kubesphere/kubesphere/master/hack/install_kubebuilder.sh).
+
+- For MacOS, you can install KubeBuilder by following this [guide](https://book.kubebuilder.io/quick-start.html).
+
+**Run and test**
+
+```bash
+$ make all
+# Run every unit test
+$ make test
+```
+
+Run `make help` for additional information on these make targets.
+
+### 5 Development in new branch
+
+**Sync with upstream**
+
+After the test is completed, suggest you to keep your local in sync with upstream which can avoid conflicts.
+
+```
+# Rebase your the master branch of your local repo.
+$ git checkout master
+$ git rebase upstream/master
+
+# Then make your development branch in sync with master branch
+git checkout new_feature
+git rebase -i master
+```
+**Commit local changes**
+
+```bash
+$ git add <file>
+$ git commit -s -m "add your description"
+```
+
+### 6 Push to your folk
+
+When ready to review (or just to establish an offsite backup or your work), push your branch to your fork on github.com:
+
+```
+$ git push -f ${your_remote_name} myfeature
+```
+
+### 7 Create a PR
+
+- Visit your fork at https://github.com/$user/kubesphere
+- Click the` Compare & Pull Request` button next to your myfeature branch.
+- Check out the [pull request process](pull-request.md) for more details and advice.

developer-guide/development/how-to-build.md

@@ -0,0 +1,120 @@
+# How to build KubeSphere?
+
+This document walks you through how to get started with building KubeSphere in your local environment.
+
+## Preparing the environment
+
+### 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).
+
+| 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.
+
+### Docker
+
+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
+
+KubeSphere uses [Go Modules](https://github.com/golang/go/wiki/Modules) to manage dependencies in the `vendor/` tree.
+
+> Note: KubeSphere uses `go module` to manage dependencies, but the development process still relies on `GOPATH`
+> 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
+
+### 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.
+
+> 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.
+
+```bash
+mkdir ks-tmp
+cd ks-tmp
+echo 'module kubesphere' > go.mod
+echo 'replace (
+        github.com/Sirupsen/logrus v1.4.1 => github.com/sirupsen/logrus v1.4.1
+      	github.com/kiali/kiali => github.com/kubesphere/kiali v0.15.1-0.20190407071308-6b5b818211c3
+      	github.com/kubernetes-sigs/application => github.com/kubesphere/application v0.0.0-20190518133311-b9d9eb0b5cf7
+      )' >> go.mod
+
+GO111MODULE=on go get kubesphere.io/kubesphere@d649e3d0bbc64bfba18816c904819e4850d021e0
+GO111MODULE=on go build -o ks-apiserver kubesphere.io/kubesphere/cmd/ks-apiserver # build ks-apiserver
+GO111MODULE=on go build -o ks-apigateway kubesphere.io/kubesphere/cmd/ks-apigateway # build ks-apigateway
+GO111MODULE=on go build -o ks-controller-manager kubesphere.io/kubesphere/cmd/controller-manager # build ks-controller-manager
+GO111MODULE=on go build -o ks-iam kubesphere.io/kubesphere/cmd/ks-iam # build ks-iam
+```
+
+### For Building KubeSphere Core Images
+
+KubeSphere components are often deployed as a container in a Kubernetes cluster, you may need to build a Docker image locally.
+
+1. Clone repo to local.
+
+```bash
+git clone https://github.com/kubesphere/kubesphere.git
+cd kubesphere
+```
+
+2. Run Docker command to build image.
+
+```bash
+# $REPO is the docker registry to push to
+# $Tag is the tag name of the docker image
+# The full go build process will be executed in the Dockerfile, so you may need to set GOPROXY in it.
+docker build -f build/ks-apigateway/Dockerfile -t $REPO/ks-apigateway:$TAG .
+docker build -f build/ks-apiserver/Dockerfile -t $REPO/ks-apiserver:$TAG .
+docker build -f build/ks-iam/Dockerfile -t $REPO/ks-account:$TAG .
+docker build -f build/ks-controller-manager/Dockerfile -t $REPO/ks-controller-manager:$TAG .
+docker build -f ./pkg/db/Dockerfile -t $REPO/ks-devops:flyway-$TAG ./pkg/db/
+```
+
+### For KubeSphere Core local development building.
+
+
+1. Create a `kubesphere` work directory under `GOPATH` and clone the source code.
+
+```bash
+mkdir -p $GOPATH/src/kubesphere.io/
+cd $GOPATH/src/kubesphere.io/
+git clone https://github.com/kubesphere/kubesphere
+```
+
+2. Use command `make` to build binary
+
+```bash
+make ks-apiserver # Build ks-apiserver binary
+make ks-iam # Build ks-iam binary
+make controller-manager # Build ks-controller-manager binary
+make ks-apigateway # Build ks-apigateway binary
+```
+
+If you need to build a docker image, you can refer to the previous section.
+
+### Test
+
+It‘s recommended to use local Kubernetes clusters, such as [minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/), or to install an single-node [all-in-one](https://github.com/kubesphere/kubesphere#all-in-one) environment (Kubernetes-based) for quick testing.
+
+> Tip: It also supports to use Docker for Desktop ships with Kubernetes as the test environment.
+
+
+## Building Other Module of KubeSphere
+
+Kubesphere has some pluggable modules such as ServiceMesh, DevOps, Logging, OpenPitrix ...
+Some of these modules have their unique build methods, refer to the their documentation accordingly.

developer-guide/development/how-to-connect-remote-service.md

@@ -0,0 +1,34 @@
+# Connect to remote service with telepresence
+
+Telepresence is an open source tool that lets you run a single service locally, while connecting that service to a remote Kubernetes cluster.
+
+We can use telepresence to help us running KubeSphere apiserver locally.
+
+
+## 1. Install telepresence
+
+You can read the [official installation documentation](https://www.telepresence.io/reference/install.html) to install telepresence.
+
+## 2. Run telepresence
+
+Open your command line and run the command `telepresence`, telepresence will help you to enter a bash connected to a remote Kubernetes cluster.
+
+Test telepresence with KubeSphere apigateway:
+
+```bash
+
+@kubernetes-admin@cluster.local|bash-3.2$ curl http://ks-apigateway.kubesphere-system
+
+401 Unauthorized
+```
+
+## 3. Run your module in bash
+
+Now your module can easily connect to remote services.
+
+```bash
+go run cmd/ks-apiserver/apiserver.go
+```
+## 4. Further more
+
+You can use telepresence to replace services in the cluster for debugging. For more information, please refer to the [official documentation](https://www.telepresence.io/discussion/overview).

developer-guide/development/how-to-run-kubesphere-core.md

@@ -0,0 +1,114 @@
+# How to run KubeSphere core in local
+
+This document will explain how to run KubeSphere apiserver locally.
+
+> Modules similar to KubeSphere apiserver are KubeSphere controller-manageer, Kubesphere iam (also known as KubeSphere account), KubeSphere api-gateway. 
+> If you need to run these modules locally, you can refer to this document for configuration.
+
+## Prepare: Build KubeSphere Core component
+
+In the document [How-to-build](How-to-build.md) We learned how to build KubeSphere locally. Make sure you could build KubeSphere Core modules accordingly.
+
+## 1. Set up a Kubernetes cluster with KubeSphere installed
+
+KubeSphere relies on some external modules during development, and these modules are already included in the installed KubeSphere.
+
+You can quickly install a KubeSphere cluster by referring to this [documentation] (https://kubesphere.io/en/install).
+
+## 2. Use kubectl to access the development cluster locally
+
+You can refer to this [document](https://kubernetes.io/docs/tasks/tools/install-kubectl/) to install and configure kubectl locally.
+
+## 3. Understand KubeSphere Core's configuration
+
+KubeSphere uses [viper](https://github.com/spf13/viper) to manage the configuration. KubeSphere supports setting up using command line arguments and configuration files.
+
+> We recommend that you use a configuration file for configuration during local development.
+
+KubeSphere apiserver needs to communicate with many modules. When you run Kubesphere, you can choose to configure the seperate modules only you care about.
+
+During the development of KubeSphere apiserver, you must configure at least the relevant part of Kubernetes to ensure that KubeSphere apiserver can be started.
+
+Below is a sample configuration of KubeSphere apiserver:
+
+> Note: In the default configuration, we use Kubernetes service name to access the service. 
+> In a remote cluster, you may need to use external network exposure to connect to the cluster's internal services.
+> Or you can refer to the [documentation](How-to-connect-remote-service.md) to use `telepresence` to connect to remote services
+
+```yaml
+kubernetes:
+  kubeconfig: "/Users/kubesphere/.kube/config"
+  master: https://192.168.0.8:6443
+  qps: 1e+06
+  burst: 1000000
+ldap:
+  host: openldap.kubesphere-system.svc:389
+  managerDN: cn=admin,dc=kubesphere,dc=io
+  managerPassword: admin
+  userSearchBase: ou=Users,dc=kubesphere,dc=io
+  groupSearchBase: ou=Groups,dc=kubesphere,dc=io
+redis:
+  host: redis.kubesphere-system.svc
+  port: 6379
+  password: ""
+  db: 0
+s3:
+  endpoint: http://minio.kubesphere-system.svc:9000
+  region: us-east-1
+  disableSSL: true
+  forcePathStyle: true
+  accessKeyID: openpitrixminioaccesskey
+  secretAccessKey: openpitrixminiosecretkey
+  bucket: s2i-binaries
+mysql:
+  host: mysql.kubesphere-system.svc:3306
+  username: root
+  password: password
+  maxIdleConnections: 100
+  maxOpenConnections: 100
+  maxConnectionLifeTime: 10s
+
+devops:
+  host: http://ks-jenkins.kubesphere-devops-system.svc/
+  username: admin
+  password: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6ImFkbWluQGt1YmVzcGhlcmUuaW8iLCJleHAiOjE4MTYyMzkwMjIsInVzZXJuYW1lIjoiYWRtaW4ifQ.okmNepQvZkBRe1M8z2HAWRN0AVj9ooVu79IafHKCjZI
+  maxConnections: 100
+sonarQube:
+  host: http://192.168.0.8:32297
+  token: 4e51de276f1fd0eb3a20b58e523d43ce76347302
+
+
+openpitrix:
+  runtimeManagerEndpoint:    "openpitrix-runtime-manager.openpitrix-system.svc:9103"
+  clusterManagerEndpoint:    "openpitrix-cluster-manager.openpitrix-system.svc:9104"
+  repoManagerEndpoint:       "openpitrix-repo-manager.openpitrix-system.svc:9101"
+  appManagerEndpoint:        "openpitrix-app-manager.openpitrix-system.svc:9102"
+  categoryManagerEndpoint:   "openpitrix-category-manager.openpitrix-system.svc:9113"
+  attachmentManagerEndpoint: "openpitrix-attachment-manager.openpitrix-system.svc:9122"
+  repoIndexerEndpoint:       "openpitrix-repo-indexer.openpitrix-system.svc:9108"
+
+monitoring:
+  endpoint: http://prometheus-k8s.kubesphere-monitoring-system.svc:9090
+  secondaryEndpoint: http://prometheus-k8s-system.kubesphere-monitoring-system.svc:9090
+
+logging:
+  host: http://elasticsearch-logging-data.kubesphere-logging-system.svc.cluster.local:9200
+  indexPrefix: ks-logstash-log
+
+alerting:
+  endpoint: http://alerting.kubesphere-alerting-system.svc
+
+notification:
+  endpoint: http://notification.kubesphere-alerting-system.svc
+```
+
+## 4. Set Up KubeSphere Core's configuration
+
+The KubeSphere Core module will read the `kubesphere.yaml` file in the current directory and the `kubesphere.yaml` file in the `/etc/kubesphere` directory, then load the configuration at startup.
+You can choose a path to set your configuration locally.
+
+## 5. Run KubeSphere apiserver 
+
+You can execute `go run cmd/ks-apiserver/apiserver.go` in the `$GOPATH/src/kubesphere.io/kubesphere` directory to start KubeSphere apiserver
+
+> If you want to understand the specific meaning of each configuration, you can view it by `go run cmd/ks-apiserver/apiserver.go --help` or read the module's design and developer documentation.

developer-guide/development/kubesphere-code-layout.md

@@ -0,0 +1,167 @@
+# KubeSphere File Tree
+
+This document describes the directory structure of the KubeSphere repository.
+
+
+```
+├── api // Automatically generated API documentation
+│   ├── api-rules
+│   ├── ks-openapi-spec // REST API documentation provided by kubesphere apiserver
+│   └── openapi-spec // REST API documentation provided by kubesphere apiserver
+├── build // Dockerfile 
+│   ├── hypersphere 
+│   ├── ks-apigateway
+│   ├── ks-apiserver
+│   ├── ks-controller-manager
+│   ├── ks-iam
+│   └── ks-network
+├── cmd // Main applications for KubeSphere.
+│   ├── controller-manager  // Kubesphere Controller Manger, used to reconcile KubeSphere CCRD
+│   │   └── app
+│   ├── hypersphere 
+│   ├── ks-apigateway // KubeSphere API gateway
+│   │   └── app
+│   ├── ks-apiserver // KubeSphere REST API server
+│   │   └── app
+│   ├── ks-iam // KubeSphere iam service
+│   │   └── app
+│   └── ks-network
+├── config // CRD config files
+│   ├── crds // CRD yaml files
+│   ├── default // kustomization yaml files
+│   ├── manager // controller manager yaml files
+│   ├── rbac // rbac yaml files
+│   ├── samples // CRD sample
+│   └── webhook // webhppk yaml files
+├── docs 
+│   ├── en
+│   │   ├── concepts-and-designs
+│   │   └── guides
+│   └── images
+├── hack // Script files to help people develop
+│   └── lib
+├── pkg // Library code. 
+│   ├── api // Structure definitions for REST APIs
+│   │   ├── devops
+│   │   ├── logging
+│   │   └── monitoring
+│   ├── apigateway 
+│   │   └── caddy-plugin
+│   ├── apis // Structure definitions for CRDs
+│   │   ├── devops
+│   │   ├── network
+│   │   ├── servicemesh
+│   │   └── tenant
+│   ├── apiserver // REST API parameter processing
+│   │   ├── components
+│   │   ├── devops
+│   │   ├── git
+│   │   ├── iam
+│   │   ├── logging
+│   │   ├── monitoring
+│   │   ├── openpitrix
+│   │   ├── operations
+│   │   ├── quotas
+│   │   ├── registries
+│   │   ├── resources
+│   │   ├── revisions
+│   │   ├── routers
+│   │   ├── runtime
+│   │   ├── servicemesh
+│   │   ├── tenant
+│   │   ├── terminal
+│   │   ├── workloadstatuses
+│   │   └── workspaces
+│   ├── client //Automatically generated CRD client
+│   │   ├── clientset
+│   │   ├── informers
+│   │   └── listers
+│   ├── constants // common constants
+│   ├── controller // controller manger's reconciliation logic
+│   │   ├── application
+│   │   ├── clusterrolebinding
+│   │   ├── destinationrule
+│   │   ├── job
+│   │   ├── namespace
+│   │   ├── network
+│   │   ├── s2ibinary
+│   │   ├── s2irun
+│   │   ├── storage
+│   │   ├── virtualservice
+│   │   └── workspace
+│   ├── db // Database ORM Framework
+│   │   ├── ddl
+│   │   ├── schema
+│   │   └── scripts
+│   ├── gojenkins // Jenkins Go Client
+│   │   ├── _tests
+│   │   └── utils
+│   ├── informers
+│   ├── kapis // REST API registration
+│   │   ├── devops
+│   │   ├── iam
+│   │   ├── logging
+│   │   ├── monitoring
+│   │   ├── openpitrix
+│   │   ├── operations
+│   │   ├── resources
+│   │   ├── servicemesh
+│   │   ├── tenant
+│   │   └── terminal
+│   ├── models // Data processing part of REST API
+│   │   ├── components
+│   │   ├── devops
+│   │   ├── git
+│   │   ├── iam
+│   │   ├── kubeconfig
+│   │   ├── kubectl
+│   │   ├── log
+│   │   ├── metrics
+│   │   ├── nodes
+│   │   ├── openpitrix
+│   │   ├── quotas
+│   │   ├── registries
+│   │   ├── resources
+│   │   ├── revisions
+│   │   ├── routers
+│   │   ├── servicemesh
+│   │   ├── status
+│   │   ├── storage
+│   │   ├── tenant
+│   │   ├── terminal
+│   │   ├── workloads
+│   │   └── workspaces
+│   ├── server // Data processing part of REST API
+│   │   ├── config
+│   │   ├── errors
+│   │   ├── filter
+│   │   ├── options
+│   │   └── params
+│   ├── simple // common clients
+│   │   └── client
+│   ├── test
+│   ├── utils // common utils
+│   │   ├── hashutil
+│   │   ├── idutils
+│   │   ├── iputil
+│   │   ├── jsonutil
+│   │   ├── jwtutil
+│   │   ├── k8sutil
+│   │   ├── net
+│   │   ├── readerutils
+│   │   ├── reflectutils
+│   │   ├── signals
+│   │   ├── sliceutil
+│   │   ├── stringutils
+│   │   └── term
+│   ├── version
+│   └── webhook
+├── test // e2e test code
+│   ├── e2e
+├── tools // tools to genereate API docs
+│   ├── cmd
+│   │   ├── crd-doc-gen // gen CRD API docs
+│   │   └── doc-gen // gen REST API docs
+│   └── lib
+
+```

developer-guide/development/pull-requests.md

@@ -0,0 +1,144 @@
+# Pull Request Process
+
+This doc explains the process and best practices for submitting a PR to the [KubeSphere project](https://github.com/kubeSphere/kubeSphere). It should serve as a reference for all contributors, and be useful especially to new and infrequent submitters.
+
+- [Before You Submit a PR](#before-you-submit-a-pr)
+  * [Run Local Verifications](#run-local-verifications)
+- [The PR Submit Process](#the-pr-submit-process)
+  * [Write Release Notes if Needed](#write-release-notes-if-needed)
+  * [The Testing and Merge Workflow](#the-testing-and-merge-workflow)
+  * [Marking Unfinished Pull Requests](#marking-unfinished-pull-requests)
+  * [Comment Commands Reference](#comment-commands-reference)
+  * [Automation](#automation)
+  * [How the e2e Tests Work](#how-the-e2e-tests-work)
+
+
+
+# Before You Submit a PR
+
+This guide is for contributors who already have a PR to submit. If you're looking for information on setting up your developer environment and creating code to contribute to KubeSphere, see the [development guide](development.md).
+
+**Make sure your PR adheres to our best practices. These include following project conventions, making small PRs, and commenting thoroughly. Please read the more detailed section on [Best Practices for Faster Reviews](#best-practices-for-faster-reviews) at the end of this doc.**
+
+## Run Local Verifications
+
+You can run these local verifications before you submit your PR to predict the
+pass or fail of continuous integration.
+
+# The PR Submit Process
+
+Merging a PR requires the following steps to be completed before the PR will be merged automatically. For details about each step, see the [The Testing and Merge Workflow](#the-testing-and-merge-workflow) section below.
+
+- Make the PR
+- Release notes - do one of the following:
+  - Add notes in the release notes block, or
+  - Update the release note label
+- Pass all tests
+- Get a `/lgtm` from a reviewer
+- Get approval from an owner
+
+If your PR meets all of the steps above, it will enter the submit queue to be merged. When it is next in line to be merged, the tests will run a second time. If all tests pass, the PR will be merged automatically.
+
+## Write Release Notes if Needed
+
+Release notes are required for any PR with user-visible changes, such as bug-fixes, feature additions, and output format changes.
+
+If you don't add release notes in the PR template, the `do-not-merge/release-note-label-needed` label is added to your PR automatically after you create it. There are a few ways to update it.
+
+To add a release-note section to the PR description:
+
+For PRs with a release note:
+
+    ```release-note
+    Your release note here
+    ```
+
+For PRs that require additional action from users switching to the new release, include the string "action required" (case insensitive) in the release note:
+
+    ```release-note
+    action required: your release note here
+    ```
+
+For PRs that don't need to be mentioned at release time, just write "NONE" (case insensitive):
+
+    ```release-note
+    NONE
+    ```
+
+The `/release-note-none` comment command can still be used as an alternative to writing "NONE" in the release-note block if it is left empty.
+
+To see how to format your release notes, view the [PR template](https://github.com/) for a brief example. PR titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
+// PR template TODO
+
+Release notes apply to PRs on the master branch. For cherry-pick PRs, see the [cherry-pick instructions](cherry-picks.md). The only exception to these rules is when a PR is not a cherry-pick and is targeted directly to the non-master branch.  In this case, a `release-note-*` label is required for that non-master PR.
+
+// cherry-pick TODO
+
+Now that your release notes are in shape, let's look at how the PR gets tested and merged.
+
+## The Testing and Merge Workflow
+
+The KubeSphere merge workflow uses comments to run tests and labels for merging PRs.
+NOTE: For pull requests that are in progress but not ready for review,
+prefix the PR title with `WIP` or `[WIP]` and track any remaining TODOs
+in a checklist in the pull request description.
+
+Here's the process the PR goes through on its way from submission to merging:
+
+1. Make the pull request
+1. `@o8x-merge-robot` assigns reviewers //TODO
+
+If you're **not** a member of the KubeSphere organization:
+
+1. Reviewer/KubeSphere Member checks that the PR is safe to test. If so, they comment `/ok-to-test`
+1. Reviewer suggests edits
+1. Push edits to your PR branch
+1. Repeat the prior two steps as needed
+1. (Optional) Some reviewers prefer that you squash commits at this step
+1. Owner is assigned and will add the `/approve` label to the PR
+
+If you are a member, or a member comments `/ok-to-test`, the PR will be considered to be trusted. Then the pre-submit tests will run:
+
+1. Automatic tests run. See the current list of tests on the
+1. If tests fail, resolve issues by pushing edits to your PR branch
+1. If the failure is a flake, anyone on trusted PRs can comment `/retest` to rerun failed tests
+
+Once the tests pass, all failures are commented as flakes, or the reviewer adds the labels `lgtm` and `approved`, the PR enters the final merge queue. The merge queue is needed to make sure no incompatible changes have been introduced by other PRs since the tests were last run on your PR.
+
+Either the [on call contributor](on-call-rotations.md) will manage the merge queue manually. //TODO
+
+1. The PR enters the merge queue ([http://submit-queue.KubeSphere.io]())
+1. The merge queue triggers a test re-run with the comment `/test all [submit-queue is verifying that this PR is safe to merge]`
+    1. Author has signed the CLA (`cncf-cla: yes` label added to PR)
+    1. No changes made since last `lgtm` label applied
+1. If tests fail, resolve issues by pushing edits to your PR branch
+1. If the failure is a flake, anyone can comment `/retest` if the PR is trusted
+1. If tests pass, the merge queue automatically merges the PR
+
+That's the last step. Your PR is now merged.
+
+## Marking Unfinished Pull Requests
+
+If you want to solicit reviews before the implementation of your pull request is complete, you should hold your pull request to ensure that the merge queue does not pick it up and attempt to merge it. There are two methods to achieve this:
+
+1. You may add the `/hold` or `/hold cancel` comment commands
+2. You may add or remove a `WIP` or `[WIP]` prefix to your pull request title
+
+The GitHub robots will add and remove the `do-not-merge/hold` label as you use the comment commands and the `do-not-merge/work-in-progress` label as you edit your title. While either label is present, your pull request will not be considered for merging.
+
+
+## Comment Commands Reference//TODO
+
+[The commands doc]() contains a reference for all comment commands. //TODO
+
+## Automation//TODO
+
+The KubeSphere developer community uses a variety of automation to manage pull requests.  This automation is described in detail [in the automation doc](automation.md). //TODO
+
+## How the e2e Tests Work//TODO
+
+The  tests will post the status results to the PR. If an e2e test fails,
+`@o8x-ci-robot` will comment on the PR with the test history and the
+comment-command to re-run that test. e.g.
+
+> The following tests failed, say /retest to rerun them all.

developer-guide/development/sig-observability/kubesphere-logging-devlopment-guide.md

@@ -0,0 +1,60 @@
+# Logging
+
+This documentation contains backend development guides for interaction with key components behind KubeSphere logging system. Logging backend provides the capabilities of:
+ 
+ - Log search
+ - Log export
+ - Log output configuration
+ - Multi-tenant isolation
+
+## File Tree
+
+The listing below covers all folders related to the logging backend.
+
+```
+/pkg
+  ├─api
+  │  └─logging            # declares structs for api responses
+  │     └─v1alpha2             
+  ├─apiserver             # implements handler for http requests
+  │  ├─logging            
+  │  └─tenant
+  ├─kapis                 # registers APIs and routing
+  │  ├─logging
+  │  │  ├─install
+  │  │  └─v1alpha2
+  │  ├─tenant
+  │  │  ├─install
+  │  │  └─v1alpha2
+  ├─models                
+  │  ├─log                # constants, utils and fluent-bit crd operation
+  │  │  ├─constants.go
+  │  │  ├─logcollector.go # some utils
+  │  │  ├─logcrd.go       # interacts with fluent-bit crd
+  │  │  └─types.go
+  │  └─tenant
+  └─simple
+     ├─factory.go         # contains factory functions for es client options
+     └─client
+        ├─elasticsearch   # wraps es search apis
+        │  ├─esclient.go  # constructs es search body 
+        │  ├─interface.go # general interface methods for es clients
+        │  ├─options.go   # es client options
+        │  └─versions     # client code by es versions
+        │     ├─v5
+        │     ├─v6
+        │     └─v7
+        └─fluentbit       # autogenerated client code for fluent-bit crd
+```
+
+## API Design
+
+There are two types of APIs in logging. One for log query, and the other for interacting with the CustomResourceDefinition used by [Fluent-bit Operator](https://github.com/kubesphere/fluentbit-operator). For information about CRD and Fluent-bit Operator, please go to its own repo.
+ 
+To support multi-tenant isolation, KubeSphere's logging query APIs have the format like below, though the underlying logic is using Elastic Search APIs:
+  
+```
+GET /namespaces/{namespace}/pods/{pod}/containers/{container}
+```
+
+KubeSphere API gateway will decode the URL and conduct authorization. A person who doesn't belong to a namespace will be rejected to make a request.

developer-guide/development/sig-observability/kubesphere-monitoring-development-guide.md

@@ -0,0 +1,49 @@
+# Monitoring
+
+This documentation contains backend development guides for interaction with Prometheus. The monitoring backend provides the capabilities of:
+
+ - Metrics query
+ - Metrics sorting
+ - Multi-tenant isolation
+
+## File Tree
+
+The listing below covers all folders related to the monitoring backend.
+
+```
+/pkg
+  ├─api
+  │  └─monitoring         # declares structs for api responses
+  │     └─v1alpha2
+  ├─apiserver             # implements handler for http requests
+  │  └─monitoring
+  ├─kapis                 # registers APIs and routing
+  │  └─monitoring
+  │     ├─install
+  │     └─v1alpha2
+  ├─models
+  │  └─metrics
+  │     ├─constants.go
+  │     ├─metrics.go       # proxies prometheus metrics query
+  │     ├─metrics_rules.go # promql expressions for builtin metrics
+  │     ├─namespaces.go    # appends metric info to namespace resource request
+  │     ├─types.go
+  │     └─util.go          # metrics sorting
+  └─simple
+     ├─factory.go          # factory functions for prometheus client options
+     └─client
+        └─prometheus
+           ├─options.go    # prometheus client options
+           └─prometheus.go # prometheus client code
+```
+
+## API Design
+
+To support multi-tenant isolation, the monitoring backend proxies Prometheus query requests. KubeSphere's APIs have the format like below:
+
+```
+GET /namespaces/{namespace}/pods
+GET /namespaces/{namespace}/pods/{pod}
+```
+
+KubeSphere API gateway will decode the URL and conduct authorization. A person who doesn't belong to a namespace will be rejected to make a request. Besides, note that the two examples above have slightly different meanings. The first is to retrieve all pod-level metrics in the namespace, while the latter is for a specific pod.

sigs.md

@@ -0,0 +1,39 @@
+# KubeSphere Special Interest Groups
+
+Most community activity is organized into Special Interest Group (SIGs).
+
+## 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.
+
+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
+
+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.
+
+- **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.
+
+### 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
+
+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.
+
+## SIGs
+
+The current SIGs are:
+
+| Group | Lead | Name | Design Docs |  Slack Channel | To do (GitHub Issues) | Description
+|-------|-------------|-------|---------------|--------------|-------------------- | -----
+| Observability | <img width="30px" src="https://avatars2.githubusercontent.com/u/18525465?s=96&v=4">| [Benjamin Huo](https://github.com/benjaminhuo) | [Design documentation](./contribution/design/sig-observability) | [#observability](https://kubesphere.slack.com/archives/CLHL8R1C7) | [Tasks & Issues](https://github.com/kubesphere/kubesphere/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fmonitoring+) | Logging, Monitoring, Alerting, Notification |
+
+> Please add your information in the table above.