Thanks for taking the time to contribute! 🎉 We've established a set of community guidelines to enable as many people as possible to contribute to and benefit from HASH. Please follow these when interacting with this repo.
We have a community Discord server and support forum where you can ask questions about contributing, and where the community can chime in with helpful advice. If you'd like to make a significant change or re-architecture, please first discuss the change there (or create an issue) to get feedback before spending too much time.
This repository is HASH's public monorepo. It contains several different projects, some of which are open-source. Each project has its own license and contribution policies which may vary slightly.
To ascertain the license and contributor policy for a given project, check out the LICENSE.md and CONTRIBUTOR.md files in its root.
These apply across all projects:
- Before undertaking any significant work, please share your proposal with us: we don't want you to invest your time on changes we are already working on ourselves, or have different plans for. You can suggest changes as a discussion if it's a feature proposal, or an issue if it's a bug you intend to fix. If you're unsure, you can always chat to us on Discord first. If it's a typo or docs change, don't worry about this step.
- When submitting a pull request, please fill out any sections of the provided template you feel able to. If you are unsure or don't feel a section is relevant, please say so.
- Always include a link to the issue or discussion proposing the change.
- Write tests to accompany your PR, or ask for help/guidance if this is a blocker.
- Make sure that your PR doesn’t break existing tests.
- Once you have receive a pull request review, please bear the following in mind:
- reviewers may make suggestions for optional changes which are not required to get your code merged. It should be obvious which suggestions are optional, and which are required changes. If it is not obvious, ask for clarification.
- please do not resolve comment threads unless you opened them - leave it to the person who raised a comment to decide if any further discussion is required (GitHub will also automatically resolve any code suggestions you click 'commit' on). Comment threads may also be left open so that they can be linked to later.
Issue tags can provide a good source of inspiration for would-be contributors. See: “help wanted” and “good for first-time contributors”. You should also feel free to join our HASH Discord and reach out directly to us for more inspiration. If you're willing to contribute, we'd love to have you!
There are a number of reasons why otherwise sound contributions might not find their way into the main branch of our repo. Ultimately, we reserve the right to reject PRs for any reason. In a bid to minimize wasted time and effort, here are some possible reasons for rejection:
- PRs that introduce new functionality without proper tests will not be accepted. You should write meaningful tests for your code.
- PRs that fail to pass tests will not be merged. If your PR doesn’t pass our Continuous Integration tests, it won’t be merged.
- PRs that duplicate functionality which already exist in HASH, but outside of the project you're introducing them in. For example, recreating functionality provided in one package directly within another.
- PRs that duplicate workstreams already under development at HASH may be rejected, or alternatively integrated into working branches other than those intended by the contributor. For more on these, see our public roadmap.
- PRs that add functionality that is only useful to a subset of users, which may increase maintenance overheads on the product. We know it can be frustrating when these sorts of PRs are rejected, and it can sometimes seem arbitrary. We’ll do our best to communicate our rationale clearly in such instances and are happy to talk it out. It's impossible to forecast all of the possible use-cases of a product or feature, and we try to keep an open posture towards such contributions.
- PRs that introduce architectural changes to the project (without prior discussion and agreement) will be rejected.
- PRs that don’t match the syntax, style and formatting of the project will be rejected. See: maintainability.
We're recruiting for a number of full-time roles. If you've already contributed to the open-source hash repo, mention this in your application. View our open roles at hash.ai/careers and drop your name in the General Pool even if you'd be happy to work on HASH, but can't see a good fit right now.