pgjdbc_r2dbc-postgresql
91 строка · 4.8 Кб
1= Contributing to R2DBC
2
3First off, thank you for taking the time to contribute! 👍 🎉
4
5== Table of Contents
6
7* <<code-of-conduct,Code of Conduct>>
8* <<how-to-contribute,How to Contribute>>
9** <<discuss,Discuss>>
10** <<ticket-lifecycle,Ticket Lifecycle>>
11** <<submit-a-pull-request,Submit a Pull Request>>
12* <<source-code-style,Source Code Style>>
13
14[[code-of-conduct]]
15== Code of Conduct
16
17This project is governed by the link:https://github.com/pgjdbc/r2dbc-postgresql/blob/main/.github/CODE_OF_CONDUCT.adoc[Code of Conduct].
18By participating you are expected to uphold this code.
19Please report unacceptable behavior to r2dbc@googlegroups.com.
20
21[[how-to-contribute]]
22== How to Contribute
23
24[[discuss]]
25=== Discuss
26
27If you have a question, check https://stackoverflow.com/tags/r2dbc[StackOverflow] using the https://stackoverflow.com/tags/r2dbc[r2dbc] tag or the link:https://groups.google.com/forum/#!forum/r2dbc[mailing list]
28Find an existing discussion or start a new one if necessary.
29
30If you suspect an issue, perform a search in the GitHub tracker of the R2DBC project, using a few different keywords.
31When you find related issues and discussions, prior or current, it helps you to learn and it helps us to make a decision.
32
33=== Create a Ticket
34
35Reporting an issue or making a feature request is a great way to contribute.
36Your feedback and the conversations that result from it provide a continuous flow of ideas.
37
38Before you create a ticket, please take the time to <<discuss,research first>>.
39
40If creating a ticket after a discussion on StackOverflow or the Mailing List, please provide a self-sufficient description in the ticket.
41We understand this is extra work but the issue tracker is an important place of record for design discussions and decisions that can often be referenced long after the fix version, for example to revisit decisions, to understand the origin of a feature, and so on.
42
43When ready create a ticket in GitHub.
44
45[[ticket-lifecycle]]
46=== Ticket Lifecycle
47
48When an issue is first created, it may not be assigned and will not have a fix version.
49Within a day or two, the issue is assigned to a specific committer.
50The committer will then review the issue, ask for further information if needed, and based on the findings, the issue is either assigned a fix
51version or rejected.
52
53When a fix is ready, the issue is marked "Resolved" and may still be re-opened.
54Once the fix is released, you will need to create a new, related ticket with a fresh description, if necessary.
55
56[[submit-a-pull-request]]
57=== Submit a Pull Request
58
59You can contribute a source code change by submitting a pull request.
60
611. For all but the most trivial of contributions, please <<create-a-ticket,create a ticket>>.
62The purpose of the ticket is to understand and discuss the underlying issue or feature.
63We use the JIRA issue tracker as the preferred place of record for conversations and conclusions.
64In that sense discussions directly under a PR are more implementation detail oriented and transient in nature.
65
662. Always check out the `main` branch and submit pull requests against it.
67Backports to prior versions will be considered on a case-by-case basis and reflected as the fix version in the issue tracker.
68
693. Use short branch names, preferably based on the GitHub issue (e.g. `gh-1234`), or otherwise using succinct, lower-case, dash (-) delimited names, such as `fix-warnings`.
70
714. Choose the granularity of your commits consciously and squash commits that represent multiple edits or corrections of the same logical change.
72See https://git-scm.com/book/en/Git-Tools-Rewriting-History[Rewriting History section of Pro Git] for an overview of streamlining commit history.
73
745. Format commit messages using 55 characters for the subject line, 72 lines for the description, followed by related issues, e.g. `[resolves #1234]`
75See the https://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines[Commit Guidelines section of Pro Git] for best practices around commit messages and use `git log` to see some examples.
76
776. List the GitHub issue number in the PR description.
78
79If accepted, your contribution may be heavily modified as needed prior to merging.
80You will likely retain author attribution for your Git commits granted that the bulk of your changes remain intact.
81You may also be asked to rework the submission.
82
83If asked to make corrections, simply push the changes against the same branch, and your pull request will be updated.
84In other words, you do not need to create a new pull request when asked to make changes.
85
86
87[[source-code-style]]
88== Source Code Style
89
90We provide an IntelliJ link:https://github.com/pgjdbc/r2dbc-postgresql/blob/main/intellij-style.xml[IDEA code formatting configuration] that defines the source file coding standards.
91Import and use the provided configuration to avoid formatting changes in pull requests.
92