Contribution Guidelines for Developers en

Developers Contribution Guidelines

Welcome! Whatever you would like to implement a new feature for a certain application, or submit a simple patch, even just to fix typos – your help is greatly appreciated. We'd like to invite you to contribute changes and make Deepin even better than it is today!

Let's get you started.

License and Code of Covenant

All projects comes with its LICENSE, so before you start, make sure you read and agree the license.

All Deepin projects adheres to the Contributor Covenant 2.1. By participating, you are expected to uphold this code. Please report unacceptable behavior to support@linuxdeepin.com.

Fetching the Source Code

We host all the code on GitHub, so you could clone projects directly from GitHub now via a simple git clone.

The thing which worth to mention is, the master branch is our development branch, thus sometimes the master state of a single application may requires another master state project to build/run. So when you get the source code, you may need to preform a git checkout to a tag version which you would like to use first.

The README.md comes with the project will contains the informations you may need to know, which may included the build steps, so check them out first.

Submit Pull Requests

We now accept GitHub Pull Request so you can submit your patches via Pull Requests directly on GitHub. Read the help page about pull requests to learn more about how it works and how to use it.

If you still prefer the classic way, you can still send your patch/diff to us, but we still recommend you use Pull Request.

Generic Pull Request Rules

All Pull Requests reqires pass the Continuous Integration Build and Code Review to merge. To help getting your changes merged, please make sure you followed these generic rules:

Make Sure Your Change Can be Accepted

We would love to help you get your simple patch merged, bug-fix and fix-typo can be merged without doubt. But once you planning to work on something big, like refacting code or adding a new feature, please creat a new issue first and so we can make sure we can accept these change.

Due to the product manager / designer / project direction decision, sometimes a single new feature won't be accepted after the discussion. Don't worry about that, you are always free to create a community fork of a specific project as long as you follow the license, and then share your work with the whole community.

After make sure your change can be accpeted, please follow these notes:

Notes for Your Commits

Coding Style
Before the hacking work, it is strongly recommended to read the code specifications to ensure a uniform style, and for some special projects, reading the HACKING file in root directory will give you useful information.
Commit Message Guideline
see Commit Message Format.
Atomic Pull Requests
Sometimes you may would like to make several changes to a project, but to make the code review process eaies, also to make the commit history cleaner, please make sure you only do one single task in a single Pull Request. Submit multiple Pull Request if you really need to submit a sequence of change.