[20181012] Contribution Guide

For contributing source code to the project smoothly, every contributor should follow the below guidance.

Branch

• Release candidate branch

Use master branch as release candidate branch, only feature/bug fix which fully passed test can commit to this branch.

• Stabilizing branch

For each release version, the release manager will create a corresponding branch and start integrate test on that branch. Only bug fix pull request is acceptable for this branch. The release manager is also responsible for regularly merge back the issue fixing commits back to the release candidate branch.

• Stabilized branch

For each released version, keep the corresponding branch. Usually they won't be updated again, except for critical problems.

• Developing branch

For feature developing or bug fixing, should create specific branch by contributors themselves name as dev_feature name or dev_issue id, and complete and fully pass test before submit pull request.

Check errors with Pylint

Pylint is a python package designed to help you check errors or poor coding practices. We recommend using Pylint with the default settings of Visual Studio Code. For those who would like to use Pylint from command line, we provide a configuration file in our repository: nni/pylintrc

Currently our pylint settings follows VS Code - Default Pylint rules, which:

• Enable all Error (E) and Fatal (F) messages.
• Disable all Convention (C) and Refactor (R) messages.
• Disable all Warning (W) messages except the following:
  • unreachable (W0101): Unreachable code
  • duplicate-key (W0109): Duplicate key %r in dictionary
  • unnecessary-semicolon (W0301): Unnecessary semicolon
  • global-variable-not-assigned (W0602): Using global for %r but no assignment is done
  • unused-variable (W0612): Unused variable %r
  • binary-op-exception (W0711): Exception to catch is the result of a binary "%s" operation
  • bad-format-string (W1302): Invalid format string
  • anomalous-backslash-in-string (W1401): Anomalous backslash in string
  • bad-open-mode (W1501): "%s" is not a valid mode for open

Pull Request

• Each Pull Request must be associated with an issue.
• The target of every pull request should always be the master branch (release candidate) at first, and the release manager will determine and assign a specific target for the pull request.
• The release manager will determine which time is suitable for releasing a new version, and he/she will create a new stabilizing branch base on the release candidate branch, and start integrate test for stabilizing. The release manager is also responsible for merging the issue fixing commits back to the release candidate branch.

Release version

• Each release version should has a corresponding tag (e.g. v0.10, v0.11), the tag should not be modified in principle.
• For small update or urgent bug fix, slightly increase the version number, for import feature, significantly increase the version number.