Skip to content

Commit

Permalink
[Docs] Add contribution guides (#1442)
Browse files Browse the repository at this point in the history
* temp

* en contribution ready

* finalize

* fix

* update
  • Loading branch information
gaotongxiao committed Oct 14, 2022
1 parent ec395c5 commit f619c69
Show file tree
Hide file tree
Showing 3 changed files with 267 additions and 203 deletions.
204 changes: 1 addition & 203 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,203 +1 @@
# Contributing to MMOCR

All kinds of contributions are welcome, including but not limited to the following.

- Fixes (typo, bugs)
- New features and components

Contents

- [Contributing to MMOCR](#contributing-to-mmocr)
- [Workflow](#workflow)
- [Main Steps](#main-steps)
- [Detailed Steps](#detailed-steps)
- [Step 1: Create a Fork](#step-1-create-a-fork)
- [Step 2: Develop a new feature](#step-2-develop-a-new-feature)
- [Step 2.1: Keep your fork up to date](#step-21-keep-your-fork-up-to-date)
- [Step 2.2: Create a feature branch](#step-22-create-a-feature-branch)
- [Step 3: Commit your changes](#step-3-commit-your-changes)
- [Step 4: Prepare to Pull Request](#step-4-prepare-to-pull-request)
- [Step 4.1: Merge official repo updates to your fork](#step-41-merge-official-repo-updates-to-your-fork)
- [Step 4.2: Push \<your_feature_branch> branch to your remote forked repo,](#step-42-push-your_feature_branch-branch-to-your-remote-forked-repo)
- [Step 4.3: Create a Pull Request](#step-43-create-a-pull-request)
- [Step 4.4: Review code](#step-44-review-code)
- [Step 4.5: Revise \<your_feature_branch> (optional)](#step-45-revise-your_feature_branch--optional)
- [Step 4.6: Delete \<your_feature_branch> branch if your PR is accepted.](#step-46-delete-your_feature_branch-branch-if-your-pr-is-accepted)
- [Code style](#code-style)
- [Python](#python)
- [Installing pre-commit hooks](#installing-pre-commit-hooks)
- [C++ and CUDA](#c-and-cuda)

## Workflow

### Main Steps

1. Fork and pull the latest MMOCR
2. Checkout a new branch (do not use main branch for PRs)
3. Commit your changes
4. Create a PR

**Note**

- If you plan to add some new features that involve large changes, it is encouraged to open an issue for discussion first.
- If you are the author of some papers and would like to include your method to MMOCR, please let us know (open an issue or contact the maintainers). We will much appreciate your contribution.
- For new features and new modules, unit tests are required to improve the code's robustness.

### Detailed Steps

The official public [repository](https://github.com/open-mmlab/mmocr) holds only one branch with an infinite lifetime: *main*

The *main* branch is the main branch where the source code of **HEAD** always reflects a state with the latest development changes for the next release.

Feature branches are used to develop new features for the upcoming or a distant future release.

All new developers to **MMOCR** need to follow the following steps:

#### Step 1: Create a Fork

1. Fork the repo on GitHub or GitLab to your personal account. Click the `Fork` button on the [project page](https://github.com/open-mmlab/mmocr).

2. Clone your new forked repo to your computer.

```
git clone https://github.com/<your name>/mmocr.git
```

3. Add the official repo as an upstream:

```
git remote add upstream https://github.com/open-mmlab/mmocr.git
```

#### Step 2: Develop a new feature

##### Step 2.1: Keep your fork up to date

Whenever you want to update your fork with the latest upstream changes, you need to fetch the upstream repo's branches and latest commits to bring them into your repository:

```
# Fetch from upstream remote
git fetch upstream
# Update your main branch
git checkout main
git rebase upstream/main
git push origin main
```

##### Step 2.2: Create a feature branch

- Create an issue on [github](https://github.com/open-mmlab/mmocr)

- Create a feature branch

```bash
git checkout -b feature/iss_<index> main
# index is the issue index on github above
```

#### Step 3: Commit your changes

Develop your new feature and test it to make sure it works well, then commit.

If you have not configured pre-commit hooks for MMOCR, please [install pre-commit hooks](#installing-pre-commit-hooks) before your first commit.

The commit message is suggested to be clear. Here is an example:

```bash
git commit -m "fix #<issue_index>: <commit_message>"
```

#### Step 4: Prepare to Pull Request

- Before creating an PR, please run

```bash
pre-commit run --all-files
pytest tests
```

and fix all failures.

- Make sure to link your pull request to the related issue. Please refer to the [instructon](https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue)

##### Step 4.1: Merge official repo updates to your fork

```
# fetch from upstream remote. i.e., the official repo
git fetch upstream
# update the main branch of your fork
git checkout main
git rebase upstream/main
git push origin main
# update the <your_feature_branch> branch
git checkout <your_feature_branch>
git rebase main
# solve conflicts if any and Test
```

##### Step 4.2: Push \<your_feature_branch> branch to your remote forked repo,

```
git checkout <your_feature_branch>
git push origin <your_feature_branch>
```

##### Step 4.3: Create a Pull Request

Go to the page for your fork on GitHub, select your new feature branch, and click the pull request button to integrate your feature branch into the upstream remote’s develop branch.

##### Step 4.4: Review code

##### Step 4.5: Revise \<your_feature_branch> (optional)

If PR is not accepted, pls follow steps above till your PR is accepted.

##### Step 4.6: Delete \<your_feature_branch> branch if your PR is accepted.

```
git branch -d <your_feature_branch>
git push origin :<your_feature_branch>
```

## Code style

### Python

We adopt [PEP8](https://www.python.org/dev/peps/pep-0008/) as the preferred code style.

We use the following tools for linting and formatting:

- [flake8](http://flake8.pycqa.org/en/latest/): linter
- [yapf](https://github.com/google/yapf): formatter
- [isort](https://github.com/timothycrosley/isort): sort imports

Style configurations of yapf and isort can be found in [setup.cfg](../setup.cfg).

We use [pre-commit hook](https://pre-commit.com/) that checks and formats for `flake8`, `yapf`, `isort`, `trailing whitespaces`,
fixes `end-of-files`, sorts `requirments.txt` automatically on every commit.
The config for a pre-commit hook is stored in [.pre-commit-config](../.pre-commit-config.yaml).

#### Installing pre-commit hooks

After you clone the repository, you will need to install and initialize pre-commit hook.

```shell
pip install -U pre-commit
```

From the repository folder

```shell
pre-commit install
```

After this on every commit check code linters and formatter will be enforced.

> Before you create a PR, make sure that your code lints and is formatted by yapf.
### C++ and CUDA

We follow the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html).
We appreciate all contributions to improve MMOCR. Please read [Contribution Guide](/docs/en/notes/contribution_guide.md) for step-by-step instructions to make a contribution to MMOCR, and [CONTRIBUTING.md](https://github.com/open-mmlab/mmcv/blob/master/CONTRIBUTING.md) in MMCV for more details about the contributing guideline.
133 changes: 133 additions & 0 deletions docs/en/notes/contribution_guide.md
Original file line number Diff line number Diff line change
@@ -1 +1,134 @@
# Contribution Guide

OpenMMLab welcomes everyone who is interested in contributing to our projects and accepts contribution in the form of PR.

## What is PR

`PR` is the abbreviation of `Pull Request`. Here's the definition of `PR` in the [official document](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) of Github.

```
Pull requests let you tell others about changes you have pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
```

## Basic Workflow

1. Get the most recent codebase
2. Checkout a new branch from `main` or `dev-1.x` branch, depending on the version of the codebase you want to contribute to (see [Maintenance Plan](../migration/overview.md) for more details)
3. Commit your changes ([Don't forget to use pre-commit hooks!](#3-commit-your-changes))
4. Push your changes and create a PR
5. Discuss and review your code
6. Merge your branch to `main` or `dev-1.x` branch

## Procedures in detail

### 1. Get the most recent codebase

- When you work on your first PR

Fork the OpenMMLab repository: click the **fork** button at the top right corner of Github page
![avatar](https://user-images.githubusercontent.com/22607038/195038780-06a46340-8376-4bde-a07f-2577f231a204.png)

Clone forked repository to local

```bash
git clone git@github.com:XXX/mmocr.git
```

Add source repository to upstream

```bash
git remote add upstream git@github.com:open-mmlab/mmocr
```

- After your first PR

Checkout the latest branch of the local repository and pull the latest branch of the source repository. Here we assume that you are working on the `dev-1.x` branch.

```bash
git checkout dev-1.x
git pull upstream dev-1.x
```

### 2. Checkout a new branch from the `main` branch or `dev-1.x` branch

```bash
git checkout -b branchname
```

```{tip}
To make commit history clear, we strongly recommend you checkout the `main` or `dev-1.x` branch before creating a new branch.
```

### 3. Commit your changes

- If you are a first-time contributor, please install and initialize pre-commit hooks from the repository root directory first.

```bash
pip install -U pre-commit
pre-commit install
```

- Commit your changes as usual. Pre-commit hooks will be triggered to stylize your code before each commit.

```bash
# coding
git add [files]
git commit -m 'messages'
```

```{note}
Sometimes your code may be changed by pre-commit hooks. In this case, please remember to re-stage the modified files and commit again.
```

### 4. Push your changes to the forked repository and create a PR

- Push the branch to your forked remote repository

```bash
git push origin branchname
```

- Create a PR
![avatar](https://user-images.githubusercontent.com/22607038/195053564-71bd3cb4-b8d4-4ed9-9075-051e138b7fd4.png)

- Revise PR message template to describe your motivation and modifications made in this PR. You can also link the related issue to the PR manually in the PR message (For more information, checkout the [official guidance](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)).

- Specifically, if you are contributing to `dev-1.x`, you will have to change the base branch of the PR to `dev-1.x` in the PR page, since the default base branch is `main`.

![avatar](https://user-images.githubusercontent.com/22607038/195045928-f3ceedc8-0162-46a7-ae1a-7e22829fe189.png)

- You can also ask a specific person to review the changes you've proposed.

### 5. Discuss and review your code

- Modify your codes according to reviewers' suggestions and then push your changes.

### 6. Merge your branch to the `main` / `dev-1.x` branch and delete the branch

- After the PR is merged by the maintainer, you can delete the branch you created in your forked repository.

```bash
git branch -d branchname # delete local branch
git push origin --delete branchname # delete remote branch
```

## PR Specs

1. Use [pre-commit](https://pre-commit.com) hook to avoid issues of code style

2. One short-time branch should be matched with only one PR

3. Accomplish a detailed change in one PR. Avoid large PR

- Bad: Support Faster R-CNN
- Acceptable: Add a box head to Faster R-CNN
- Good: Add a parameter to box head to support custom conv-layer number

4. Provide clear and significant commit message

5. Provide clear and meaningful PR description

- Task name should be clarified in title. The general format is: \[Prefix\] Short description of the PR (Suffix)
- Prefix: add new feature \[Feature\], fix bug \[Fix\], related to documents \[Docs\], in developing \[WIP\] (which will not be reviewed temporarily)
- Introduce main changes, results and influences on other modules in short description
- Associate related issues and pull requests with a milestone
Loading

0 comments on commit f619c69

Please sign in to comment.