1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
# Contributing to the Fortran Package Manager
First off, thank you for considering contributing to the Fortran Package Manager (fpm).
Please take a moment to review this guidelines to make the contribution process simple and effective for all involved.
Respecting these guidelines helps communicate that you respect the time of the developers who manage and develop this open source project.
In return, they should return this respect by addressing your problem, evaluating changes, and helping you handle your pull requests.
We encourage and enforce high quality code.
Generally, follow the
[style guide of the Fortran stdlib](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md)
for any contributed Fortran code.
This allows code review discussions to focus on semantics and substance rather than pedantry.
## Reporting a Bug
A bug is a _demonstratable problem_ caused by the code in this repository.
Good bug reports are extremely valuable for us - thank you!
Before opening a bug report:
1. Check if the issue has already been reported.
2. Check if it still is an issue or has already been fixed?
Try to reproduce it with the latest version from the default branch.
3. Isolate the problem and create a reduced test case.
A good bug report should not leave others needing to chase you up for more information.
So please try to be as detailed as possible in your report, answer at least these questions:
1. Which version of fpm are you using?
The current version is always a subject to change, so be more specific.
2. What steps will reproduce the issue?
We have to reproduce the issue, so we need all the input files.
3. What would be the expected outcome?
4. What did you see instead?
All these details will help people to fix any potential bugs.
## Suggesting a New Feature
Feature requests are welcome.
But take a moment to find out if your idea fits the scope and goals of the project.
It is up to you to provide a strong argument to convince the project's developers of the benefits of this feature.
Please provide as much detail and context as possible.
## Implementing a New Feature
Contributions are welcome via GitHub pull requests.
But suggest a new feature in an issue first to discuss the scope of the necessary changes or the required functionality before submitting a pull request.
You can always choose from one of the
[existing issues](https://github.com/fortran-lang/fpm/issues).
- Each pull request should implement _one_ feature or fix _one_ bug.
If you want to add or fix more than one thing, submit more than one pull request.
- Do not commit changes to files that are irrelevant to your feature or bugfix (_e.g._ `.gitignore`).
- Add tests for your new features or fixed bugs such that we can ensure that they stay functional and useful
- Be willing to accept criticism and work on improving your code.
Have one to three maintainers review your contribution.
- Generally, follow the [style guide of the Fortran stdlib](https://github.com/fortran-lang/stdlib/blob/master/STYLE_GUIDE.md) for any contributed Fortran code.
### For New Contributors
If you 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 these
[help-wanted issues](https://github.com/fortran-lang/fpm/issues?q=label%3A%22help+wanted%22+is%3Aissue+is%3Aopen).
## Sign Your Work
The sign-off is a simple line at the end of the explanation for a commit.
All commits needs to be signed.
Your signature certifies that you wrote the patch or otherwise have the right to contribute the material.
The rules are pretty simple, if you can certify the below
(from [developercertificate.org](https://developercertificate.org/)):
```
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
```
Then you just add a line to every git commit message:
```
Signed-off-by: Joe Smith <joe.smith@example.com>
```
Use your real name (sorry, no pseudonyms or anonymous contributions.)
If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`.
|
