diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 45b023453..ae9141ca3 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,76 +1,3 @@ -# Contributor Covenant Code of Conduct +# Dragonfly Community Code of Conduct -## Our Pledge - -In the interest of fostering an open and welcoming environment, -we as contributors and maintainers pledge to -make participation in our project and -our community a harassment-free experience for everyone, -regardless of age, body size, -disability, ethnicity, gender identity and expression, -level of experience, nationality, -personal appearance, race, religion, -or sexual identity and orientation. - -## Our Standards - -Examples of behavior that contributes to creating a positive environment include: - -- Using welcoming and inclusive language -- Being respectful of differing viewpoints and experiences -- Gracefully accepting constructive criticism -- Focusing on what is best for the community -- Showing empathy towards other community members - -Examples of unacceptable behavior by participants include: - -- The use of sexualized language or imagery and unwelcome sexual attention or advances -- Trolling, insulting/derogatory comments, and personal or political attacks -- Public or private harassment -- Publishing others' private information, - such as a physical or electronic address, without explicit permission -- Other conduct which could reasonably be considered inappropriate in - a professional setting - -## Our Responsibilities - -Project maintainers are responsible for clarifying the standards of -acceptable behavior and are expected to take appropriate and -fair corrective action in response to any instances of unacceptable behavior. - -Project maintainers have the right and responsibility to remove, -edit, or reject comments, commits, code, wiki edits, issues, -and other contributions that are not aligned to this Code of Conduct, -or to ban temporarily or permanently any contributor for -other behaviors that they deem inappropriate, threatening, offensive, or harmful. - -## Scope - -This Code of Conduct applies both within project spaces and in public -spaces when an individual is representing the project or its community. -Examples of representing a project or community include using an official -project e-mail address, posting via an official social media account, -or acting as an appointed representative at an online or offline event. -Representation of a project may be further defined and clarified by project maintainers. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable -behavior may be reported by contacting the project team at -. The project team will review -and investigate all complaints, and will respond in a way -that it deems appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. - -Project maintainers who do not follow or enforce the Code of -Conduct in good faith may face temporary or permanent repercussions as -determined by other members of the project's leadership. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 1.4, available at [https://www.contributor-covenant.org/version/2/0/][version] - -[homepage]: https://contributor-covenant.org -[version]: https://www.contributor-covenant.org/version/2/0/ +Please refer to the [community code of conduct](https://github.com/dragonflyoss/community/blob/master/CODE_OF_CONDUCT.md). diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 325405d67..85ee6e4eb 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,324 +1,3 @@ # Contributing to Dragonfly -It is warmly welcomed if you have the interest to hack on Dragonfly. -First, we encourage this kind of willingness very much. -And here is a list of contributing guide for you. - -## Topics - -- [Reporting security issues](#reporting-security-issues) -- [Reporting general issues](#reporting-general-issues) -- [Code and doc contribution](#code-and-doc-contribution) -- [Engage to help anything](#engage-to-help-anything) -- [Join Dragonfly as a member](#join-dragonfly-as-a-member) - -## Reporting security issues - -Security issues are always treated seriously. -As our usual principle, we discourage anyone to spread security issues. -If you find a security issue of Dragonfly, please do not discuss it in -public and even do not open a public issue. -Instead, we encourage you to send us a private email to -[dragonfly-developers@googlegroups.com](mailto:dragonfly-developers@googlegroups.com) to report this. - -## Reporting general issues - -To be honest, we regard every user of Dragonfly as a very kind contributor. -After experiencing Dragonfly, you may have some feedback for the project. -Then feel free to open an issue via -[NEW ISSUE](https://github.com/dragonflyoss/dragonfly/issues/new). - -Since we collaborate project Dragonfly in a distributed way, -we appreciate **WELL-WRITTEN**, **DETAILED**, **EXPLICIT** issue reports. -To make the communication more efficient, we wish everyone could -search if your issue is an existing one in the searching list. -If you find it existing, please add your details in comments -under the existing issue instead of opening a brand new one. - -To make the issue details as standard as possible, -we setup an [ISSUE TEMPLATE](./.github/ISSUE_TEMPLATE) for issue reporters. -You can find three kinds of issue templates there: question, -bug report and feature request. Please **BE SURE** to follow -the instructions to fill fields in template. - -There are a lot of cases when you could open an issue: - -- bug report -- feature request -- performance issues -- feature proposal -- feature design -- help wanted -- doc incomplete -- test improvement -- any questions on project -- and so on - -Also, we must remind that when filing a new issue, -please remember to remove the sensitive data from your post. -Sensitive data could be password, secret key, -network locations, private business data and so on. - -## Code and doc contribution - -Every action to make project Dragonfly better is encouraged. -On GitHub, every improvement for Dragonfly could be -via a PR (short for pull request). - -- If you find a typo, try to fix it! -- If you find a bug, try to fix it! -- If you find some redundant codes, try to remove them! -- If you find some test cases missing, try to add them! -- If you could enhance a feature, please **DO NOT** hesitate! -- If you find code implicit, try to add comments to make it clear! -- If you find code ugly, try to refactor that! -- If you can help to improve documents, it could not be better! -- If you find document incorrect, just do it and fix that! -- ... - -Actually, it is impossible to list them completely. -Just remember one principle: - -> WE ARE LOOKING FORWARD TO ANY PR FROM YOU. - -Since you are ready to improve Dragonfly with a PR, -we suggest you could take a look at the PR rules here. - -- [Workspace Preparation](#workspace-preparation) -- [Branch Definition](#branch-definition) -- [Commit Rules](#commit-rules) -- [PR Description](#pr-description) -- [Developing Environment](#developing-environment) -- [Golang Dependency Management](#golang-dependency-management) - -### Workspace Preparation - -To put forward a PR, we assume you have registered -a GitHub ID. Then you could finish -the preparation in the following steps: - -1. **FORK** Dragonfly to your repository. - -To make this work, you just need to click the button Fork -in right-left of [dragonflyoss/dragonfly](https://github.com/dragonflyoss/dragonfly) -main page. Then you will end up with your repository in -`https://github.com//Dragonfly`, -in which `your-username` is your GitHub username. - -1. **CLONE** your own repository to develop locally. - -Use `git clone https://github.com//dragonfly.git` -to clone repository to your local machine. -Then you can create new branches to finish the change you wish to make. - -1. **Set Remote** upstream to be - `https://github.com/dragonflyoss/dragonfly.git` - -using the following two commands: - -```bash -git remote add upstream https://github.com/dragonflyoss/dragonfly.git -git remote set-url --push upstream no-pushing -``` - -With this remote setting, you can check your git remote configuration like this: - -```bash -$ git remote -v -origin https://github.com//dragonfly.git (fetch) -origin https://github.com//dragonfly.git (push) -upstream https://github.com/dragonflyoss/dragonfly.git (fetch) -upstream no-pushing (push) -``` - -Adding this, we can easily synchronize local branches with upstream branches. - -1. **Create a branch** to add a new feature or fix issues - -Update local working directory: - -```bash -cd dragonfly -git fetch upstream -git checkout main -git rebase upstream/main -``` - -Create a new branch: - -```bash -git checkout -b -``` - -Make any change on the `new-branch` then build and test your codes. - -### Branch Definition - -Right now we assume every contribution via pull -request is for [branch main](https://github.com/dragonflyoss/dragonfly/tree/main) -in Dragonfly. Before contributing, -be aware of branch definition would help a lot. - -As a contributor, keep in mind again that every -contribution via pull request is for branch main. -While in project Dragonfly, there are several other branches, -we generally call them rc branches, release branches and backport branches. - -Before officially releasing a version, -we will checkout a rc(release candidate) branch. -In this branch, we will test more than branch main. - -When officially releasing a version, -there will be a release branch before tagging. -After tagging, we will delete the release branch. - -When backporting some fixes to existing released version, -we will checkout backport branches. After backporting, -the backporting effects will be in PATCH number in -MAJOR.MINOR.PATCH of [SemVer](http://semver.org/). - -### Commit Rules - -Actually in Dragonfly, we take two rules seriously when committing: - -- [Commit Message](#commit-message) -- [Commit Content](#commit-content) - -#### Commit Message - -Commit message could help reviewers better understand -what the purpose of submitted PR is. -It could help accelerate the code review procedure as well. -We encourage contributors to use **EXPLICIT** commit -message rather than an ambiguous message. In general, -we advocate the following commit message type: - -- feat: xxxx.For example, "feat: make result show in sorted order". -- fix: xxxx. For example, "fix: fix panic when input nil parameter". -- docs: xxxx. For example, "docs: add docs about storage installation". -- style: xxxx. For example, "style: format the code style of Constants.java". -- refactor: xxxx. For example, "refactor: simplify to make codes more readable". -- test: xxx. For example, "test: add unit test case for func InsertIntoArray". -- chore: xxx. For example, "chore: integrate travis-ci". - It's the type of maintenance change. - -On the other side, we discourage contributors -from committing messages in the following ways: - -- ~~fix bug~~ -- ~~update~~ -- ~~add doc~~ - -#### Commit Content - -Commit content represents all content changes -included in one commit. We had better include things -in one single commit which could support reviewer's complete -review without any other commits' help. In another word, -contents in one single commit can pass the CI to avoid code mess. -In brief, there are two minor rules for us to keep in mind: - -- avoid very large change in a commit. -- complete and reviewable for each commit. - -No matter what the commit message, or commit content is, -we do take more emphasis on code review. - -### PR Description - -PR is the only way to make change to Dragonfly project files. -To help reviewers better get your purpose, -PR description could not be too detailed. -We encourage contributors to follow the -[PR template](./.github/PULL_REQUEST_TEMPLATE.md) to finish the pull request. - -### Developing Environment - -As a contributor, if you want to make any contribution to -Dragonfly project, we should reach an agreement on -the version of tools used in the development environment. -Here are some dependents with specific version: - -- golang: v1.15 -- misspell: latest -- shellCheck: latest -- docker: latest - -When you develop the Dragonfly project in the local environment, -you should use subcommands of Makefile to help yourself -to check and build the latest version of Dragonfly. -For the convenience of developers, -we use docker to build Dragonfly. -It can reduce problems of the developing environment. - -### Golang Dependency Management - -The Dragonfly project uses -[Go modules](https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more) -to manage dependencies on external packages. -This requires a working Go environment with version 1.15 or greater installed. - -To add or update a new dependency, use the `go get` command: - -```bash -# Pick the latest tagged release. -go get example.com/some/module/pkg - -# Pick a specific version. -go get example.com/some/module/pkg@vX.Y.Z -``` - -Tidy up the `go.mod` and `go.sum` files: - -```bash -go mod tidy -``` - -You have to commit the changes to `go.mod`, -`go.sum` before submitting the pull request. - -```bash -git add go.mod go.sum -git commit -``` - -## Engage to help anything - -We choose GitHub as the primary place for Dragonfly to -collaborate. So the latest updates of Dragonfly are always here. -Although contributions via PR is an explicit way to help, -we still call for any other ways. - -- Reply to others' issues if you could. -- Help solve other users' problems. -- Help review others' PR design. -- Help review others' codes in PR. -- Discuss Dragonfly to make things clearer. -- Advocate Dragonfly technology beyond GitHub. -- Write blogs on Dragonfly and so on. - -In a word, **ANY HELP IS CONTRIBUTION.** - -## Join Dragonfly as a member - -It is also welcomed to join Dragonfly team if you are -willing to participate in Dragonfly community continuously and be active. - -### Requirements - -- Have read the [Contributing to Dragonfly](CONTRIBUTING.md) carefully. -- Have read the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). -- Ability to maintain one or more modules of `scheduler`, `dfdaemon` and `manager`. -- Have submitted multi PRs to the community. -- Be active in the community, may including but not limited: - - Submitting or commenting on issues. - - Contributing PRs to the community. - - Reviewing PRs in the community. - -### How to do it - -You can do it in either of two ways: - -- Submit a PR in the - [dragonflyoss/dragonfly](https://github.com/dragonflyoss/dragonfly) repo. -- Contact with the community's [maintainers](MAINTAINERS.md) offline. +Please refer to the [community contributing guide](https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md). diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 67c519f75..51b0d8a3e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,190 +1,3 @@ # Dragonfly Project Governance -As a CNCF member project, Dragonfly project abides by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). - -This doc outlines the responsibilities of contributor roles in Dragonfly. The Dragonfly project is subdivided into sub-projects -under (predominantly, but not exclusively) nydus, nydus-snapshotter, api, docs, console and client. -Responsibilities for roles are scoped to these sub-projects (repos). - -We have six levels of responsibility including: - -- Contributor -- Member -- Approver -- Maintainer -- Administrator - -## Contributor - -A Contributor is someone who has contributed to the project by submitting code, issues, or participating in discussions. - -### Responsibilities - -- Contribute code changes via pull requests (PRs). -- Raise issues for bugs, enhancements, or other discussions. -- Participate in code reviews if requested. -- Follow the project's Code of Conduct and contribution guidelines. - -### Requirements - -- Have a GitHub account. -- Sign the Contributor License Agreement (if applicable). -- Adhere to the project's coding standards and guidelines.Contributor - -## Member - -A Member is a contributor who has shown long-term commitment to the project, -consistently contributing high-quality work and actively participating in the community. - -Responsibilities: - -- All responsibilities of a Contributor. -- Participate in project planning and decision-making processes. -- Mentor new contributors. -- Actively participate in community meetings and discussions. - -Requirements: - -- Demonstrated history of contributions (code, reviews, discussions) over at least 3 months. -- Invitation by a Maintainer or Administrator based on consensus. -- Continued adherence to the project's Code of Conduct. - -## Approver - -An Approver is a member who has the additional responsibility of reviewing and approving PRs that affect the project. - -Responsibilities: - -- All responsibilities of a Member. -- Review and approve PRs from Contributors and Members. -- Ensure that changes adhere to coding standards, do not introduce bugs, and improve the project. -- Help triage issues and provide feedback on improvements. - -Requirements: - -- Demonstrated expertise in the project’s codebase. -- Consistent and high-quality contributions. -- Trusted by Maintainers and Administrators to provide accurate reviews and approvals. - -## Maintainer - -A Maintainer is an experienced and trusted member who has extensive knowledge of the project, including architecture -and design principles. Maintainers have the authority to merge PRs and make significant project decisions. - -Responsibilities: - -- All responsibilities of an Approver. -- Merge PRs to the main branch. -- Ensure the overall quality, stability, and performance of the codebase. -- Coordinate releases and update documentation. -- Guide the project's technical direction and roadmap. -- Facilitate communication and collaboration within the community. - -Requirements: - -- Demonstrated long-term, high-quality contributions and leadership in the project. -- Deep understanding of the project’s architecture and design. -- Commitment to the project's goals and values. -- Nominated and approved by existing Maintainers and Administrators. - -### Maintainership - -Maintainers of Dragonfly share the responsibility. And they have 3 things in general: - -- share responsibility in the project's success; -- make a long-term investment to improve the project; -- spend time doing whatever needs to, not only the most interesting part; - -Maintainers are often working hard, but sometimes what they do is hardly appreciate. -It is easy to work on the fancy part or technically advanced feature. It is harder -to work on minor bugfix, small improvement, long-term stable optimization or -others. While all of the above is the essential parts to build up a successful project. - -### Adding Maintainers - -Maintainers are foremost and first contributors that have dedicated to the long -term success of the project. Contributors wishing to become maintainers are -expected to deeply involved in tackling issues, contributing codes, review -proposals and codes for more than two months. - -Maintainership is built on trust. Trust is totally beyond just contributing -code. Thus it is definitely worthy to achieving current maintainers' trust via -bringing best interest for the project. - -Current maintainers will hold a maintainer meeting periodically. During the -meeting, filtering a list of active contributors that have proven to invest -regular time on project over the prior months. From the list, if maintainers -find that one or more are qualified candidates, then a proposal of adding -maintainers can be submitted to GitHub via a pull request. If a vote of at -least 50% agree with the proposal, the newly added maintainer must be treated -valid. - -### Removal of Inactive Maintainers - -Similar to adding maintainers, existing maintainer can been removed from the -active maintainer list. If the existing maintainer meet one of the conditions -below, any other maintainers can proposed to remove him from active list via a -pull request: - -- A maintainer has not participated in community activities for more than last - three months; -- A maintainer did not obey to the governance rules more than twice; - -After confirming conditions above, in theory maintainer can be removed from -list directly unless the original maintainer requests to remain maintainer seat -and gets a vote of at least 50% of other maintainers. - -If a maintainer is removed from the maintaining list, other maintainers should -at a column to the alumni part to thank the contribution made from the inactive -maintainer. - -### How to make decision - -Dragonfly is an open-source project illustrating the concept of open. This -means that Dragonfly repository is the source of truth for every aspect of the -project, including raw value, design, doc, roadmap, interfaces and so on. If it -is one part of the project, it should be in the repo. - -To be honest, all decisions can be regarded as an update to project. - -Any updates or changes which take effect on Dragonfly, no matter big or small, -should follow three steps below: - -- Step 1: Open a pull request; -- Step 2: Discuss under the pull request; -- Step 3: Merge or refuse the pull request. - -When Dragonfly has less than seven maintainers, a pull request except adding -maintainers pull request could be merged, if it meets both conditions below: - -- at least one maintainer commented `LGTM` to the pull request; -- no other maintainers have opposite opinion on it. - -When Dragonfly has more than seven maintainers, a pull request except adding -maintainers pull request could be merged, if it meets conditions below: - -- at least two maintainers commented `LGTM` to the pull request; - -### Updating Governance - -All substantive updates in Governance require a supermajority maintainers vote. - -## Administrator - -An Administrator has the highest level of access and responsibility in the project. They manage overall project governance, -ensure adherence to policies, and resolve conflicts within the community. - -Responsibilities: - -- All responsibilities of a Maintainer. -- Manage project settings and permissions. -- Ensure compliance with legal and organizational policies. -- Handle CoC violations and mediate conflicts. -- Facilitate election of new roles or changes in the governance structure. - -Requirements: - -- Proven contribution history and leadership within the project. -- Strong understanding of open-source community management. -- Trusted by the community and other Administrators. -- Appointed through consensus of current Administrators. +Please refer to the [community project governance](https://github.com/dragonflyoss/community/blob/master/GOVERNANCE.md). diff --git a/README.md b/README.md index 8a6d05411..a1bea44a0 100644 --- a/README.md +++ b/README.md @@ -80,7 +80,7 @@ Please refer to our [Code of Conduct][codeconduct]. [arch]: docs/images/arch.png [logo-linear]: docs/images/logo/dragonfly-linear.svg [discussion]: https://github.com/dragonflyoss/dragonfly/discussions -[contributing]: CONTRIBUTING.md -[codeconduct]: CODE_OF_CONDUCT.md +[contributing]: https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md +[codeconduct]: https://github.com/dragonflyoss/community/blob/master/CODE_OF_CONDUCT.md [d7y.io]: https://d7y.io/ [dingtalk]: docs/images/community/dingtalk-group.jpeg diff --git a/SECURITY.md b/SECURITY.md index 8e700dec7..09631ea6f 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,52 +1,3 @@ # Security Policy -## Reporting a Vulnerability - -To report a Dragonfly vulnerability: - -1. Navigate to the security tab on the repository GitHub Security Tab. -2. Click on Advisories GitHub Advisories tab. -3. Click on Report a vulnerability. - -The reporter(s) can expect a response within 24 hours acknowledging the issue was received. -If a response is not received within 24 hours, please reach out to any committer directly to confirm receipt of the issue. - -## Review Process - -Once a committer has confirmed the relevance of the report, a draft security advisory will be created on GitHub. -The draft advisory will be used to discuss the issue with committers, the reporter(s), and Dragonfly's security advisors. -If the reporter(s) wishes to participate in this discussion, then provide reporter GitHub username(s) to be invited -to the discussion. If the reporter(s) does not wish to participate directly in the discussion, -then the reporter(s) can request to be updated regularly via email. - -If the vulnerability is accepted, a timeline for developing a patch, public disclosure, and patch release will be -determined. If there is an embargo period on public disclosure before the patch release, -an announcement will be sent to the security announce mailing list announcing -the scope of the vulnerability, the date of availability of the patch release, and the date of public disclosure. -The reporter(s) are expected to participate in the discussion of the timeline and abide by agreed-upon dates for public disclosure. - -## Supported Versions - -See the Dragonfly releases page for information on supported versions of Dragonfly. -Any Extended or Active release branch may receive security updates. For any security issues discovered -on older versions, non-core packages, or dependencies, please inform committers using -the same security mailing list as for reporting vulnerabilities. - -## Joining the Security Announce Mailing List - -Any organization or individual who directly uses Dragonfly and non-core packages in production or in a -security-critical application is eligible to join the security announce mailing list. Indirect users -who use Dragonfly through a vendor are not expected to join but should request their vendor join. -To join the mailing list, the individual or organization must be sponsored by either a Dragonfly committer or -security advisor as well as have a record of properly handling non-public security information. -Sponsorship should not be requested via public channels since membership of the security announce list is not public. - -### Mailing Lists - -- **dragonfly-developers@googlegroups.com**: Report security concerns. - -### Confidentiality, Integrity, and Availability - -We prioritize vulnerabilities that compromise data confidentiality, privilege elevation, or integrity. -Availability issues, such as DoS and resource exhaustion, are also serious concerns. -Operators must configure settings, role-based access control, and other features to provide a hardened environment. +Please refer to the [community security policy](https://github.com/dragonflyoss/community/blob/master/SECURITY.md).