|
| 1 | +# Contributing to the Fortran standard library |
| 2 | + |
| 3 | +Thank you for considering contributing to the Fortran standard library (*stdlib*). |
| 4 | +Please review and follow these guidelines to make the contribution process |
| 5 | +simple and effective for all involved. It will help communicate that you |
| 6 | +respect the time of the community developers. In return, the community will |
| 7 | +help address your problem, evaluate changes, and guide you through your pull |
| 8 | +requests. |
| 9 | + |
| 10 | +By contributing to *stdlib*, you certify that you own or are allowed to share the |
| 11 | +content of your contribution under the |
| 12 | +[stdlib license](https://github.com/fortran-lang/stdlib/blob/master/LICENSE). |
| 13 | + |
| 14 | +* [Style](#style) |
| 15 | +* [Reporting a bug](#reporting-a-bug) |
| 16 | +* [Suggesting a feature](#suggesting-a-feature) |
| 17 | +* [Workflow](#workflow) |
| 18 | +* [General guidelines](#general-guidelines) |
| 19 | +* [For new contributors](#for-new-contributors) |
| 20 | + |
| 21 | + |
| 22 | +## Style |
| 23 | + |
| 24 | +Please follow the |
| 25 | +[Fortran stdlib style guide](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) |
| 26 | +for any Fortran code that you contribute. |
| 27 | +This allows us to focus on substance rather than style. |
| 28 | + |
| 29 | +The style guide is a living document. |
| 30 | +You are welcome to propose changes to the style guide by |
| 31 | +[opening an issue](https://github.com/fortran-lang/stdlib/issues/new/choose) or |
| 32 | +[starting a discussion](https://github.com/fortran-lang/stdlib/discussions/new). |
| 33 | + |
| 34 | + |
| 35 | +## Reporting a bug |
| 36 | + |
| 37 | +A bug is a *demonstrable problem* caused by the code in this repository. |
| 38 | +Good bug reports are extremely valuable to us—thank you! |
| 39 | + |
| 40 | +Before opening a bug report: |
| 41 | + |
| 42 | +1. Check if the issue has already been reported |
| 43 | + ([issues](https://github.com/fortran-lang/stdlib/issues)). |
| 44 | +2. Check if it is still an issue or it has been fixed? |
| 45 | + Try to reproduce it with the latest version from the master branch. |
| 46 | +3. Isolate the problem and create a minimal test case. |
| 47 | + |
| 48 | +A good bug report should include all information needed to reproduce the bug. |
| 49 | +Please be as detailed as possible: |
| 50 | + |
| 51 | +1. Which version of *stdlib* are you using? |
| 52 | + What compiler version are you using? |
| 53 | + Which platform and architecture are on? |
| 54 | + Please be specific. |
| 55 | +2. What are the steps to reproduce the issue? |
| 56 | +3. What is the expected outcome? |
| 57 | +4. What happens instead? |
| 58 | + |
| 59 | +This information will help the community diagnose the issue quickly and with |
| 60 | +minimal back-and-forth. |
| 61 | + |
| 62 | + |
| 63 | +## Suggesting a feature |
| 64 | + |
| 65 | +Before suggesting a new feature, take a moment to find out if it fits the scope |
| 66 | +of the project, or if it has already been discussed. It is up to you to provide |
| 67 | +a strong argument to convince the community of the benefits of this feature. |
| 68 | +Please provide as much detail and context as possible. If applicable, include a |
| 69 | +mocked-up snippet of what the output or behavior would look like with this |
| 70 | +feature implemented. “Crazy,” out-of-the-box ideas are especially welcome. |
| 71 | +It’s quite possible that we are not considering an unusually creative solution. |
| 72 | + |
| 73 | + |
| 74 | +## Workflow |
| 75 | + |
| 76 | +The general workflow is documented in |
| 77 | +[this document](https://github.com/fortran-lang/stdlib/blob/master/WORKFLOW.md) |
| 78 | + |
| 79 | +The workflow guide is a living document. |
| 80 | +You are welcome to propose changes to the workflow by |
| 81 | +[opening an issue](https://github.com/fortran-lang/stdlib/issues/new/choose) or |
| 82 | +[starting a discussion](https://github.com/fortran-lang/stdlib/discussions/new). |
| 83 | + |
| 84 | + |
| 85 | +## General guidelines |
| 86 | + |
| 87 | +* A PR should implement *only one* feature or bug fix. |
| 88 | +* Do not commit changes to files that are irrelevant to your feature or bug fix. |
| 89 | +* Smaller PRs are better than large PRs, and will lead to a shorter review and |
| 90 | + merge cycle |
| 91 | +* Add tests for your feature or bug fix to be sure that it stays functional and useful |
| 92 | +* Be open to constructive criticism and requests for improving your code. |
| 93 | +* Again, please follow the |
| 94 | + [Fortran stdlib style guide](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md). |
| 95 | + |
| 96 | + |
| 97 | +## For new contributors |
| 98 | + |
| 99 | +If you have never created a pull request before, welcome :tada:. |
| 100 | +You can learn how from |
| 101 | +[this great tutorial](https://app.egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github). |
| 102 | + |
| 103 | +Don’t know where to start? |
| 104 | +You can start by looking through the list of |
| 105 | +[open issues](https://github.com/fortran-lang/stdlib/issues). |
0 commit comments