Added new OS type checks.

1 files changed, 126 insertions, 0 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..1332278
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,126 @@
+# Contributing to the Fortran Package Manager
+
+Thank you for considering contributing to the Fortran Package Manager (fpm).
+Please review and follow these guidelines to make the contribution process
+simple and effective for all involved.
+It will help communicate that you respect the time of the community
+developers.
+In return, the community will help address your problem, evaluate changes, and
+guide you through your pull requests.
+
+By contributing to fpm, you certify that you own or are allowed to share the
+content of your contribution under the
+[fpm license](https://github.com/fortran-lang/fpm/blob/master/LICENSE).
+
+* [Style](#style)
+* [Reporting a bug](#reporting-a-bug)
+* [Suggesting a feature](#suggesting-a-feature)
+* [Workflow](#workflow)
+* [General guidelines](#general-guidelines)
+* [For new contributors](#for-new-contributors)
+
+## Style
+
+Please follow the
+[Fortran stdlib style guide](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md)
+for any Fortran code that you contribute.
+This allows us to focus on substance rather than style.
+
+## Reporting a bug
+
+A bug is a _demonstrable problem_ caused by the code in this repository.
+Good bug reports are extremely valuable to us—thank you!
+
+Before opening a bug report:
+
+1. Check if the issue has already been reported.
+   ([issues](https://github.com/fortran-lang/fpm/issues))
+2. Check if it is still an issue or it has been fixed?
+   Try to reproduce it with the latest version from the master branch.
+3. Isolate the problem and create a minimal test case.
+
+A good bug report should include all information needed to reproduce the bug.
+Please be as detailed as possible:
+
+1. Which version of fpm are you using? Please be specific.
+2. What are the steps to reproduce the issue?
+3. What is the expected outcome?
+4. What happens instead?
+
+This information will help the community diagnose the issue quickly and with
+minimal back-and-forth.
+
+## Suggesting a feature
+
+Before suggesting a new feature, take a moment to find out if it fits
+the scope of the project, or if it has already been discussed.
+It is up to you to provide a strong argument to convince the community of the
+benefits of this feature.
+Please provide as much detail and context as possible.
+If applicable, include a mocked-up snippet of what the output or behavior would
+look like with this feature implemented.
+"Crazy", out-of-the-box ideas are especially welcome.
+It's quite possible that we are not considering an unusually creative solution.
+
+## Workflow
+
+fpm is a community project.
+There is no one single person making final decisions.
+This is the workflow that we follow:
+
+1. Open a [new issue](https://github.com/fortran-lang/fpm/issues/new) to
+   describe a bug or propose a new feature.
+   Refer to the earlier sections on how to write a good bug report or feature
+   request.
+2. Discuss with the community and reach majority consensus about what should be
+   done about the bug or feature request.
+   We define "majority" loosely as 80%.
+   This means that at least 4 of 5 people engaged in the discussion should be
+   able to agree on the next step.
+   This allows us to have the community mostly agree while not getting stuck if
+   one person disagrees.
+   At this stage, the scope of the fix/feature, its behavior, and API if
+   applicable should be defined.
+   Only when you have community concensus on these items you should proceed
+   to writing code and opening a PR.
+   __When actively working on code towards a PR, please assign yourself to the issue on github.__
+   This is good collaborative practice to avoid duplicated effort and also inform others what you 
+   are currently working on.
+3. Open a new Pull Request (PR) with your contribution.
+   The body of the PR should at least include a bullet-point summary of the
+   changes, and a detailed description is encouraged.
+   If the PR completely addresses the issue you opened in step 1, include in
+   the PR description the following line: `Fixes #<issue-number>`.
+4. Request reviewers to your PR.
+   For small bug fixes or documentation improvements, 1 to 2 reviewers is
+   sufficient.
+   For implementation of bigger features, request 3 to 4 or more reviewers.
+   Ideally, request reviewers that participated in step 2.
+5. If your PR implements a feature that adds or changes the behavior of fpm,
+   your PR must also include appropriate changes to the documentation.
+
+This workflow can evolve and change over time as we learn how best to work
+together.
+If you have an idea on how to improve the workflow itself, please open an issue
+and we'll discuss it.
+
+## General guidelines
+
+* A PR should implement _only one_ feature or bug fix.
+* Do not commit changes to files that are irrelevant to your feature or bug fix.
+* Smaller PRs are better than large PRs, and will lead to a shorter review and
+  merge cycle
+* Add tests for your feature or bug fix to be sure that it stays functional and useful
+* Be open to constructive criticism and requests for improving your code.
+* Again, please follow the
+  [Fortran stdlib style guide](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md).
+
+## For New Contributors
+
+If you have never created a pull request before, welcome :tada:.
+You can learn how from
+[this great tutorial](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github).
+
+Don't know where to start?
+You can start by looking through the list of
+[open issues](https://github.com/fortran-lang/fpm/issues).