Contribution Guidelines
We welcome and invite contributions from anyone at any career stage and with any amount of coding experience towards the development of pyTMD
.
We appreciate any and all contributions made to the project.
Please read our code of conduct before contributing to pyTMD
development.
You will be recognized for your work by being listed as one of the project contributors.
Ways to Contribute
Fixing typographical or coding errors
Submitting bug reports or feature requests through the use of GitHub issues
Improving documentation and testing
Sharing use cases and examples (such as Jupyter Notebooks)
Providing code for everyone to use
Adding model providers to the database
Requesting a Feature
Check the project issues tab to see if the feature has already been suggested.
If not, please submit a new issue describing your requested feature or enhancement .
Please give your feature request both a clear title and description.
Let us know if this is something you would like to contribute to pyTMD
in your description as well.
Reporting a Bug
Check the project issues tab to see if the problem has already been reported. If not, please submit a new issue so that we are made aware of the problem. Please provide as much detail as possible when writing the description of your bug report. Providing information and examples will help us resolve issues faster.
Contributing Code or Examples
We follow a standard Forking Workflow for code changes and additions. Submitted code goes through the pull request process for continuous integration (CI) testing and comments.
General Guidelines
Make each pull request as small and simple as possible
Larger changes should be broken down into their basic components and integrated separately
Bug fixes should be their own pull requests with an associated GitHub issue
Write a descriptive pull request message with a clear title
Be patient as reviews of pull requests take time
Steps to Contribute
Fork the repository to your personal GitHub account by clicking the “Fork” button on the project main page. This creates your own server-side copy of the repository.
Either by cloning to your local system or working in GitHub Codespaces, create a work environment to make your changes.
Add your fork as the
origin
remote and the original project repository as theupstream
remote. While this step isn’t a necessary, it allows you to keep your fork up to date in the future.Create a new branch to do your work.
Make your changes on the new branch and add yourself to the list of project contributors.
Push your work to GitHub under your fork of the project.
Submit a Pull Request from your forked branch to the project repository.
Adding Examples
Examples may be in the form of executable scripts or interactive Jupyter Notebooks. Fully working (but unrendered) examples should be submitted with the same steps as above.
Adding Model Providers
Model providers can be added to their respective JSON files. The main database can then be updated by running the merge providers script.
Continuous Integration
We use GitHub Actions continuous integration (CI) services to build and test the project on Linux (Ubuntu) and Mac Operating Systems. The configuration files for this service are in the GitHub workflows directory. The workflows rely on the environment.yml and requirements-dev.txt files to install the required dependencies.
The GitHub Actions jobs include:
Semantic Commit Messages
Please follow the Conventional Commits specification for your commit messages to help organize the pull requests:
<type>: <subject>
[optional message body]
where <type>
is one of the following:
feat
: adding new features or programsfix
: fixing bugs or problemsdocs
: changing the documentationstyle
: changing the line order or adding commentsrefactor
: changing the names of variables or programsci
: changing the continuous integration configuration files or scriptstest
: adding or updating continuous integration tests