update contribution.md (#86)

* update contrib

* update links

.github/CONTRIBUTING.md

-## Contributing to OpenMMLab
+## Contributing to InternLM
 
-Welcome to the MMCV community, we are committed to building a cutting-edge computer vision foundational library and all kinds of contributions are welcomed, including but not limited to
+Welcome to the InternLM community, all kinds of contributions are welcomed, including but not limited to
 
 **Fix bug**
 
@@ -34,29 +34,29 @@ If you are posting a pull request for the first time, you should fork the OpenMM
 Then, you can clone the repositories to local:
 
 ```shell
-git clone git@github.com:{username}/mmcv.git
+git clone git@github.com:{username}/lmdeploy.git
 ```
 
 After that, you should add official repository as the upstream repository
 
 ```bash
-git remote add upstream git@github.com:open-mmlab/mmcv
+git remote add upstream git@github.com:InternLM/lmdeploy.git
 ```
 
 Check whether remote repository has been added successfully by `git remote -v`
 
 ```bash
-origin	git@github.com:{username}/mmcv.git (fetch)
-origin	git@github.com:{username}/mmcv.git (push)
-upstream	git@github.com:open-mmlab/mmcv (fetch)
-upstream	git@github.com:open-mmlab/mmcv (push)
+origin	git@github.com:{username}/lmdeploy.git (fetch)
+origin	git@github.com:{username}/lmdeploy.git (push)
+upstream	git@github.com:InternLM/lmdeploy.git (fetch)
+upstream	git@github.com:InternLM/lmdeploy.git (push)
 ```
 
 > Here's a brief introduction to origin and upstream. When we use "git clone", we create an "origin" remote by default, which points to the repository cloned from. As for "upstream", we add it ourselves to point to the target repository. Of course, if you don't like the name "upstream", you could name it as you wish. Usually, we'll push the code to "origin". If the pushed code conflicts with the latest code in official("upstream"), we should pull the latest code from upstream to resolve the conflicts, and then push to "origin" again. The posted Pull Request will be updated automatically.
 
 #### 2. Configure pre-commit
 
-You should configure [pre-commit](https://pre-commit.com/#intro) in the local development environment to make sure the code style matches that of OpenMMLab. **Note**: The following code should be executed under the MMCV directory.
+You should configure [pre-commit](https://pre-commit.com/#intro) in the local development environment to make sure the code style matches that of InternLM. **Note**: The following code should be executed under the lmdeploy directory.
 
 ```shell
 pip install -U pre-commit
@@ -101,7 +101,7 @@ git pull upstream master
 
 #### 4. Commit the code and pass the unit test
 
-- MMCV introduces mypy to do static type checking to increase the robustness of the code. Therefore, we need to add Type Hints to our code and pass the mypy check. If you are not familiar with Type Hints, you can refer to [this tutorial](https://docs.python.org/3/library/typing.html).
+- lmdeploy introduces mypy to do static type checking to increase the robustness of the code. Therefore, we need to add Type Hints to our code and pass the mypy check. If you are not familiar with Type Hints, you can refer to [this tutorial](https://docs.python.org/3/library/typing.html).
 
 - The committed code should pass through the unit test
 
@@ -141,7 +141,7 @@ Find more details about Pull Request description in [pull request guidelines](#p
 
 **note**
 
-(a) The Pull Request description should contain the reason for the change, the content of the change, and the impact of the change, and be associated with the relevant Issue (see [documentation](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
+(a) The Pull Request description should contain the reason for the change, the content of the change, and the impact of the change, and be associated with the relevant Issue (see [documentation](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue))
 
 (b) If it is your first contribution, please sign the CLA
 
@@ -151,7 +151,7 @@ Find more details about Pull Request description in [pull request guidelines](#p
 
 <img src="https://user-images.githubusercontent.com/57566630/167307490-f9ebf9fa-63c0-4d83-8ba1-081ea169eb3a.png" width="1200">
 
-MMCV will run unit test for the posted Pull Request on different platforms (Linux, Window, Mac), based on different versions of Python, PyTorch, CUDA to make sure the code is correct. We can see the specific test information by clicking `Details` in the above image so that we can modify the code.
+IternLM will run unit test for the posted Pull Request on different platforms (Linux, Window, Mac), based on different versions of Python, PyTorch, CUDA to make sure the code is correct. We can see the specific test information by clicking `Details` in the above image so that we can modify the code.
 
 (3) If the Pull Request passes the CI, then you can wait for the review from other developers. You'll modify the code based on the reviewer's comments, and repeat the steps [4](#4-commit-the-code-and-pass-the-unit-test)-[5](#5-push-the-code-to-remote) until all reviewers approve it. Then, we will merge it ASAP.
 
@@ -177,28 +177,6 @@ If you are very good at handling conflicts, then you can use rebase to resolve c
 
 ### Guidance
 
-#### Unit test
-
-If you cannot run the unit test of some modules for lacking of some dependencies, such as [video](https://github.com/open-mmlab/mmcv/tree/master/mmcv/video) module, you can try to install the following dependencies:
-
-```shell
-# Linux
-sudo apt-get update -y
-sudo apt-get install -y libturbojpeg
-sudo apt-get install -y ffmpeg
-
-# Windows
-conda install ffmpeg
-```
-
-We should also make sure the committed code will not decrease the coverage of unit test, we could run the following command to check the coverage of unit test:
-
-```shell
-python -m coverage run -m pytest /path/to/test_file
-python -m coverage html
-# check file in htmlcov/index.html
-```
-
 #### Document rendering
 
 If the documents are modified/added, we should check the rendering result. We could install the dependencies and run the following command to render the documents and check the results:
@@ -226,15 +204,13 @@ We use the following tools for linting and formatting:
 - [mdformat](https://github.com/executablebooks/mdformat): Mdformat is an opinionated Markdown formatter that can be used to enforce a consistent style in Markdown files.
 - [docformatter](https://github.com/myint/docformatter): A formatter to format docstring.
 
-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`, `markdown files`,
 fixes `end-of-files`, `double-quoted-strings`, `python-encoding-pragma`, `mixed-line-ending`, sorts `requirments.txt` automatically on every commit.
-The config for a pre-commit hook is stored in [.pre-commit-config](./.pre-commit-config.yaml).
+The config for a pre-commit hook is stored in [.pre-commit-config](../.pre-commit-config.yaml).
 
 #### C++ and CUDA
 
-We follow the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html).
+The clang-format config is stored in [.clang-format](../.clang-format).
 
 ### PR Specs
 

docs/en/serving.md

@@ -2,7 +2,7 @@
 
 ## Serving [LLaMA](https://github.com/facebookresearch/llama)
 
-Weights for the LLaMA models can be obtained from by filling out [this form](<(https://docs.google.com/forms/d/e/1FAIpQLSfqNECQnMkycAp2jP4Z9TFX0cGR4uf7b_fBxjY_OjhJILlKGA/viewform)>)
+Weights for the LLaMA models can be obtained from by filling out [this form](https://docs.google.com/forms/d/e/1FAIpQLSfqNECQnMkycAp2jP4Z9TFX0cGR4uf7b_fBxjY_OjhJILlKGA/viewform)
 
 <details open>
 <summary><b>7B</b></summary>