Project: Flomesh Service Mesh (FSM) (Orchestration & Management / Service Mesh)
File: CONTRIBUTING.md

The FSM project accepts contributions via GitHub pull requests. This document outlines the requirements for contributing to this project. The FSM project recommends drafting a design doc in a shareable Google doc for features that significantly alter core control plane components or change the existing behavior. It is recommended to have the design doc reviewed by the FSM project maintainers and relevant stakeholders before proceeding with an implementation. The design doc must be referenced in the Github issue corresponding to the feature being requested. Introduction of new custom APIs, feature changes requiring significant changes to the control plane, features impacting multiple FSM components, and refactoring work for performance optimization, are some of the examples of when a design doc is necessary. The following sections describe how to contribute code by opening a pull request. Visit `https://github.com/flomesh-io/fsm`. Click the `Fork` button. Set `GITHUB_USERNAME` to match your Github username: ```sh export GITHUB_USERNAME=<github username> ``` Clone and set up your fork: ```sh git clone git@github.com:$GITHUB_USERNAME/fsm.git cd fsm git remote add upstream git@github.com:flomesh-io/fsm.git git remote set-url --push upstream no_push git remote -v ``` Get your local `main` branch up to date with upstream's `main` branch: ```sh git fetch upstream git checkout main git rebase upstream/main ``` Create a local branch from `main` for your development: ```sh git checkout -b <branch name> ``` Keep your branch up to date during development: ```sh git fetch upstream git rebase upstream/main ``` Make code changes on the `feature` branch and commit them with your signature ```sh git commit -s ``` Follow the . Make sure to squash your commits before opening a pull request. This is preferred so that your pull request can be merged as is without requesting to be squashed before merge if possible. Push your branch to your remote fork: ```sh git push -f <remote name> <branch name> ``` Visit your fork at `https://github.com/$GITHUB_USERNAME/fsm`. Open a pull request from your `feature` branch using the `Compare & Pull Request` button. Fill the pull request template and provide enough description so that it can be reviewed. If your pull request is not ready to be reviewed, open it as a draft. Your pull request will be reviewed by the maintainers to ensure correctness. Reviewers might approve the pull request or suggest improvements to make before the changes can be committed. When addressing review comments, refrain from rewriting the Git history of your branch (e.g. with `git commit --amend` or `git rebase`) where possible to make those changes easy to review. Instead, prefer creating new commits without `--amend` and using `git merge` to resolve conflicts with the upstream branch. The commit style guidelines below will not be enforced for follow-up commits. When the PR is merged, all commits in the PR will automatically be squashed into one commit added to the upstream branch. Pull requests by default must be merged by a core maintainer. Maintainers can add the `automerge` or `autorebase` label to a pull request, additional details . Pull requests will be merged based on the following criteria: Has at least two LGTM from a core maintainer. Commits follow the . Does not have the `do-not-merge/hold`

Does not have the `wip` label. All status checks have succeeded. Commits in the pull request are squashed and have a valid . If the commits in the PR are not squashed, maintainers must use the `squash and merge` option to squash the commits before merging. Maintainers may choose to update the commit message to meet the commit message guidelines without altering the signatures of the authors of the pull request. In certain situations, it is okay to have multiple related but independent commits in the same pull request. In such cases, a pull request may be merged as a `merge commit`. If the person who opened the pull request is a core maintainer, then only that person is expected to merge once it has the necessary LGTMs/reviews. Another maintainer can merge the pull request at their discretion if they feel the pull request must be merged urgently. Maintainers may edit the commit message for `Squash and merge`d PRs to remove messages from follow-up commits. We follow a rough convention for commit messages borrowed from . This is an example of a commit: ```vim feat(scripts/test-cluster): add a cluster test command Adds test experience where there was none before and resolves #1213243. ``` This is a more formal template: ```vim {type}({scope}): {subject} <BLANK LINE> {body} ``` The `{scope}` can be anything specifying the place of the commit change. Use `` to denote multiple areas (i.e. `scripts/: refactored lots of stuff`). The `{subject}` needs to use imperative, present tense: `change` not `changed` nor `changes`. The first letter should not be capitalized, and there is no dot (`.`) at the end. Just like the `{subject}`, the message `{body}` needs to be in the present tense and includes the motivation for the change as well as a contrast with the previous behavior. The first letter in the paragraph must be capitalized. If there is an issue number associate with the chunk of work that should be mentioned in this section as well so that it may be closed once the PR with this commit is merged. Any line of the commit message cannot be longer than 72 characters, with the subject line limited to 50 characters. This allows the message to be easier to read on GitHub as well as in various git tools. The allowed types for `{type}` are as follows: ```text feat -> feature fix -> bug fix docs -> documentation style -> formatting ref -> refactoring code test -> adding missing tests chore -> maintenance ``` The sign-off is a simple line at the end of the explanation for a commit. All commits needs to be signed. Your signature certifies that you wrote the patch or otherwise have the right to contribute the material. The rules are pretty simple, if you can certify the below (from ): ```properties Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developer's Certificate of Origin

By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ``` Then you just add a line to every git commit message: ```vi Signed-off-by: Joe Smith <joe.smith@example.com> ``` Use your real name (sorry, no pseudonyms or anonymous contributions.) If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. Note: If your git config information is set properly then viewing the `git log` information for your commit will look something like this: ```vi Author: Joe Smith <joe.smith@example.com> Date: Thu Feb 2 11:41:15 2018 -0800 Update README Signed-off-by: Joe Smith <joe.smith@example.com> ``` Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will be rejected by the automated DCO check. FSM's primary documentation is made available at . Any documentation content that needs to be visible on the website must be created in the repository. Refer to the for more details. Documentation that is primarily intended for use with this code repo (instead of as a website) can be found in . Refer to the to document custom APIs. We use to help give a high level overview and track what work is going on and what stage it is in. If you want an idea of our roadmap and prioritization, this is the best place to find that information. If a bug is found, need clarification, or want to propose a feature, submit an issue using . We use once all issues tagged in the milestone are closed or moved to the next milestone. This project's releases will follow for labeling releases to maintain backwards compatibility. Features and functionality may be added in major (x.0.0) and minor (0.x.0) releases. Bug fixes may be added in patch releases (0.0.x). We will follow semantic versioning to guarantee features, flags, functionality, public APIs will be backwards compatible as the versioning scheme suggests. Please properly attribute any code that is copied or inspired by another project to the author(s) of the work. Read the license of the original project to understand how to properly attribute work from that project and include this in your pull request.