github/kubevela
1
0
Fork 0
mirror of https://github.com/kubevela/kubevela.git synced 2026-08-27 16:17:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

Docs: overhaul CONTRIBUTING.md and issue templates (#7337)

Browse Source 
* Docs: overhaul CONTRIBUTING.md and issue templates

Expand the root CONTRIBUTING.md from a one-line redirect into a real front door covering the Code of Conduct, ways to contribute, DCO sign-off, and links to governance and security. Convert the bug and feature issue templates from free-text Markdown into GitHub issue forms with required version fields and a duplicate-search checkbox, merging the separate enhancement template into the feature form. Fix stale oam-dev/kubevela references in bot.md, issue-commands.json, and ISSUE_TRIAGE.md, add a Security contact link and disable blank issues in the issue template config, and add a DCO checklist item to the pull request template.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: expand GOVERNANCE.md and community.md stubs

GOVERNANCE.md and community.md were one and two line redirects to the community repo. Both now cover Code of Conduct, meetings, KEP process, membership ladder, security, and releases (GOVERNANCE.md) or communication channels, how to get involved, and governance links (community.md), as short maps that link out to the community repo for anything that changes often, rather than duplicating it. CONTRIBUTING.md's Communication line now points at the local community.md first.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: rename community.md to COMMUNITY.md

Match the all-caps naming used by CONTRIBUTING.md, GOVERNANCE.md, CODE_OF_CONDUCT.md, and SECURITY.md.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: fix stale domains in README and de-duplicate ISSUE_TRIAGE.md

README.md had three kubevela.net links left over from the domain move to kubevela.io, and a Contact Us / Community Call section that duplicated, and disagreed with on cadence, what COMMUNITY.md now documents. Point Community, Contributing, and Report Vulnerability at the local COMMUNITY.md, CONTRIBUTING.md, and SECURITY.md instead of re-describing them inline.

ISSUE_TRIAGE.md was a full copy of the community repo's canonical document. That's how it went stale in the first place, still referencing oam-dev/kubevela after the org move. Replaced it with a short pointer to the canonical copy, matching how GOVERNANCE.md and COMMUNITY.md already work.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: bring contribute/ folder up to the same standard

These six files were the original bare-stub redirects this whole pass started from. Their links were already correct, unlike everything else touched in this branch, but they were the last remaining one-line 'please refer to X' pages in the repo. Each now has a short line of real context before the link, and README.md cross-links the new CONTRIBUTING.md front door instead of only pointing out to kubevela.io.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: remove contribute/ folder, fold it into CONTRIBUTING.md

The contribute/ folder was six tiny files that each pointed at one kubevela.io page, and every one of those pages was already linked from CONTRIBUTING.md's Ways to contribute and More sections. Keeping both meant two indexes into the same handful of pages, organized differently, with no content of its own beyond the links. Folded the two links CONTRIBUTING.md was missing, code conventions and test principles, into the Code bullet, and removed the folder. The develop-code-flow.pdf diagram wasn't linked from anywhere in the repo and duplicates what release-process.md already covers, so it goes too.

PULL_REQUEST_TEMPLATE.md's contribution process checklist item pointed at contribute/create-pull-request.md; repointed it at CONTRIBUTING.md. Confirmed with a repo-wide grep that nothing else referenced the contribute/ path.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: fix dangling references flagged by review

Three real issues from automated review, still present at HEAD: GOVERNANCE.md's membership sentence read as four roles after three levels beyond contributor instead of three, missing a colon. README.md claimed the meeting schedule lives in COMMUNITY.md, which explicitly says it doesn't. ISSUE_TRIAGE.md attributed the type/area/priority label taxonomy to COMMUNITY.md, which never describes those labels, repointed to the canonical ISSUE_TRIAGE.md already linked at the top of the same file.

Two other flagged issues (CONTRIBUTING.md's issue-triage and governance links) were valid against an earlier commit but got resolved in the opposite direction by later commits in this branch, converting ISSUE_TRIAGE.md and GOVERNANCE.md into pointers/maps rather than repointing links at them. The type/feature label flag is accurate but intentional, a maintainer is creating that label.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: split feature and enhancement issue forms back apart

The merged feature_request.yml applied type/feature regardless of which option the kind dropdown picked, silently dropping the type/enhancement distinction the old enhancement_request.md preserved and that ISSUE_TRIAGE.md and issue-commands.json still reference. GitHub issue forms can't conditionally set a label based on a form answer, so the only way to keep both labels working is two templates again: feature_request.yml (type/feature, for net-new capability) and enhancement_request.yml (type/enhancement, for improving something that exists), each asking only the questions relevant to that case.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: link PR template directly to the pull request process

CONTRIBUTING.md is a front door, not the PR process itself, it links out to code-contribute.md for that. Pointing the PR template's checklist item straight at the section with the actual process (title format, DCO, backport labels) saves the contributor an extra hop at the exact moment they're creating a PR, matching how Kubernetes and Crossplane link their PR templates directly to the dev guide. Verified the anchor resolves on the live page before pushing.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: add a Quick start section to CONTRIBUTING.md

Compared to peer CNCF projects (Kubernetes, Crossplane, etcd, Helm), CONTRIBUTING.md had zero runnable commands, a contributor had to click through to kubevela.io just to learn how to build or test locally. Added the three commands that matter most (make, make test, make reviewable, all verified against the actual Makefile targets) so the basics don't require leaving the repo.

Left the fuller dev environment setup, coding style rules, and PR lifecycle narrative as link-outs rather than duplicating them here, that content is detailed enough (Go/kustomize/CUE/kubebuilder versions, VelaUX, e2e setup) that inlining it would just recreate the drift problem ISSUE_TRIAGE.md had before this PR.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: document commit message format in CONTRIBUTING.md

etcd, Kubernetes, and Helm all state their commit message convention directly in CONTRIBUTING.md. KubeVela has one too (Type: subject, documented in full at code-contribute.md#formatting-guidelines) but it was never mentioned here. Added the format and three real examples inline, kept the full scope/area rules and PR title/squash policy as a link-out rather than duplicating all of it.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: drop unrelated tagline from bot comments

issue-commands.json's bot/duplicate and bot/no new info comments both ended with 'Happy graphing!', a leftover from some other project's bot config with nothing to do with KubeVela. Already editing this file for the org-name fixes, so dropped the tagline from both, and fixed a duplicated 'you you' typo in the second one while there.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: break up long Ways to contribute bullets

The Code bullet ran past 400 characters on one line. Split Code, Docs, Issue triage, and Everything else into a lead-in plus sub-bullets, matching Crossplane's CONTRIBUTING style, left Answer questions as a single line since it was already short enough to scan. No content changed, just line length.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: add existing-issue-search checkbox to feature and enhancement forms

bug_report.yml has a required checkbox confirming the reporter searched for duplicates first; feature_request.yml and enhancement_request.yml didn't, despite Kubernetes applying this consistently across all its issue forms. Added the same required checkbox to both, worded for a feature/enhancement rather than a bug.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Docs: fix comma splice in COMMUNITY.md

Split one sentence into two instead of joining them with a comma.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

* Chore: add roguepikachu to comment.userlist

Grants triage bot comment command access per bot.md.

Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com>

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>

---------

Signed-off-by: Jerrin Francis <jerrinfrancis7@gmail.com>
This commit is contained in:
Ayush Kumar
2026-08-19 13:33:30 +01:00
committed by GitHub
parent 5cf3e3a80a
commit 5b70fcc006
24 changed files with 366 additions and 487 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/ISSUE_TEMPLATE/bug_report.md
-49
View File
@@ -1,49 +0,0 @@
---
name: "\U0001F41B Bug report"
about: Create a report to help us improve
title: ""
labels: type/bug
assignees: ''
---
**Describe the bug**
<!--
A clear and concise description of what the bug is.
-->
**To Reproduce**
<!--
Steps to reproduce the behavior:
1. The YAML files of Component/Trait I used.
2. The YAML file of Application I applied.
3. Other operations I have done.
4. See error
-->
**Expected behavior**
<!--
A clear and concise description of what you expected to happen.
-->
**Screenshots**
<!--
If applicable, add screenshots to help explain your problem.
-->
**KubeVela Version**
<!--
Describe your KubeVela controller or CLI version information.
-->
**Cluster information**
<!--
Describe your kubernetes cluster information.
- Kubernetes Version [e.g. 1.16.9]
-->
**Additional context**
<!--
Add any other context about the problem here.
-->
.github/ISSUE_TEMPLATE/bug_report.yml
+85
View File
@@ -0,0 +1,85 @@
name: "🐛 Bug report"
description: Create a report to help us improve
title: ""
labels: ["type/bug"]
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this bug report. Please search [existing issues](https://github.com/kubevela/kubevela/issues) first to avoid duplicates.
- type: checkboxes
id: existing-search
attributes:
label: Is there an existing issue for this?
description: Please search to see if an issue already exists for the bug you encountered.
options:
- label: I have searched the existing issues
required: true
- type: dropdown
id: area
attributes:
label: Affected area
description: Which part of KubeVela does this affect? Pick the closest match.
options:
- Application controller
- Component / ComponentDefinition
- Trait / TraitDefinition
- Workflow / WorkflowStepDefinition
- Policy
- CUE templating
- CLI (vela)
- Addon
- Multi-cluster
- Helm chart / installation
- Other / not sure
validations:
required: true
- type: input
id: kubevela-version
attributes:
label: KubeVela version
description: Output of `vela version`, covering both the CLI and the controller.
placeholder: e.g. v1.9.0
validations:
required: true
- type: input
id: k8s-version
attributes:
label: Kubernetes version and distribution
description: The Kubernetes version and where it runs.
placeholder: e.g. v1.28.3, EKS
validations:
required: true
- type: textarea
id: describe-bug
attributes:
label: Describe the bug
description: A clear and concise description of what the bug is.
validations:
required: true
- type: textarea
id: reproduce
attributes:
label: To reproduce
description: Steps to reproduce the behavior. Include the YAML of any Application, Component, or Trait you used.
placeholder: |
1. Applied this Application YAML: ...
2. Ran this command: ...
3. Observed: ...
validations:
required: true
- type: textarea
id: expected
attributes:
label: Expected behavior
description: A clear and concise description of what you expected to happen.
- type: textarea
id: screenshots
attributes:
label: Screenshots or logs
description: If applicable, add screenshots or relevant controller logs to help explain the problem.
- type: textarea
id: additional
attributes:
label: Additional context
description: Add any other context about the problem here.
.github/ISSUE_TEMPLATE/config.yml
+5 -2
View File
@@ -1,5 +1,8 @@
blank_issues_enabled: true
blank_issues_enabled: false
contact_links:
- name: Questions & Help
url: https://github.com/oam-dev/kubevela/discussions
url: https://github.com/kubevela/kubevela/discussions
about: Please ask and answer questions here.
- name: Security
url: https://github.com/kubevela/kubevela/blob/master/SECURITY.md
about: Do not file a public issue for a security vulnerability. Report it privately by following our security policy.
.github/ISSUE_TEMPLATE/enhancement_request.md
-28
View File
@@ -1,28 +0,0 @@
---
name: "✨ Enhancement request"
about: Suggest an improvement to an existing feature
title: "[Enhancement]"
labels: type/enhancement
assignees: ''
---
**Which existing feature or component would you like to improve?**
<!--
Name the feature, component, or API (e.g. "Application rollout", "vela CLI output", "CUE template rendering").
-->
**What is the current limitation or pain point?**
<!--
A clear and concise description of what is missing or frustrating today.
-->
**Describe the improvement you'd like**
<!--
A clear and concise description of what you want to happen instead.
-->
**Additional context**
<!--
Add any other context or screenshots about the enhancement request here.
-->
.github/ISSUE_TEMPLATE/enhancement_request.yml
+45
View File
@@ -0,0 +1,45 @@
name: "✨ Enhancement request"
description: Suggest an improvement to an existing feature or component
title: ""
labels: ["type/enhancement"]
body:
- type: checkboxes
id: existing-search
attributes:
label: Is there an existing issue for this?
description: Please search to see if an issue already exists for the enhancement you're requesting.
options:
- label: I have searched the existing issues
required: true
- type: input
id: affected
attributes:
label: Affected feature or component
description: Name the feature, component, or API this enhancement targets.
placeholder: e.g. Application rollout, vela CLI output, CUE template rendering
validations:
required: true
- type: textarea
id: problem
attributes:
label: What is the current limitation or pain point?
description: A clear and concise description of what is missing or frustrating today.
validations:
required: true
- type: textarea
id: solution
attributes:
label: Describe the improvement you'd like
description: A clear and concise description of what you want to happen instead.
validations:
required: true
- type: textarea
id: alternatives
attributes:
label: Alternatives considered
description: A clear and concise description of any alternative solutions you've considered.
- type: textarea
id: additional
attributes:
label: Additional context
description: Add any other context or screenshots here.
.github/ISSUE_TEMPLATE/feature_request.md
-28
View File
@@ -1,28 +0,0 @@
---
name: "\U0001F680 Feature request"
about: Suggest an idea for this project
title: "[Feature]"
labels: type/feature
assignees: ''
---
**Is your feature request related to a problem? Please describe.**
<!--
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
-->
**Describe the solution you'd like**
<!--
A clear and concise description of what you want to happen.
-->
**Describe alternatives you've considered**
<!--
A clear and concise description of any alternative solutions or features you've considered.
-->
**Additional context**
<!--
Add any other context or screenshots about the feature request here.
-->
.github/ISSUE_TEMPLATE/feature_request.yml
+37
View File
@@ -0,0 +1,37 @@
name: "🚀 Feature request"
description: Suggest a brand new capability that doesn't exist yet
title: ""
labels: ["type/feature"]
body:
- type: checkboxes
id: existing-search
attributes:
label: Is there an existing issue for this?
description: Please search to see if an issue already exists for the feature you're requesting.
options:
- label: I have searched the existing issues
required: true
- type: textarea
id: problem
attributes:
label: What problem or limitation does this address?
description: "A clear and concise description of the problem. Ex. I'm always frustrated when [...]"
validations:
required: true
- type: textarea
id: solution
attributes:
label: Describe the solution you'd like
description: A clear and concise description of what you want to happen.
validations:
required: true
- type: textarea
id: alternatives
attributes:
label: Alternatives considered
description: A clear and concise description of any alternative solutions or features you've considered.
- type: textarea
id: additional
attributes:
label: Additional context
description: Add any other context or screenshots here.
.github/PULL_REQUEST_TEMPLATE.md
+2 -1
View File
@@ -15,7 +15,8 @@ Fixes #
I have:
- [ ] Read and followed KubeVela's [contribution process](https://github.com/kubevela/kubevela/blob/master/contribute/create-pull-request.md).
- [ ] Read and followed KubeVela's [pull request process](https://kubevela.io/docs/contributor/code-contribute#create-a-pull-request).
- [ ] All commits are signed off (DCO).
- [ ] [Related Docs](https://github.com/kubevela/kubevela.io) updated properly. In a new feature or configuration option, an update to the documentation is necessary.
- [ ] Run `make reviewable` to ensure this PR is ready for review.
- [ ] Added `backport release-x.y` labels to auto-backport this PR if necessary.
.github/bot.md
+1 -1
View File
@@ -14,7 +14,7 @@ Comment commands:
* Write the word `/area/*` in a comment, and the bot will add the corresponding label `/area/*`.
* Write the word `/priority/*` in a comment, and the bot will add the corresponding label `/priority/*`.
The `*` mention above represent a specific word. Please read the details about label category in [ISSUE_TRIAGE.md](https://github.com/kubevela/kubevela/blob/master/ISSUE_TRIAGE.md)
The `*` mention above represent a specific word. Please read the details about label category in [ISSUE_TRIAGE.md](https://github.com/kubevela/community/blob/main/ISSUE_TRIAGE.md)
Label commands:
.github/comment.userlist
+2 -1
View File
@@ -14,4 +14,5 @@ leejanee
barnettZQG
anoop2811
briankane
jguionnet
jguionnet
roguepikachu
.github/issue-commands.json
+2 -2
View File
@@ -136,13 +136,13 @@
"addLabel": "type/duplicate",
"removeLabel": "bot/duplicate",
"action": "close",
"comment": "Thanks for creating this issue! It looks like this has already been reported by another user. We’ve closed this in favor of the existing one. Please consider adding any details you think is missing to that issue.\n\nTo avoid having your issue closed in the future, please read our [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) guidelines.\n\nHappy graphing!"
"comment": "Thanks for creating this issue! It looks like this has already been reported by another user. We’ve closed this in favor of the existing one. Please consider adding any details you think is missing to that issue.\n\nTo avoid having your issue closed in the future, please read our [CONTRIBUTING](https://github.com/kubevela/kubevela/blob/master/CONTRIBUTING.md) guidelines."
},
{
"type": "label",
"name": "bot/no new info",
"action": "close",
"comment": "We've closed this issue since it needs more information and hasn't had any activity recently. We can re-open it after you you add more information. To avoid having your issue closed in the future, please read our [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) guidelines.\n\nHappy graphing!"
"comment": "We've closed this issue since it needs more information and hasn't had any activity recently. We can re-open it after you add more information. To avoid having your issue closed in the future, please read our [CONTRIBUTING](https://github.com/kubevela/kubevela/blob/master/CONTRIBUTING.md) guidelines."
},
{
"type": "label",
COMMUNITY.md
+38
View File
@@ -0,0 +1,38 @@
# Community
KubeVela is built and maintained by an open community, with bootstrap
contributors from more than 8 organizations. This is a short map. The full
detail lives in the [kubevela/community](https://github.com/kubevela/community)
repo.
## Communication
- Slack: [#kubevela](https://cloud-native.slack.com/archives/C01BLQ3HTJA) on
the CNCF Slack (English)
- DingTalk and WeChat groups for Chinese-speaking contributors
- Weekly community meetings, alternating between English and Chinese
See [community communication](https://github.com/kubevela/community#communication)
for joining links, group IDs, and the current meeting schedule. Those change
often enough that duplicating them here would just go stale.
## How can I get involved?
Pick up a [good first issue](https://github.com/kubevela/kubevela/labels/good%20first%20issue)
or a [help wanted](https://github.com/kubevela/kubevela/labels/help%20wanted)
issue, answer questions in
[GitHub Discussions](https://github.com/kubevela/kubevela/discussions), help
with [issue triage](https://github.com/kubevela/community/blob/main/ISSUE_TRIAGE.md),
write docs, or just join a community meeting. See
[CONTRIBUTING.md](./CONTRIBUTING.md) for the full path from first issue to
first pull request.
## Governance and membership
See [GOVERNANCE.md](./GOVERNANCE.md) for how decisions get made, and
[community membership](https://github.com/kubevela/community/blob/main/community-membership.md)
for the Reviewer, Approver, and Maintainer ladder.
## Code of Conduct
KubeVela follows the CNCF Code of Conduct. See [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md).
CONTRIBUTING.md
+77 -2
View File
@@ -1,3 +1,78 @@
# CONTRIBUTING Guide
# Contributing to KubeVela
Please refer to https://kubevela.io/docs/contributor/overview for details.
Thanks for your interest in KubeVela. Contributions of every kind are welcome, whether
you are fixing a typo, triaging an issue, improving the docs, or shipping a new feature.
This page is a map: it covers what you need before your first pull request and links out
to the full guide for everything else.
## Code of Conduct
KubeVela follows the CNCF Code of Conduct. By participating, you agree to uphold it.
See [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md).
## Ways to contribute
- **Code**
- Pick up a [good first issue](https://github.com/kubevela/kubevela/labels/good%20first%20issue).
- Follow the [code conventions](https://kubevela.io/docs/contributor/code-conventions) and [test principles](https://kubevela.io/docs/contributor/principle-of-test).
- See the [code contribution guide](https://kubevela.io/docs/contributor/code-contribute) for local setup and the pull request process.
- **Docs**
- The docs live in [kubevela/kubevela.io](https://github.com/kubevela/kubevela.io).
- See its [developer guide](https://github.com/kubevela/kubevela.io/blob/main/README.md) for how to write and preview them.
- **Issue triage**
- Help reproduce, label, and narrow down reported bugs.
- See [ISSUE_TRIAGE.md](https://github.com/kubevela/community/blob/main/ISSUE_TRIAGE.md).
- **Answer questions**: help other users in [GitHub Discussions](https://github.com/kubevela/kubevela/discussions) and on Slack.
- **Everything else**
- Blog posts, talks, case studies, and translations all count.
- See the [non-code contribution guide](https://kubevela.io/docs/contributor/non-code-contribute).
## Quick start
Build the CLI, run the unit tests, and lint before opening a pull request:
```bash
make # build the vela CLI to bin/vela
make test # run unit tests
make reviewable # lint, generate, and get the PR ready for review
```
These assume the prerequisites (Go, kustomize, CUE, and friends) are already
installed. See the [code contribution guide](https://kubevela.io/docs/contributor/code-contribute)
for installing those, running `vela-core` and VelaUX locally, and end-to-end tests.
## Commit messages
Commits follow `<Type>[optional scope]: <subject>`, with the type capitalized:
```
Fix: correct minor typos in code
Feat(cli): add polish language
Docs: changed url to URL in all documentation files
```
`<Type>` is one of Feat, Fix, Docs, Build, Style, Refactor, Perf, Test, or
Chore. Pull requests are squash-merged, so the PR title becomes the commit
message, use the same format there too. See
[Formatting guidelines](https://kubevela.io/docs/contributor/code-contribute#formatting-guidelines)
for the full convention, including scopes and areas.
## Sign your commits (DCO)
Every commit must carry a `Signed-off-by` line certifying you wrote the code and can
contribute it under the project license. Add it with `-s`:
```bash
git commit -s -m "your commit message"
```
Without it, your pull request may not be able to merge. For the full explanation and
how to fix commits you already pushed, see
[Sign Your Commits (DCO)](https://kubevela.io/docs/contributor/code-contribute#sign-your-commits-dco).
## More
- **Full Contributor Guide**: [kubevela.io/docs/contributor/overview](https://kubevela.io/docs/contributor/overview), covering development setup, testing, and the pull request process.
- **Governance**: [GOVERNANCE.md](./GOVERNANCE.md) explains roles, responsibilities, and how decisions get made.
- **Security**: do not open a public issue for a vulnerability. Follow [SECURITY.md](./SECURITY.md).
- **Communication**: Slack, community meetings, and how to get involved are covered in [COMMUNITY.md](./COMMUNITY.md).
GOVERNANCE.md
+49 -1
View File
@@ -1 +1,49 @@
Refer to https://github.com/kubevela/community/blob/main/GOVERNANCE.md
# Governance
This is a short map. The full governance document, including how decisions get
made and how it can itself be amended, lives in
[kubevela/community/GOVERNANCE.md](https://github.com/kubevela/community/blob/main/GOVERNANCE.md).
## Code of Conduct
KubeVela follows the CNCF Code of Conduct. See [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md).
## Meetings
Weekly community meetings are open to the public and are the primary place to
discuss pull requests before they merge. See
[community meetings](https://github.com/kubevela/community#community-meetings)
for the schedule and joining links.
## KubeVela Enhancement Proposals
Changes that introduce new behavior or modify existing requirements go through
a KubeVela Enhancement Proposal, tracked under
[design/](https://github.com/kubevela/kubevela/tree/master/design). Simple
additions and bug fixes can go straight to a pull request, see
[CONTRIBUTING.md](./CONTRIBUTING.md).
## Membership
KubeVela has three levels of membership beyond contributor: Reviewer,
Approver, and Maintainer, each with more responsibility than the last. See
[community membership](https://github.com/kubevela/community/blob/main/community-membership.md)
for what each level requires, and
[OWNERS.md](https://github.com/kubevela/community/blob/main/OWNERS.md) for who
currently holds which role.
Maintainers who are unresponsive for more than six months are removed unless
the other maintainers agree by supermajority to extend that period. New
maintainers are added the same way, by a supermajority vote.
## Security
Security vulnerabilities are handled privately per [SECURITY.md](./SECURITY.md),
never as a public issue.
## Releases
KubeVela aims for a major or minor release at least once every two months,
with patch releases as needed. Only maintainers can cut a release. See
[Release Process And Cadence](https://kubevela.io/docs/contributor/release-process)
for the full cadence and branch cut process.
ISSUE_TRIAGE.md
+16 -323
View File
@@ -1,323 +1,16 @@
# Triage issues
The main goal of issue triage is to categorize all incoming KubeVela issues and make sure each issue has all basic
information needed for anyone else to understand and be able to start working on it.
> **Note:** This information is for OAM/KubeVela project Maintainers, Owners, and Admins.
> If you are a Contributor, then you will not be able to perform most of the tasks in this topic.
The core maintainers of the OAM/KubeVela project are responsible for categorizing all incoming issues and delegating
any critical or important issue to other maintainers. Currently one maintainer each week is responsible.
Besides that part, triage provides an important way to contribute to an open source project.
Triage helps ensure issues resolve quickly by:
- Ensuring the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for
an issue to explain how an end user experiences a problem and what actions they took.
- Giving a contributor the information they need before they commit to resolving an issue.
- Lowering the issue count by preventing duplicate issues.
- Streamlining the development process by preventing duplicate discussions.
If you don't have the knowledge or time to code, consider helping with triage.
The community will thank you for saving them time by spending some of yours.
## Simplified flowchart diagram of the issue triage process
<!-- https://textik.com/#908a27a44c590528 -->
```
+-----------------------------+
| |
| New Issues Opened |
+-----------------+ |
| | Or More information needed |
| | |
| +--------------+--------------+
| Ask for more info |
| |
| +--------------+------------+
| | | Yes
| | All informatio needed |
| +-----------+ to categorize the issue？ +---------------+
| | No | | |
| | +---------------------------+ |
| | +-----------+-----------+ +---------------------------+
+------------+-----+-----+ | | Yes | |
| | | Needs investigation ？ +---------+ label: needs investigation|
| label: needs more info | | | | |
| | +----------+------------+ +-------------+-------------+
+------------------------+ | |
| No |
| |
+----------+----------+ investigate |
| label: type/* | |
| label: area/* +--------------------------+
| |
+--|-------------|----+
| | Yes
| +-------|-------------+ +-------------------+
| | needs priority？ +----+ label: priority/* |
| +-------|-------------+ +----------|--------+
| | No |
| | |
+----- ------|---+ +--|----- --+ |
| close issue + ---- + done +---------------------+
+----------------+ +-----------+
```
## 1. Find uncategorized issues
To get started with issue triage and finding issues that haven't been triaged you have two alternatives.
### Browse unlabeled issues
The easiest and straight forward way of getting started and finding issues that haven't been triaged is to browse
[unlabeled issues](https://github.com/kubevela/kubevela/issues?q=is%3Aopen+is%3Aissue+no%3Alabel) and starting from
the bottom and working yourself to the top.
### Subscribe to all notifications
The more advanced, but recommended way is to subscribe to all notifications from this repository which means that
all new issues, pull requests, comments and important status changes are sent to your configured email address.
Read this [guide](https://help.github.com/en/articles/watching-and-unwatching-repositories#watching-a-single-repository)
for help with setting this up.
It's highly recommended that you setup filters to automatically remove emails from the inbox and label/categorize
them accordingly to make it easy for you to understand when you need to act upon a notification or where to look for
finding issues that haven't been triaged etc.
## 2. Ensure the issue contains basic information
Before triaging an issue very far, make sure that the issue's author provided the standard issue information.
This will help you make an educated recommendation on how to categorize the issue.
The KubeVela project utilizes [GitHub issue templates](https://help.github.com/en/articles/creating-issue-templates-for-your-repository)
to guide contributors to provide standard information that must be included for each type of template or type of issue.
### Standard issue information that must be included
Given a certain [issue template]([template](https://github.com/kubevela/kubevela/issues/new/choose)) have been used
by the issue author or depending how the issue is perceived by the issue triage responsible, the following should
help you understand what standard issue information that must be included.
#### Bug reports
Should explain what happened, what was expected and how to reproduce it together with any additional information that
may help giving a complete picture of what happened such as screenshots, application related YAMLs, and any environment
related information that's applicable and/or maybe related to the reported problem:
- KubeVela version
- K8s cluster version KubeVela is installed on
- Which other K8s CRD controllers used
- Development environment like Go versions, if applicable
#### Enhancement requests
Should explain what enhancement or feature that the author wants to be added and why that is needed.
### Good practices
To make it easier for everyone to understand and find issues they're searching for it's suggested as a general rule of thumbs to:
- Make sure that issue titles are named to explain the subject of the issue, has a correct spelling and doesn't include irrelevant information and/or sensitive information.
- Make sure that issue descriptions doesn't include irrelevant information, information from template that haven't been filled out and/or sensitive information.
- Do your best effort to change title and description or request suggested changes by adding a comment.
> **Note:** Above rules is applicable to both new and existing issues of the KubeVela project.
### Do you have all the information needed to categorize an issue?
Depending on the issue, you might not feel all this information is needed. Use your best judgement.
If you cannot triage an issue using what its author provided, explain kindly to the author that they must provide the
above information to clarify the problem. Label issue with `needs more info` and add any related `area/*` or `type/*` labels.
If the author provides the standard information but you are still unable to triage the issue, request additional information.
Do this kindly and politely because you are asking for more of the author's time.
If the author does not respond to the requested information within the timespan of a week,
close the issue with a kind note stating that the author can request for the issue to be reopened when the necessary information is provided.
When you feel you have all the information needed you're ready to [categorizing the issue](#3-categorizing-an-issue).
If you receive a notification with additional information provided but you are not anymore on issue triage and
you feel you do not have time to handle it, you should delegate it to the current person on issue triage.
## 3. Categorizing an issue
An issue can have multiple of the following labels. Typically, a properly categorized issue should at least have:
- One label identifying its type (`type/*`).
- One or multiple labels identifying the functional areas of interest or component (`area/*`), if applicable.
| Label | Description |
| ------------------------ | ------------------------------------------------------------------------- |
| `type/bug` | A feature isn't working as expected given design or documentation. |
| `type/enhancement` | Request for a new feature or enhancement. |
| `type/docs` | Documentation problem or enhancement. |
| `type/question` | Issue is a question or is perceived as such. |
| `type/duplicate` | An existing issue of the same subject/request have already been reported. |
| `type/wontfix` | A reported bug works as intended/by design. |
| `type/invalid` | A reported bug with invalid usage. |
| `area/*` | Subject is related to a functional area of interest or component. |
### Duplicate issues
Make sure it's not a duplicate by searching existing issues using related terms from the issue title and description.
If you think you know there is an existing issue, but can't find it, please reach out to one of the maintainers and ask for help.
If you identify that the issue is a duplicate of an existing issue:
1. Add a comment `/duplicate of #<issue number>`. GitHub will recognize this and add some additional context to the issue activity.
2. The KubeVela bot will do the rest, adding the correct label and closing comment
3. Optionally add any related `area/*` labels.
### Bug reports
If it's not perfectly clear that it's an actual bug, quickly try to reproduce it.
**It's a bug/it can be reproduced:**
1. Add a comment describing detailed steps for how to reproduce it, if applicable.
2. Label the issue `type/bug` and at least one `area/*` label.
3. If you know that maintainers won't be able to put any resources into it for some time then label the issue
with `help wanted` and optionally `good first issue` together with pointers on which code to update to fix the bug.
This should signal to the community that we would appreciate any help we can get to resolve this.
4. Move on to [prioritizing the issue](#4-prioritization-of-issues).
**It can't be reproduced:**
1. Either [ask for more information](#2-ensure-the-issue-contains-basic-information) needed to investigate it more thoroughly.
2. Either [delegate further investigations](#investigation-of-issues) to someone else.
**It works as intended/by design:**
1. Kindly and politely add a comment explaining briefly why we think it works as intended and close the issue.
2. Label the issue `type/wontfix`.
### Enhancement/feature?
1. Label the issue `type/enhancement` and at least one `area/*` label.
2. Move on to [prioritizing the issue](#4-prioritization-of-issues).
### Documentation issue?
First, evaluate if the documentation makes sense to be included in the KubeVela project:
- Is this something we want/can maintain as a project?
- Is this referring to usage of some specific integration/tool and in that case is that a popular use case in combination with KubeVela?
- If unsure, kindly and politely add a comment explaining that we would need [upvotes](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments)
to identify that lots of other users want/need this.
Second, label the issue `type/docs` and at least one `area/*` label.
**Minor typo/error/lack of information:**
There's a minor typo/error/lack of information that adds a lot of confusion for users and given the amount of work is a big win to make sure fixing it:
1. Either update the documentation yourself and open a pull request.
2. Either delegate the work to someone else by assigning that person to the issue and add the issue to next major/minor milestone.
**Major error/lack of information:**
1. Label the issue with `help wanted` and `good first issue`, if applicable, to signal that we find this important to
fix and we would appreciate any help we can get from the community.
2. Move on to [prioritizing the issue](#4-prioritization-of-issues).
### Support requests and questions
1. Kindly and politely direct the issue author to the [github discussion](https://github.com/kubevela/kubevela/discussions)
and explain that issue is mainly used for tracking bugs and feature requests.
If possible, it's usually a good idea to add some pointers to the issue author's question.
2. Close the issue and label it with `type/question`.
## 4. Prioritization of issues
In general bugs and enhancement issues should be labeled with a priority.
This is the most difficult thing with triaging issues since it requires a lot of knowledge, context and experience
before being able to think of and start feel comfortable adding a certain priority label.
The key here is asking for help and discuss issues to understand how more experienced project members think and reason.
By doing that you learn more and eventually be more and more comfortable with prioritizing issues.
In case there is an uncertainty around the prioritization of an issue, please ask the maintainers for help.
| Label | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `priority/critical` | Highest priority. Must be actively worked on as someone's top priority right now. |
| `priority/important-soon` | Must be staffed and worked on either currently, or very soon, ideally in time for the next release. |
| `priority/important-longterm` | Important over the long term, but may not be staffed and/or may need multiple releases to complete. |
| `priority/nice-to-have` | It's a good idea, but not scheduled for any release. |
| `priority/awaiting-more-evidence` | Lowest priority. Possibly useful, but not yet enough interest in it. |
| `priority/unscheduled` | Something to look into before and to be discussed during the planning of the next (upcoming) major/minor stable release. |
**Critical bugs**
1. If a bug has been categorized and any of the following criteria apply, the bug should be labeled as critical and
must be actively worked on as someone's top priority right now.
- Results in any crash or data loss.
- Critical security or performance issues
- Problem that makes a feature unusable
- Multiple users experience a severe problem affecting their business, users etc.
2. Label the issue `priority/critical`.
3. Add the issue to the next upcoming patch release milestone. Create a new milestone if there are none.
4. Escalate the problem to the maintainers.
5. Assign or ask a maintainer for help assigning someone to make this issue their top priority right now.
**Important short-term**
1. Label the issue `priority/important-soon`.
2. Add the issue to the next upcoming patch or major/minor stable release milestone. Ask maintainers for help if unsure if it's a patch or not.
Create a new milestone if there are none.
3. Make sure to add the issue to a suitable backlog of a GitHub project and prioritize it or assign someone to work on it now or very soon.
4. Consider requesting [help from the community](#5-requesting-help-from-the-community), even though it may be problematic given a short amount of time until it should be released.
**Important long-term**
1. Label the issue `priority/important-longterm`.
2. Consider requesting [help from the community](#5-requesting-help-from-the-community).
**Nice to have**
1. Label the issue `priority/nice-to-have`.
2. Consider requesting [help from the community](#5-requesting-help-from-the-community).
**Not critical, but unsure?**
1. Label the issue `priority/unscheduled`.
2. Consider requesting [help from the community](#5-requesting-help-from-the-community).
## 5. Requesting help from the community
Depending on the issue and/or priority, it's always a good idea to consider signalling to the community that help from community
is appreciated and needed in case an issue is not prioritized to be worked on by maintainers. Use your best judgement.
In general, requesting help from the community means that a contribution has a good chance of getting accepted and merged.
1. Kindly and politely add a comment to signal to users subscribed to updates of the issue.
- Explain that the issue would be nice to get resolved, but it isn't prioritized to work on by maintainers for an unforeseen future.
- If possible or applicable, try to help contributors getting starting by adding pointers and references to
what code/files need to be changed and/or ideas of a good way to solve/implement the issue.
2. Label the issue with `help wanted`.
3. If applicable, label the issue with `good first issue` to denote that the issue is suitable for a beginner to work on.
4. If possible, try to estimate the amount of work by adding `effort/small`, `effort/medium` or `effort/large`.
## Investigation of issues
When an issue has all basic information provided, but the triage responsible haven't been able to reproduce the reported
problem at a first glance, the issue is labeled [Needs investigation](https://github.com/oam-dev/kubevela/labels/needs%20investigation).
Depending on the perceived severity and/or number of [upvotes](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments),
the investigation will either be delegated to another maintainer for further investigation or put on hold until someone else (maintainer or contributor)
picks it up and eventually starts investigating it.
Investigating issues can be a very time consuming task, especially for the maintainers, provide as much related info will
make it easier for maintainers to investigate.
Even if you don't have the time or knowledge to investigate an issue we highly recommend that you [upvote](https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments)
the issue if you happen to have the same problem. If you have further details that may help investigating the issue
please provide as much information as possible.
## Automation
We have some automation that triggers on comments or labels being added to issues.
Many of these automated behaviors are defined in [issue-commands.json](https://github.com/oam-dev/kubevela/blob/master/.github/issue-commands.json).
* Add comment `/duplicate #<number>` to have `type/duplicate` label, the issue number is required for remind where is the other issue.
* Add label `bot/no new info` for bot to close an issue where we asked for more info but has not received any updates in at least 14 days.
Read more bot actions on [bot.md](https://github.com/oam-dev/kubevela/blob/master/.github/bot.md)
# Issue Triage
The full issue triage process, for KubeVela project Maintainers, Owners, and
Admins, lives at
[kubevela/community/ISSUE_TRIAGE.md](https://github.com/kubevela/community/blob/main/ISSUE_TRIAGE.md).
This file used to carry a full copy of that document. Two versions of the
same process drift apart over time, in this case it went stale enough to
still reference the project's old `oam-dev/kubevela` org name after the move
to `kubevela/kubevela`, so it now just points at the one canonical copy
instead.
If you're looking to help with triage rather than run it, see
[COMMUNITY.md](./COMMUNITY.md) for how to get involved, and the canonical
[ISSUE_TRIAGE.md](https://github.com/kubevela/community/blob/main/ISSUE_TRIAGE.md)
linked above for how the `type/*`, `area/*`, and `priority/*` labels work.
README.md
+7 -27
View File
@@ -37,9 +37,9 @@ No ad-hoc scripts, no dirty glue code, just deploy. The deployment workflow in K
#### **Built-in observability, multi-tenancy and security support**
Choose from the wide range of LDAP integrations we provided out-of-box, enjoy enhanced [multi-tenancy and multi-cluster authorization and authentication](https://kubevela.net/docs/platform-engineers/auth/advance),
Choose from the wide range of LDAP integrations we provided out-of-box, enjoy enhanced [multi-tenancy and multi-cluster authorization and authentication](https://kubevela.io/docs/platform-engineers/auth/advance),
pick and apply fine-grained RBAC modules and customize them as per your own supply chain requirements.
All delivery process has fully [automated observability dashboards](https://kubevela.net/docs/platform-engineers/operations/observability).
All delivery process has fully [automated observability dashboards](https://kubevela.io/docs/platform-engineers/operations/observability).
#### **Multi-cloud/hybrid-environments app delivery as first-class citizen**
@@ -51,7 +51,7 @@ along with automated cloud environments provision.
Minimize your control plane deployment with only one pod and 0.5c1g resources to handle thousands of application delivery.
Glue and orchestrate all your infrastructure capabilities as reusable modules with a highly extensible architecture
and share the large growing community [addons](https://kubevela.net/docs/reference/addons/overview).
and share the large growing community [addons](https://kubevela.io/docs/reference/addons/overview).
## Getting Started
@@ -78,28 +78,8 @@ Official blog is available on [KubeVela blog](https://kubevela.io/blog).
## Community
We want your contributions and suggestions!
One of the easiest ways to contribute is to participate in discussions on the Github Issues/Discussion, chat on IM or the bi-weekly community calls.
For more information on the community engagement, developer and contributing guidelines and more, head over to the [KubeVela community repo](https://github.com/kubevela/community).
### Contact Us
Reach out with any questions you may have and we'll make sure to answer them as soon as possible!
- Slack: [CNCF Slack kubevela channel](https://cloud-native.slack.com/archives/C01BLQ3HTJA) (*English*)
- [DingTalk Group](https://page.dingtalk.com/wow/dingtalk/act/en-home): `23310022` (*Chinese*)
- Wechat Group (*Chinese*): Broker wechat to add you into the user group.
<img src="https://static.kubevela.net/images/barnett-wechat.jpg" width="200" />
### Community Call
Every two weeks we host a community call to showcase new features, review upcoming milestones, and engage in a Q&A. All are welcome!
- Bi-weekly Community Call:
- [Meeting Notes](https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs).
- [Video Records](https://www.youtube.com/channel/UCSCTHhGI5XJ0SEhDHVakPAA/videos).
- Bi-weekly Chinese Community Call:
- [Video Records](https://space.bilibili.com/180074935/channel/seriesdetail?sid=1842207).
One of the easiest ways to contribute is to participate in discussions on the Github Issues/Discussion, chat on IM or the community calls.
See [COMMUNITY.md](./COMMUNITY.md) for Slack, DingTalk, WeChat, and meeting info, and the [KubeVela community repo](https://github.com/kubevela/community) for joining links, the current meeting schedule, and developer and contributing guidelines.
## Talks and Conferences
@@ -107,11 +87,11 @@ Check out [KubeVela videos](https://kubevela.io/videos/talks/en/oam-dapr) for th
## Contributing
Check out [CONTRIBUTING](https://kubevela.io/docs/contributor/overview) to see how to develop with KubeVela
Check out [CONTRIBUTING.md](./CONTRIBUTING.md) to see how to develop with KubeVela.
## Report Vulnerability
Security is a first priority thing for us at KubeVela. If you come across a related issue, please send email to security@mail.kubevela.io .
Security is a first priority thing for us at KubeVela. See [SECURITY.md](./SECURITY.md) to report an issue privately, or send email directly to security@mail.kubevela.io.
## Code of Conduct
community.md
-3
View File
@@ -1,3 +0,0 @@
# Community
Please refer to the [community repo](https://github.com/kubevela/community) for details.
contribute/README.md
-3
View File
@@ -1,3 +0,0 @@
# Contribute
Please refer to https://kubevela.io/docs/contributor/overview for details.
contribute/coding-conventions.md
-3
View File
@@ -1,3 +0,0 @@
# KubeVela code conventions
Please refer to https://kubevela.io/docs/contributor/code-conventions for details.
contribute/create-pull-request.md
-3
View File
@@ -1,3 +0,0 @@
# Create a pull request
Please refer to https://kubevela.io/docs/contributor/code-contribute#create-a-pull-request for details.
contribute/develop-code-flow.pdf
BIN
View File
Binary file not shown.
contribute/developer-guide.md
-3
View File
@@ -1,3 +0,0 @@
# Developer guide
Please refer to https://kubevela.io/docs/contributor/code-contribute for details.
contribute/testcode-guidance.md
-4
View File
@@ -1,4 +0,0 @@
# Principle of Test
Please refer to https://kubevela.io/docs/contributor/principle-of-test for details.
contribute/triage-issues.md
-3
View File
@@ -1,3 +0,0 @@
# Triage issues
Please refer to https://github.com/kubevela/community/blob/main/ISSUE_TRIAGE.md for details.