Skip to content

Commit fbe1f42

Browse files
committed
#224 - Switched to Asciidoctor for CONTRIBUTING document.
1 parent 6bbbd94 commit fbe1f42

File tree

1 file changed

+61
-51
lines changed

1 file changed

+61
-51
lines changed
Lines changed: 61 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -1,93 +1,103 @@
1-
# Spring Data contribution guidelines
1+
= Spring Data contribution guidelines
22

3-
## Code of Conduct
3+
[[code-of-conduct]]
4+
== Code of Conduct
45

5-
This project adheres to the Contributor Covenant [code of conduct](CODE_OF_CONDUCT.adoc).
6+
This project adheres to the Contributor Covenant link:CODE_OF_CONDUCT.adoc[code of conduct].
67
By participating, you are expected to uphold this code.
78
Please report unacceptable behavior to [email protected].
89

9-
## Quickstart
10+
[[quickstart]]
11+
== Quickstart
1012

1113
For the impatient, if you want to submit a quick pull request:
1214

13-
- Make sure there is a ticket in the bug tracker for the project in our [JIRA](https://jira.springsource.org).
14-
- Make sure you use the code formatters provided [here](https://github.com/spring-projects/spring-data-build/tree/master/etc/ide) and have them applied to your changes. Don't submit any formatting related changes.
15-
- Make sure you submit test cases (unit or integration tests) that back your changes.
16-
- Try to reuse existing test sample code (domain classes). Try not to amend existing test cases but create new ones dedicated to the changes you're making to the codebase. Try to test as locally as possible but potentially also add integration tests.
17-
- In the Javadoc for the newly added test cases refer to the ticket the changes apply to like this
15+
* Make sure there is a ticket in the bug tracker for the project in our https://jira.spring.io[JIRA].
16+
* Make sure you use the code formatters provided https://github.com/spring-projects/spring-data-build/tree/master/etc/ide[here] and have them applied to your changes. Don't submit any formatting related changes.
17+
* Make sure you submit test cases (unit or integration tests) that back your changes.
18+
* Try to reuse existing test sample code (domain classes). Try not to amend existing test cases but create new ones dedicated to the changes you're making to the codebase. Try to test as locally as possible but potentially also add integration tests.
19+
* In the Javadoc for the newly added test cases refer to the ticket the changes apply to like this
1820

19-
```java
21+
[source, java]
22+
----
2023
/**
2124
* @see DATA…-???
2225
*/
2326
@Test
2427
public void yourTestMethod() { … }
25-
```
26-
27-
- Make sure you added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).
28-
- The commit message should follow the following style:
29-
- First line starts with the ticket id.
30-
- Separate ticket id and summary with a dash.
31-
- Finish summary with a dot.
32-
- In the description, don't use single line breaks. No manual wrapping. Separate paragraphs by a blank line.
33-
- Add related references at the very bottom (also see the section on pull requests below).
34-
35-
```
28+
----
29+
30+
* Make sure you added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).
31+
* The commit message should follow the following style:
32+
** First line starts with the ticket id.
33+
** Separate ticket id and summary with a dash.
34+
** Finish summary with a dot.
35+
** In the description, don't use single line breaks. No manual wrapping. Separate paragraphs by a blank line.
36+
** Add related references at the very bottom (also see the section on pull requests below).
37+
38+
[source]
39+
----
3640
DATA…-??? - Summary of the commit (try to stay under 80 characters).
3741
3842
Additional explanations if necessary.
3943
4044
See also: DATA…-???. (optionally refer to related tickets)
41-
```
45+
----
4246

43-
- Make sure you provide your full name and an email address registered with your GitHub account. If you're a first-time submitter, make sure you have completed the [Contributor's License Agreement form](https://support.springsource.com/spring_committer_signup).
47+
* Make sure you provide your full name and an email address registered with your GitHub account. If you're a first-time submitter, make sure you have completed the https://support.springsource.com/spring_committer_signup[Contributor's License Agreement form].
4448

45-
# Advanced
49+
[[advanced]]
50+
== Advanced
4651

4752
This section contains some advanced information, mainly targeted at developers of the individual projects.
4853

49-
## General
54+
[[advanced.general]]
55+
=== General
5056

51-
- Fix bugs in master first, if it's reasonable to port the fix back into a bugfix branch, try to do so with cherry picking.
52-
- Try to keep the lifespan of a feature branch as short as possible. For simple bug fixes they should only be used for code review in pull requests.
53-
- On longer running feature branches, don't pull changes that were made to master in the meantime. Instead, rebase the feature branch onto current master, sorting out issues and making sure the branch will fast-forward merge eventually.
57+
* Fix bugs in master first, if it's reasonable to port the fix back into a bugfix branch, try to do so with cherry picking.
58+
* Try to keep the lifespan of a feature branch as short as possible. For simple bug fixes they should only be used for code review in pull requests.
59+
* On longer running feature branches, don't pull changes that were made to master in the meantime. Instead, rebase the feature branch onto current master, sorting out issues and making sure the branch will fast-forward merge eventually.
5460

55-
## Change tracking
61+
[[advanced.change-tracking]]
62+
=== Change tracking
5663

57-
- Make sure you don't commit without referring to a ticket. If we have a rather general task to work on, create a ticket for it and commit against that one.
58-
- Try to resolve a ticket in a single commit. I.e. don't have separate commits for the fix and the test cases. When polishing pull requests requires some more effort, have a separate commit to clearly document the polishing (and attribute the efforts to you).
59-
- We usually use feature branches to work on tickets and potentially let multiple people work on a feature. There's a [new-issue-branch script](https://github.com/spring-projects/spring-data-build/tree/master/etc/scripts) available that sets up a feature branch for you, and adds a commit changing the Maven version numbers so that the branch builds can still publish snapshot artifacts but don't interfere with each other.
60-
- Follow the commit message style described in [quickstart]. Especially the summary line should adhere to the style documented there.
61-
- After pushing fixes to the remote repository, mark the tickets as resolved in JIRA and set the fixed versions according to which branches you pushed to.
62-
- Avoid merge commits as they just tend to make it hard to understand what comes from where. Using the ticket identifier in the summary line will allow us to keep track fo commits belonging together.
64+
* Make sure you don't commit without referring to a ticket. If we have a rather general task to work on, create a ticket for it and commit against that one.
65+
* Try to resolve a ticket in a single commit. I.e. don't have separate commits for the fix and the test cases. When polishing pull requests requires some more effort, have a separate commit to clearly document the polishing (and attribute the efforts to you).
66+
* We usually use feature branches to work on tickets and potentially let multiple people work on a feature. There's a https://github.com/spring-projects/spring-data-build/tree/master/etc/scripts[new-issue-branch script] available that sets up a feature branch for you, and adds a commit changing the Maven version numbers so that the branch builds can still publish snapshot artifacts but don't interfere with each other.
67+
* Follow the commit message style described in <<quickstart>>. Especially the summary line should adhere to the style documented there.
68+
* After pushing fixes to the remote repository, mark the tickets as resolved in JIRA and set the fixed versions according to which branches you pushed to.
69+
* Avoid merge commits as they just tend to make it hard to understand what comes from where. Using the ticket identifier in the summary line will allow us to keep track fo commits belonging together.
6370

64-
## Code style
71+
[[advanced.code-style]]
72+
=== Code style
6573

6674
This section contains some stuff that the IDE formatters do not enforce. Try to keep track of those as well
6775

68-
- Make sure, your IDE uses `.*` imports for all static ones.
69-
- Eclipse users should activate Save Actions to format sources on save, organize imports and also enable the standard set of
70-
- For methods only consisting of a single line, don't use any blank lines around the line of code. For methods consisting of more than one line of code, have a blank line after the method signature.
76+
* Make sure, your IDE uses `.*` imports for all static ones.
77+
* Eclipse users should activate Save Actions to format sources on save, organize imports and also enable the standard set of
78+
* For methods only consisting of a single line, don't use any blank lines around the line of code. For methods consisting of more than one line of code, have a blank line after the method signature.
7179

72-
## Handling pull requests
80+
=== Handling pull requests
7381

74-
- Be polite. It might be the first time someone contributes to an OpenSource project so we should forgive violations to the contribution guidelines. Use some gut feeling to find out in how far it makes sense to ask the reporter to fix stuff or just go ahead and add a polishing commit yourself.
75-
- The information we need from contributors are: their full name, an email address they have associated with their Github account, the confirmation number of the CLA (for the first contribution). Especially the first one probably needs to be asked for as people sometimes just use some alias in their GitHub account.
76-
- If you decide to merge stuff back make sure that all the infrastructure requirements are met (set up a JIRA ticket to commit against if necessary, etc.).
77-
- Before merging stuff back into master, make sure you rebase the branch. We generally do not allow merge commits, so a merge should always be fast-forward. The ticket IDs and the timestamps give enough tracking information already.
78-
- The simplest way to merge back a pull request submitted by someone external is `curl`ing the patch into `git am`. You can then polish it by either adding a commit or amending the provided commit. Make sure you keep the original author when amending.
82+
* Be polite. It might be the first time someone contributes to an OpenSource project so we should forgive violations to the contribution guidelines. Use some gut feeling to find out in how far it makes sense to ask the reporter to fix stuff or just go ahead and add a polishing commit yourself.
83+
* The information we need from contributors are: their full name, an email address they have associated with their Github account, the confirmation number of the CLA (for the first contribution). Especially the first one probably needs to be asked for as people sometimes just use some alias in their GitHub account.
84+
* If you decide to merge stuff back make sure that all the infrastructure requirements are met (set up a JIRA ticket to commit against if necessary, etc.).
85+
* Before merging stuff back into master, make sure you rebase the branch. We generally do not allow merge commits, so a merge should always be fast-forward. The ticket IDs and the timestamps give enough tracking information already.
86+
* The simplest way to merge back a pull request submitted by someone external is `curl`ing the patch into `git am`. You can then polish it by either adding a commit or amending the provided commit. Make sure you keep the original author when amending.
7987

80-
```
88+
[source]
89+
----
8190
curl $PULL_REQUEST_URL.patch | git am --ignore-whitespace
82-
```
91+
----
8392

84-
- If the you merge back a feature branch and multiple developers contributed to that, try to rearrange to commits and squash the into a single commit per developer. Combine the commit messages and edit them to make sense.
85-
- Before pushing the changes to the remote repository, amend the commit(s) to be pushed and add a reference to the pull request to them. This will cause the pull request UI in GitHub show and link those commits.
93+
* If the you merge back a feature branch and multiple developers contributed to that, try to rearrange to commits and squash the into a single commit per developer. Combine the commit messages and edit them to make sense.
94+
* Before pushing the changes to the remote repository, amend the commit(s) to be pushed and add a reference to the pull request to them. This will cause the pull request UI in GitHub show and link those commits.
8695

87-
```
96+
[source]
97+
----
8898
8999
90100
Original pull request: #??.
91-
```
101+
----
92102

93103
Important pieces here: colon and the sence completed with a dot.

0 commit comments

Comments
 (0)