Thanks for your interest in contributing to ResearchTown! We welcome and appreciate contributions.
There are many ways that you can contribute:
- Download and use ResearchTown, and send issues when you encounter something that isn't working or a feature that you'd like to see.
- Improve the Codebase by sending PRs (see details below). In particular, we have some good first issue issues that may be ones to start on.
ResearchTown is an open-source package that is released on pypi
.
When you write code, it is also good to write tests. Please navigate to the tests
folder to see existing test suites. These tests also run on github's continuous integration to ensure quality of the project.
Fork the Research Town repository into your own account. Clone your own forked repository into your local environment:
git clone [email protected]:<YOUR-USERNAME>/research-town.git
Set the official repository as your upstream to synchronize with the latest update in the official repository. Add the original repository as upstream:
cd research-town
git remote add upstream [email protected]:ulab-uiuc/research-town.git
Verify that the remote is set:
git remote -v
You should see both origin
and upstream
in the output.
Synchronize latest commit with official repository before coding:
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
Use poetry install
to set up the development environment.
Once you have done this, you can write code, test it, and commit it to a branch (replace my_branch
with an appropriate name):
git checkout -b my_branch
git add .
git commit
git push origin my_branch
- On Github, go to the page of your forked repository, and create a Pull Request:
- Click on
Branches
- Click on the
...
beside your branch and click onNew pull request
- Set
base repository
toulab-uiuc/research-town
- Set
base
tomain
- Click
Create pull request
- Click on
The PR should appear in Research Town PRs.
Then the Research Town team will review your code.
As described here, a valid PR title should begin with one of the following prefixes:
feat
: A new featurefix
: A bug fixdocs
: Documentation only changesstyle
: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)refactor
: 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 dependencies (example scopes: gulp, broccoli, npm)ci
: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)chore
: Other changes that don't modify src or test filesrevert
: Reverts a previous commit
For example, a PR title could be:
refactor: modify package path
feat(frontend): xxxx
, where(frontend)
means that this PR mainly focuses on the frontend component.
You may also check out previous PRs in the PR list.
As described here, we have created several labels. Every PR should be tagged with the corresponding labels.
- If your PR is small (such as a typo fix), you can go brief.
- If it contains a lot of changes, it's better to write more details.