Contributing to OOPNET¶
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it’s:
Reporting a bug
Discussing the current state of the code
Submitting a fix
Proposing new features
Becoming a maintainer
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
Our Development Process¶
We use Github Actions, so all code changes happen through pull requests (PRs). Pull requests are the best way to propose changes to the codebase. We actively welcome your pull requests:
Fork the repo and create your branch from
main
.If you’ve added code that should be tested, add tests.
If you’ve changed APIs, update the documentation.
Ensure the test suite passes.
Make sure your code lints.
Issue that pull request!
Report bugs¶
We use Github’s issues to track public bugs. Report a bug by opening a new issue; it’s that easy!
For us to be able to fix a bug, we require information about the bug. Great Bug Reports tend to have:
A quick summary and/or background
Steps to reproduce
Be specific!
Give sample code if you can
What you expected would happen
What actually happens
Notes (possibly including why you think this might be happening, or stuff you tried that didn’t work)
People love thorough bug reports. I’m not even kidding.
Request a feature¶
If you want a new feature in OOPNET, please provide us with a use case and a description of what is missing. If possible, provide a code snippet that describes your use case. If you already have a solution for the implementation, please add this to the issue as well.
Security issues¶
If you find a security vulnerability, do NOT open an issue. Email oopnet.contact@gmail.com instead.
Style and standards¶
OOPNET uses a few standards to simplify its development. Please adhere to them.
Coding Style¶
Codes will be formatted by black as part of the CI pipeline and check by Pylint.
Github issue labels¶
StandardIssueLabels are used for labeling issues. Please read the description to choose the correct label(s) for your issue.
Git commit messages¶
Semantic Versioning is used to calculate the next version number based of the commits and their corresponding commit message. We use the Angular Commit message format for this purpose. Please, adhere to this standard, if you want your PR to be merged.
Versions look like this: MAJOR.MINOR.PATCH
For now, MAJOR is set to 0 until OOPNET is deemed stable.
Code of Conduct¶
Please read our Code of Conduct before interacting with the OOPNET team or the community. Violations will be met with clear consequences.
License¶
In short, when you submit code changes, your submissions are understood to be under the same MIT License that covers the project.
References¶
This document was adapted from the open-source contribution guidelines by Brian Danielak which is based on the guidelines for Meta’s Draft-JS