Thank you for your interest in contributing to HyperTools 🎉!
HyperTools is designed to facilitate dimensionality reduction-based visual explorations of high-dimensional data. The basic pipeline is to feed in a high-dimensional dataset (or a series of high-dimensional datasets) and, in a single function call, reduce the dimensionality of the dataset(s) and create a plot. The package is built atop many familiar friends, including matplotlib, scikit-learn and seaborn.
This document is a set of guidelines for contributing to HyperTools on GitHub. These are guidelines, not rules. This guide is meant to make it easy for you to get involved. Before contributing, it is important to read over this page because it will help you understand the problem that this toolbox tries to solve, our future vision for the project, and what kinds of contributions (we think) would be most useful.
- Participation guidelines
- What we're working on
- How to submit changes
- Merging pull requests (maintainers)
- How to report bugs
- Communication channels
This project adheres to a code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to contextualdynamics@gmail.com.
Take a look at the open issues in our issue tracker -- it doubles as the project roadmap, and issues are labeled by topic and estimated effort. If you'd like to work on one, leave a comment on the issue so we can coordinate.
Once you've identified one of the issues above that you feel you can contribute to, you're ready to make a change to the project repository!
- Fork this repository. This makes your own version of this project you can edit and use.
- Make your changes! You can do this in the GitHub interface or on your own local machine. Once you're happy with your changes...
- Submit a pull request. This opens a discussion around your project and lets the project lead know you are proposing changes. Please run the test suite (
pytest, from the repository root) before opening a pull request, and add tests covering any new functionality or bug fixes.
First time contributing to open source? Check out the free guide, How to Contribute to Open Source.
Squash-merge any pull request whose branch history contains large or
generated binaries -- most importantly the long-lived 1.0 development
branches (dev-1.0-refactor -> dev-1.0 -> master). Earlier commits on
those branches carried large generated artifacts (rendered documentation
galleries, audit evidence, example-dataset payloads) that were later removed
from the working tree. Those blobs still live in the branch's commit
history: a normal merge copies that entire history -- and every large blob
in it -- into the target branch permanently, inflating clone and fetch size
for everyone (the packed history is well over 1 GB even though the current
tree is ~115 MB). Squash-merging brings only the final tree into the target
branch, so the removed binaries never enter its permanent history.
Do not rewrite already-published history (e.g. filter-repo/force-push)
to shrink it -- that breaks every existing clone and open PR. Squash-merge is
the supported way to keep the target branch small without rewriting history.
After a squash-merge, the source branch (with its heavy history) can be
deleted.
If you are reporting a bug, please submit it to our issue tracker. Please do your best to include the following:
- A short, top-level summary of the bug. In most cases, this should be 1-2 sentences.
- A short, self-contained code snippet to reproduce the bug, ideally allowing a simple copy and paste to reproduce. Please do your best to reduce the code snippet to the minimum required.
- The actual outcome of the code snippet
- The expected outcome of the code snippet
Have questions? Want to join in on the discussion? Open an issue in our issue tracker -- we use it for questions and design discussions as well as bug reports.