You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/contributing.md
+31-10Lines changed: 31 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,23 +5,44 @@ Below are the specifics about our contributing process.
5
5
If you are entirely new to contributing to open source, [this generic guide](https://opensource.guide/how-to-contribute/) also helps explain why, what, and how to successfully get involved in open source projects.
6
6
7
7
## Workflow
8
-
- Create a fork of the Delft3D repository, or request write-access to our Delft3D repository via Delft3D support.
9
-
- Create a JIRA issue ticket at https://issuetracker.deltares.nl describing the bug to be fixed or functionality to be developed.
10
-
The issue number is relevant for naming the development branch (see below).
11
-
Third party developers don't have access to the issue tracker; we recommend to communicate with a Deltares contact person.
8
+
### External contributors
9
+
- Create a fork of the Delft3D repository.
10
+
- Reach out to Deltares as early as possible if you intend to contribute changes back to the main Delft3D version.
11
+
This helps us with keeping track of what developments are ongoing.
12
+
This helps avoid starting work on something that other people are already implementing, and we can give guidance on how best to implement the intended changes.
13
+
Reach out to us via the **sales services team:**https://www.deltares.nl/en/software-and-data/software-sales-and-support-teams with a brief description of the scope of the code change; they will forward your request internally to the appropriate development team.
14
+
- Checkout/Clone the repository locally.
15
+
- Create a branch, ideally using the naming convention below.
16
+
The frequency of updating your fork/branch from the Deltares main is up to personal taste.
17
+
Yet, merge from our main as often as possible, and contribute back to us as early as possible.
18
+
- Implement, test and document the modifications.
19
+
- Provide a patch-file, or reach out to Deltares to create a pull request:
20
+
- Although anyone can create a pull request on our repository, our pipelines will only be triggered if the pull request is created by a Deltares employee.
21
+
- Merging back to our main will typically include the following steps: transfer code changes to a branch in our Delft3D repository, security scan of the changes made, creation of a pull request, review of code, documentation and test cases, and automated code testing.
22
+
Obviously, with some iterations if one of the steps identifies issues to be resolved before the merge.
23
+
- To keep legal representation of the Delft3D software indisputable, we ask you to sign a Fiduciary License Agreement (FLA) before the final merge into main.
24
+
For an explanation why, see [this page](https://fsfe.org/activities/fla/fla.en.html) by the Free Software Foundation Europe.
25
+
The FLA can be obtained via the Deltares contact person who handles the merging process.
26
+
Signing the FLA makes sense for code contributions of significant size.
27
+
For small bug fixes, it's better to send an email with a test case and a description of the recommended code changes than following the formal procedure described above.
28
+
29
+
### Deltares employees
12
30
- Checkout/Clone the repository locally.
31
+
- Create a JIRA issue ticket at https://issuetracker.deltares.nl describing the bug to be fixed or functionality to be developed.
32
+
The issue number is required for naming the development branch (see below).
13
33
- Create a branch using the naming convention below.
14
-
If no issue number is available, create a research branch starting with `research/`.
15
34
The frequency of updating your branch from main is up to personal taste.
16
35
Yet, merge from main as often as possible, and merge back to main as early as possible.
17
-
- Make and test the modifications.
18
-
- Provide a patch-file, or create a pull request:
19
-
- Our Continuous Integration pipelines will only be triggered if the pull request is created by a Deltares contact person.
36
+
- Implement, test and document the modifications.
37
+
In case of changes by external contributors, this step will include pulling the changes from the external repository into the local branch and at least a security scan of the changes made by the external contributor.
38
+
- Create a pull request:
39
+
- Our Continuous Integration pipelines will be triggered automatically by a pull request created by Deltares employees.
20
40
These pipelines consist of (Deltares-internal) TeamCity projects to build the source code (Windows and Linux) and subsequently a set of model simulation testbenches.
21
41
A merge is only possible when all checks succeed.
22
42
The projects will take at least 30 minutes to complete.
23
-
- You have to assign the Pull request to a core developer for reviewing and testing. When succeeded, the tester/reviewer is allowed to merge into main.
24
-
- Official binary deliveries are only allowed using Deltares TeamCity server
43
+
- You have to assign the pull request to a core developer for review.
44
+
If review and all tests pass, the tester/reviewer is allowed to merge into main (signed Fiduciary License Agreement required in case of external contributor).
45
+
- Official binary deliveries are only allowed using the Deltares TeamCity server.
25
46
26
47
## Branch naming
27
48
For each issue or feature, a separate branch should be created from the main.
0 commit comments