Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

update contributing style guide

  • Loading branch information...
commit 2d1bffb61a69119a31f885b9a6a04ccd12c883e3 1 parent 09c53ba
Hsiaoming Yang authored
Showing with 66 additions and 18 deletions.
  1. +61 −17
  2. +5 −1
@@ -1,25 +1,69 @@
+# Contributing
-First, please do contribute!
+First, please do contribute! There are more than one way to contribute, and I will appreciate any way you choose.
-There are three ways to contribute:
+- introduce spm to your friends, let spm to be known
+- discuss spm, and submit bugs with github issues
+- write a spm plugin, and share with us
+- translate documentation for us
+- send patch with github pull request
-1. introduce spm to your friends
-2. write a spm plugin
-3. send pull request to spm
+English and Chinese issues are acceptable, talk in your favorite language.
+Pull request and git commit message must be in English, if your commit message is in other language, it will be rejected.
-* On first cloning the repo, run `make` from your command line to ensure all dependencies are met
-* Make your changes in a separate branch than `master`. It'll be easier for you to manage.
-* Write unit tests!
-* Run unit tests! There's a shortcut from your command line: `make test`.
-* Run lint! `make lint`
-* Send a pull request and explain your changes and why they are necessary.
+## Issues
-No contributions will be accepted that do not pass all tests or throw any linter errors.
+When you submit an issue, please format your content, a readable content helps a lot. You should have a little knowledge on [Markdown](
-The spm codebase is highly tested and linted, as a way to guarantee functionality and keep all code written in a particular style for readability.
+Code talks. If you can't make yourself understood, show us the code.
+- fork and clone repo [issue-cases](
+- add your case in the repo
+- send us a pull request
+Please make your case as simple as possible.
+## Codebase
+The codebase of spm is highly tested and linted, as a way to guarantee functionality and keep all code written in a particular style for readability.
+You should follow the code style, and if you add any code, please add test cases for them.
+Here is a little tips to make things simple:
+- when you cloned this repo, run `make`, it will prepare everything for you
+- check the code style with `make lint`
+- check the test case with `make test`
+If you are on Windows, you should have a look at the `Makefile` and find out what you should do. If you are familiar with Windows, please add a `make.bat` for me.
+## Git Help
+Something you should know about git.
+- don't add any code on the master branch, create a new one
+- don't add too many code in one pull request
+- all featured branches should be based on the master branch
+Take an example, if you want to add feature A and feature B, you should have two branches:
+$ git branch feature-A
+$ git checkout feature-A
+Now code on feature-A branch, and when you finish feature A:
+$ git checkout master
+$ git branch feature-B
+$ git checkout feature-B
+All branches must be based on the master branch. If your feature-B needs feature-A, you should send feature-A first, and wait for its merging. We may reject feature-A, and you should stop feature-B.
+We use a none fast forward merging strategy, please don't `git rebase`.
@@ -2,5 +2,9 @@
+This is a total rewrite of spm, it is still on heavy development.
+You should use the old [spm]( right now.
-This is a rebuild version of spm.
+## Contribute
+Yes, please do contribute. But before this, you should read our [Contributing Guide](
Please sign in to comment.
Something went wrong with that request. Please try again.