@@ -4,7 +4,7 @@ Thank you for considering contributing to the Fortran standard library (*stdlib*
4
4
Please review and follow these guidelines to make the contribution process
5
5
simple and effective for all involved. It will help communicate that you
6
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
7
+ help to address your problem, evaluate changes, and guide you through your pull
8
8
requests.
9
9
10
10
By contributing to * stdlib* , you certify that you own or are allowed to share the
@@ -24,7 +24,7 @@ content of your contribution under the
24
24
Please follow the
25
25
[ Fortran stdlib style guide] ( https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md )
26
26
for any Fortran code that you contribute.
27
- This allows us to focus on substance rather than style.
27
+ This allows the community to focus on substance rather than style.
28
28
29
29
The style guide is a living document.
30
30
You are welcome to propose changes to the style guide by
@@ -35,7 +35,7 @@ You are welcome to propose changes to the style guide by
35
35
## Reporting a bug
36
36
37
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!
38
+ Good bug reports are extremely valuable to the community —thank you!
39
39
40
40
Before opening a bug report:
41
41
@@ -49,14 +49,14 @@ A good bug report should include all information needed to reproduce the bug.
49
49
Please be as detailed as possible:
50
50
51
51
1 . Which version of * stdlib* are you using?
52
- What compiler version are you using?
53
- Which platform and architecture are on?
52
+ Which compiler version are you using?
53
+ Which platform and architecture are you on?
54
54
Please be specific.
55
55
2 . What are the steps to reproduce the issue?
56
56
3 . What is the expected outcome?
57
57
4 . What happens instead?
58
58
59
- This information will help the community diagnose the issue quickly and with
59
+ This information will help the community to diagnose the issue quickly and with
60
60
minimal back-and-forth.
61
61
62
62
@@ -65,7 +65,7 @@ minimal back-and-forth.
65
65
Before suggesting a new feature, take a moment to find out if it fits the scope
66
66
of the project, or if it has already been discussed. It is up to you to provide
67
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
68
+ Please provide as much details and context as possible. If applicable, include a
69
69
mocked-up snippet of what the output or behavior would look like with this
70
70
feature implemented. “Crazy,” out-of-the-box ideas are especially welcome.
71
71
It’s quite possible that we are not considering an unusually creative solution.
@@ -87,8 +87,8 @@ You are welcome to propose changes to the workflow by
87
87
* A PR should implement * only one* feature or bug fix.
88
88
* Do not commit changes to files that are irrelevant to your feature or bug fix.
89
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
90
+ merge cycle.
91
+ * Add tests for your feature or bug fix to be sure that it stays functional and useful.
92
92
* Be open to constructive criticism and requests for improving your code.
93
93
* Again, please follow the
94
94
[ Fortran stdlib style guide] ( https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md ) .
0 commit comments