Skip to main content

Contribute

Thanks for your interest in contributing to Pooldash! 🎉

Creating an Issue​

  • If you have a question about using Pooldash, please ask on the Pooldash forum

  • You should aim to clearly describe the steps necessary to reproduce the issue you are running into. Although we would love to help our users as much as possible, trying to diagnose issues without clear steps on how to reproduce them is time consuming and

  • The issue list of a repository is exclusively for bug reports and feature requests. If you have questions that relate to pool maintenance or general questions, please ask on this forum. Although feel free to ask for feature requests and bug fixes on the forum as well.

  • If you think you have found a bug, or have a new feature idea, please start by making sure it hasn't already been reported. You can search through existing issues to see if there is a similar one reported. Include closed issues as it may have been closed with a solution.

  • Next, find the pooldash repository your issue is addressing here. Create a new issue that thoroughly explains the problem. Please fill out the populated issue form before submitting the issue.

Creating a Good Code Reproduction​

What is a Code Reproduction?​

A code reproduction is a small application that is built to demonstrate a particular issue. The code reproduction should contain the minimum amount of code needed to recreate the issue and should focus on a single issue.

Why Should You Create a Reproduction?​

A code reproduction of the issue you are experiencing helps us better isolate the cause of the problem. This is an important first step to getting any bug fixed!

Without a reliable code reproduction, it can be much harder to solve the issue, leading to it being closed. In other words, creating a code reproduction of the issue helps us help you.

How to Create a Reproduction​

  • Create a branch off of the latest master branch of the repository your issue is addressing.
  • Add the minimum amount of code needed to recreate the issue you are experiencing. Do not include anything that is not required to reproduce the issue. This includes any 3rd party plugins you have installed.
  • Publish the application on GitHub and include a link to it when creating an issue.
  • Be sure to include steps to reproduce the issue. These steps should be clear and easy to follow.

Creating a Pull Request​

Before creating a pull request, please read our requirements that explains the minimal details to have your PR considered and merged into the codebase.

Requirements​

  1. PRs must reference an existing issue that describes the issue or feature being submitted.
  2. PRs must have a reproduction app or the issue must include a reproduction app to verify changes against.
  3. PRs must include tests covering the changed behavior or a description of why tests cannot be written.

Note: We appreciate you taking the time to contribute! Before submitting a pull request, please take the time to comment on the issue you are wanting to resolve. This helps us prevent duplicate effort or advise if the team is already addressing the issue.

  • Looking for an issue to fix? Look through issues on the repo you want to contribute to. If you find an issue you would like to fix, please comment on the issue to let us know you are working on it. This helps us prevent duplicate effort and helps us advise if the team is already addressing the issue.

Setup​

  1. Follow the environment setup instructions in this guide.
  2. Fork a repository from here.
  3. Clone your fork.
  4. Create a new branch from master for your change.
  5. Make your changes and then submit a pull request.

Submit Pull Request​

  1. Create a new pull request from one of repositories here with the master branch as the base. You may need to click on compare across forks to find your changes.
  2. See the Creating a pull request from a fork GitHub help article for more information.
  3. Please fill out the provided Pull Request template to the best of your ability and include any issues that are related.

To help expedite the process make sure your pull request has an issue attached. If you are submitting a new feature, please make sure to include some sort of a design proposal in the issue. This will help the team understand the problem you are trying to solve and how you are trying to solve it.

Scope​

The scope can be anything specifying place of the commit change. Usually it will refer to a component but it can also refer to a utility. For example action-sheet, button, css, menu, nav, etc. If you make multiple commits for the same component, please keep the naming of this component consistent. For example, if you make a change to navigation and the first commit is fix(nav), you should continue to use nav for any more commits related to navigation. As a general rule, if you're modifying a component use the name of the folder.

Subject​

The subject contains succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • entire length of the commit message must not go over 50 characters
  • describe what the commit does, not what issue it relates to or fixes
  • be brief, yet descriptive - we should have a good understanding of what the commit does by reading the subject.

Body​

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

License​