Contributing to DeePTB#
We heartily welcome contributions to the DeePTB project. This guide provides technical and non-technical guidelines to help you contribute effectively.
Table of Contents#
Got a question?#
For questions and discussions about DeePTB, use our GitHub Discussions. If you find a bug or want to propose a new feature, please use the issue tracker.
Project Structure#
DeePTB is organized into several modules. Here’s a brief overview:
data
: Data processing module.entrypoints
: Entry points for the command-line interface.negf
: Nonequilibrium Green’s Function (NEGF) module.nn
: Neural network model module.nnops
: Neural network operations module.plugins
: Plugins for various functionalities.postprocess
: Post-processing module.tests
: Unit tests for DeePTB.utils
: Utility module with tools and constants.
Submitting an Issue#
Before you submit an issue, please search the issue tracker, and maybe your problem has been discussed and fixed. You can submit new issues by filling our issue forms. To help us reproduce and confirm a bug, please provide a test case and building environment in your issue.
Code Formatting Style#
Adhere to the PEP 8 style guide for Python code. For other languages, follow their respective community standards.
Adding a Unit Test#
When contributing a new feature or fixing a bug, it’s important to include tests to ensure the code works as expected and to prevent future regressions.
Locate the appropriate test file in the
tests
directory, usingpytest
for Python tests.Write your test case, following the existing structure and style.
Running Unit Tests#
To run all unit tests, use the following command in the project root directory:
pytest ./dptb/tests
To run a specific test, use:
pytest ./dptb/tests/test_file.py
Submitting a Pull Request#
Fork the DeePTB repository. If you already had an existing fork, sync the fork to keep your modification up-to-date.
Create a new branch for your changes.
git checkout -b my-fix-branch
Make your changes, including tests and documentation updates.
Commit your changes with a proper commit message.
Push your branch to your fork on GitHub.
Submit a pull request (PR) with
deepmodeling/DeePTB:main
as the base repository. It is required to document your PR following our guidelines.
After Your Pull Request is Merged#
Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
git push origin --delete my-fix-branch
Check out the master branch:
git checkout develop -f
Delete the local branch:
git branch -D my-fix-branch
Update your master with the latest upstream version:
git pull --ff upstream develop
Commit Message Guidelines#
A well-formatted commit message leads a more readable history when we look through some changes, and helps us generate change log.
We follow the Conventional Commits specification for commit messages:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Example:
Fix(data): handle missing data gracefully
When a required data file is missing, the program now displays a user-friendly error message and exits.
Fixes #123
Header
type: The general intention of this commit
Feature
: A new featureFix
: A bug fixDocs
: Only documentation changesStyle
: Changes that do not affect the meaning of the codeRefactor
: A code change that neither fixes a bug nor adds a featurePerf
: A code change that improves performanceTest
: Adding missing tests or correcting existing testsBuild
: Changes that affect the build system or external dependenciesCI
: Changes to our CI configuration files and scriptsRevert
: Reverting commits
scope: optional, could be the module which this commit changes; for example,
orbital
description: A short summary of the code changes: tell others what you did in one sentence.
Body: optional, providing detailed, additional, or contextual information about the code changes, e.g. the motivation of this commit, referenced materials, the coding implementation, and so on.
Footer: optional, reference GitHub issues or PRs that this commit closes or is related to. Use a keyword to close an issue, e.g. “Fix #753”.
Comment Style for Documentation#
We encourage you to add comments to your code, especially for complex logic or decisions. Use clear, concise language and reference any related issues or discussions.