-
Notifications
You must be signed in to change notification settings - Fork 22
Contribution Rules
You must follow the rules described below as part of the Automan community. Please read the following carefully before you start contributing to Automan. Thank you for your time.
To assure traceability in your code, please follow our development process:
- If you are working on a feature/modify-node, create an issue first.
- Declare the release version in each release issue if the issue is targeting to a specific release.
- Create a branch, work on the feature/modify-node, refer in at least one commit to the issue #number.
- Open a pull request for the given feature/modify-node and fill out the pull request template.
This will assure that you know where the feature originated from and the implemented code will be linked to the feature request (or bug report). Otherwise there is absolutely no traceability. Secondly, with the pull request template it will be easier for the reviewer(s) to understand the changes and we can later on convert "Steps to Reproduce" into integration tests.
In order to make the development process efficient, we ask you to comply with the branching model described below. On this model, we mainly use six branches - master, develop, feature, release, experimental, and hotfix.
This is the latest stable version of AutomanTools.
In general, developers should NOT work on the "develop" branch. When you develop new functions, please check out a new branch, "feature/[branch_name]", from the "develop" branch, and modify the code there. After the modificaiton, please send a pull request to the "develop" branch.
This situation is true of only the persons in charge of releasing AutomanTools. Once we complete some major development, we make a new release. For the release work, please checkout a new branch, "release/[1.xx.yy], from the "develop" branch, and modify the code there. After the modification, please send a pull request: "xx" in version of release/[1.xx.yy] is increased when checked out from the "develop" branch, and yy is also increased when bug fixes are done. Finally, we merge this branch to the master branch, attaching a version tag.
If we encounter bugs in the "master" branch after the release, we check out the "hotfix" branch from the "master" branch and fix the bugs there. This branch is merged to each corresponding branch - master, release, and develop. After the merge, the version of the master and the release branches is increased.
Reference for the git-flow model
When you are ready to send a pull request from your branch, please follow:
- A design article should be posted with a GitHub comment for every feature or bug.
- Every feature/bug implementation needs to be thoroughly reviewed. You can specify your favorite or appropriate reviewers by @accountname.
- The integration test with the demo data needs to be passed.
- Coding style enforcement must be applied: e.g., flake8, pep8, eslint.
Please check coding style with the following commands.
pipenv run flake8
pipenv run pep8
Please check coding style with the following command.
yarn lint