Please take a look at our code of conduct and adhere to the rules. Note that actions will be taken against individuals who violate our rules.
Help us keep discussions focused by checking if there already exists a thread pertaining to your issue before creating a thread. Duplicate threads will be redirected to existing ones.
Create an issue on our issues tracker and tag the issue as a bug. In the issue, please provide a short description of the bug and the steps required to replicate it.
Useful Information
- Operating System (mac/win/linux)
- Python Environment (venv/pyenv)
- Step by step information to recreate the bug
Join us in our discussion board. Post your thread regarding
- Questions on the project
- Suggestions/features requests
- Projects built using our project
Here is a guide of the general steps to contribute code to PeekingDuck.
-
Own an issue from the issues board. This is to prevent duplicate work.
- Pick an issue from our issues tracker and indicate your interest to work on the issue.
- If there are no one else working on the issue, the maintainer will assign the issue to you.
- After receiving the confirmation from the maintainer, you may begin work on the issue.
-
Contributing Code
- Do read our code styles guidelines.
- Fork the aimakerspace/PeekingDuck repository. For more details in this process, Jake Jarvis has a useful guide that describes steps 2-6 and 10 in more detail.
- Clone the forked branch to your local machine.
- [Recommended] track the original repository as another remote. After which you will be able to receive updates using
git fetch. This is useful for long term contributions to the repository. - In your local repository, create a descriptive branch to work on your issue.
- Make the required changes within the branch.
- Add tests (if possible).
- Run the test suite and check that it passes.
- Push the changes to your github remote.
- Send us a pull request to PeekingDuck/dev.
- Make changes requested by your reviewer (if any).
Thank you for your contribution!!
Help us maintain the quality of our project by following the conventions we take below.
This is a shortened version inspired by angular's contributing docs.
A standard git commit message helps us structure the project.
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: core|cli|changelog|packaging|models|heuristics|cicd-infra|docs-infra|community
│
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|testThe <type> and <summary> fields are required, we encourage filling the (<scope>) field where possible.
The following conventions are adopted to help maintain code consistency.
- PEP8 convention
- PEP484 type hinting for functions and methods
- Absolute imports instead of relative imports
The project uses tools like pylint, pytest and bandit to maintain project quality. To run the test in mac use sh (for linux use bash).
sh scripts/linter.sh # pylint for pep8 and code consistency
sh scripts/bandit.sh # bandit to check for security related issues on dependencies
sh scripts/check_type.sh # mypy to check for type hints on function/method level
sh scripts/unit_tests.sh # pytest unit test for individual components
sh scripts/usecase_tests.sh # check standard usecase to ensure it is not brokenNOTE - linter, bandit, check_type runs on every pull request