We welcome new contributors to this project to help make the Ising_OPV morphology tool better and more effective for our scientific and educational users. Contributions can take on a variety of forms, such as bug reports, feature requests, code documentation updates, user tutorials, feature implementations, bugfixes, and more.
- To maintain an inclusive and welcoming environment, all community members must follow the Code of Conduct.
- To keep project development organized, all new features and bugfixes must be proposed and discussed using issues before changes are implemented.
- C++ code should follow the C++11 standard and should be written to be simple and largely self-documenting with self-descriptive names.
One of the easiest ways to contribute is by using the software and submitting bug reports and feature requests as issues in the Issues section. Before filing a new issue please check that your issue has not already been submitted. If it has, 'like' the issue and add any additional feedback you have to the issue thread in a comment. If your issue has not already been filed, create a new issue and provide a detailed description of the problem or new idea/suggestion. The code owners will review new issues, provide feedback, and decide if and when to implement the changes needed to resolve the issue.
-
Before you set out to tackle an issue, discuss your implementation plans with the code owners on the issue page.
Especially for code additions needed to add new features, it is important to discuss your implementation ideas with the code owners to ensure that the software design is relatively well thought out and fits with the rest of the codebase.
-
Create fork of the KMC_Lattice repo on your account.
Click the "Fork" button near the top of any KMC_Lattice Github webpage.
-
Connect your fork to the upstream repo
git remote add upstream https://github.com/MikeHeiber/KMC_Lattice.git -
Clone your forked KMC_Lattice repo to your local machine.
git clone --recurse-submodules https://github.com/YOUR_USERNAME/KMC_Lattice -
Create a new feature branch from the development branch.
git checkout development git branch feature-new-thing git checkout feature-new-thing -
Implement your changes keeping the scope of changes limited to the specified issue.
-
Document your changes by adding to the Changelog.
-
Update your new branch with any upstream changes and resolve any conflicts.
git fetch upstream git checkout development git merge upstream/development git checkout feature-new-thing git rebase development -
Make sure your changes do not break any of the existing functionality by running the tests locally.
make test ./test/KMC_Lattice_tests.exe mpiexec -n 4 ./test/KMC_Lattice_MPI_tests.exe -
Push your local changes to your forked KMC_Lattice repo.
git push origin feature-new-thing -
Submit a pull request
See below for details about how to submit a pull request.
Unit tests using the googletest framework must be created for all new/modified functions and added to the test/test.cpp or test/test_mpi.cpp file as appropriate. Tests should include comments that describe what functionality each test code section is testing for.
All new/modified classes and functions must be documented using the Doxygen style.
The pull request must reference the issue that is being resolved. Merging of feature branches into the development branch will be done using a squash merge operation to keep a tidy Git history. The squash merge will be done by a code owner, so you must provide a single overall commit message that details all changes in the pull request body text for the code owner the use with the merge. The pull request version of the code must pass all TravisCI tests and must not reduce code testing coverage on Coveralls. Code will be formatted during the code review stage to the Microsoft Visual Studio 2017 standard format. Updated documentation files will also be generated by Doxygen during the code review stage as needed. Code owners may add new commits to your pull request branch in order to help you fix any problems.