When filing new issues and commenting on existing issues on this repository, please ensure that discussions are related to concrete technical issues. For general questions and help, consult the [FAQ][stdlib-faq] and visit the [Gitter][stdlib-gitter] channel.

* Search for existing issues and pull requests.

* Try some debugging techniques to help isolate the problem, including logging inputs and outputs.

When filing an issue, provide the following, where possible:

Be aware that the `@` symbol tags users on GitHub, so __always__ surround package names with backticks (e.g., `@stdlib/utils/copy`).

* read and understand the [licensing terms][stdlib-license].

* read and understand the [style guides][stdlib-style-guides].

For instructions on how to setup and configure your environment, be sure to

Next, take a look around the project, noting the style and organization of documentation, tests, examples, benchmarks, and source implementations. Consistency is highly __prioritized__ within stdlib. Thus, the more you are able to match and adhere to project conventions and style, the more likely your contribution will be accepted. While we have done our best to automate linting and style guidelines, such automation is not perfect and cannot adequately capture the inevitable exceptions and nuance to many rules. In short, the more you study existing practice, the better prepared you will be to contribute to stdlib.

For modifications intended to be included in stdlib, create a new local branch.

``` bash

where `<branch>` is the branch name. Both the `master` and `develop` branches for the main stdlib project are protected, and direct modifications to these branches will __not__ be accepted. Instead, all contributions should be made on non-master and non-develop local branches, including documentation changes and other non-code modifications.

1. interleaved histories make [squashing][git-rewriting-history] commits more difficult

2. a standard merge increases the risk of incomplete/broken commits appearing in the git history.

An ideal commit history is one in which, at no point in time, is the project in a broken state. While not always possible (mistakes happen), striving for this ideal facilitates time travel and software archeology.

``` bash

$ make test

Note that each of the above tasks can take considerable time (>30 minutes per task).

Note that, once a [pull request][github-pull-request] has been made (i.e., your local repository commits have been pushed to a remote server), you should __not__ perform any further [rewriting][git-rewriting-history] of git history. If the history needs modification, a contributor will modify the history during the merge process. The rationale for __not__ rewriting public history is that doing so invalidates the commit history for anyone else who has pulled your changes, thus imposing additional burdens on collaborators to ensure that their local versions match the modified history.

Phew. While the above may be a lot to remember, even for what seem like minor changes, eventually it becomes routine and part of the normal development flow. Part of the motivation for enforcing process is to ensure that all code contributions meet a certain quality threshold, thus helping reviewers focus less on non-substantive issues like style and failing tests and more on substantive issues such as contribution content and merit. Know that your patience, hard work, time, and effort are greatly appreciated!

[github-pull-request]: https://help.github.com/articles/creating-a-pull-request/

[github-gist]: https://gist.github.com/

[github-markdown-guide]: https://guides.github.com/features/mastering-markdown/

[git-rebase]: https://git-scm.com/docs/git-rebase

[git-merge]: https://git-scm.com/docs/git-merge

[git-rewriting-history]: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History