Thanks for taking the time to contribute!
This project is simpler than most, so it’s a good place to start contributing to the open source community, even if you’re a newbie.
We are accepting these sorts of changes and requests:
- Bug reports and fixes
- Usability improvements
- Documentation updates
- New reputable “by the book” indicators and overlays
We are not accepting things that should be done in your own wrapper code:
- Personal customizations and preferences
- Modified or augmented outputs that are not intrinsic
Reporting bugs and feature requests
We have different places to take issues by its category.
If you are reporting a bug or suspect a problem, please submit an issue with a detailed description of the problem + include steps to reproduce, code samples, and any reference materials.
For new features, submit an issue with the
- Planned work is managed in the backlog.
- Work items are primarily entered as Notes (not Issues), except where an issue or feature is user reported. With that said, Notes can be converted to Issues if in-progress and collaborative discussion is needed.
- Use the Discussions area for general ideation and unrelated questions.
- Read this first: A Step by Step Guide to Making Your First GitHub Contribution. I also have a discussion on Forking if you have questions.
- If you are adding a new indicator, the easiest way to do this is to copy the folder of an existing indicator and rename everything using the same naming conventions and taxonomy. All new indicators should include unit and performance tests.
- Do not commingle multiple contributions. Please keep changes small and separate.
- We use pytest for testing.
- Review the
testsfolder for examples of unit tests. Just copy one of these.
- New indicators should be tested against manually calculated, proven, accurate results. It is helpful to include your manual calculations spreadsheet in the appropriate indicator folder when submitting changes.
- Historical Stock Quotes are automatically added as pytest fixtures. A
History.xlsxExcel file is included in the
samplesfolder that is an exact copy of what is used in the unit tests. Use this for your manual calculations to ensure that it is correct. Do not commit changes to this Excel file.
- We expect all unit tests to execute successfully and all Errors and Warning resolved before you submit your code.
- Failed builds or unit testing will block acceptance of your Pull Request when submitting changes.
# install core dependencies pip install -r requirements.txt # install test dependencies pip install -r requirements-test.txt # run all tests. pytest -svr A tests
Running the commands below in your console will show performance data. You can find the latest results here.
# install pytest and other dependencies. pip install -r requirements-test.txt pip install pytest-benchmark # run benchmarks. pytest benchmarks
This site uses GitHub Pages and Jekyll construction with Front Matter.
The documentation site is in the
docs folder. Build the site locally to test that it works properly.
See GitHub Pages documentation for initial setup instructions.
bundle install bundle exec jekyll serve # then open site on http://127.0.0.1:4000
When adding or updating indicators:
- Add or update the indicator documentation
- Page image assets go in the
By submitting changes to this repo you are also acknowledging and agree to the terms in both the Developer Certificate of Origin (DCO) 1.1 and the Apache 2.0 license. These are standard open-source terms and conditions.
When ready, submit a Pull Request with a clear list of what you’ve done (read more about pull requests). Always write a clear log message for your commits. One-line messages are fine for most changes.
After a Pull Request is reviewed, accepted, and [squash] merged to
main, we may batch changes before publishing a new package version to PyPI. Please be patient with turnaround time.
Code reviews and administration
If you want to contribute administratively, do code reviews, or provide general user support, we’re also currently seeking a few core people to help. Please contact us if interested.
Standards and design guidelines
- PEP 8 – Style Guide for Python Code
- PEP 440 – Version Identification and Dependency Specification
- Semantic Version 2.0
- Python Packaging User Guide
We use the
GitVersion tool for semantic versioning. It is mostly auto generated in the Azure DevOps build.
||A significant deviation with major breaking changes.|
||A new feature, usually new non-breaking change, such as adding an indicator. Minor breaking changes may occur here and are denoted in the release notes.|
||A small bug fix, chore, or documentation change.|
||Intermediate commits between releases.|
This only needs to be done on the merge to
main when the Pull Request is committed, so your feature branch does not need to include this as it will get squashed anyway.
+semver: majoras a PR merge commit message will increment the major x.-.- element
+semver: minoras a PR merge commit message will increment the minor -.x.- element
+semver: patchas a PR merge commit message will increment the minor -.-.x element. Patch element auto-increments, so you’d only need to do this to override the next value.
tag, in accordance with the above schema, is introduced automatically after deploying to PyPI and is reflected in the Releases.
This repository uses a standard Apache 2.0 open-source license. It enables open-source community development by protecting the project and contributors from certain legal risks while allowing the widest range of uses, including in closed source software. Please review the license before using or contributing to the software.
Start a new discussion, ask a question, or submit an issue if it is publicly relevant. You can also direct message @daveskender.
Thanks, Dave Skender