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: CONTRIBUTING.md
+47-1Lines changed: 47 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,8 +2,14 @@
2
2
3
3
## Table of Contents <!-- omit in toc -->
4
4
-[Contributing](#contributing)
5
+
-[Issue vs. Pull Request](#issue-vs-pull-request)
5
6
-[Templates](#templates)
6
7
-[Why Contributing?](#why-contributing)
8
+
-[Contribution FAQs](#contribution-faqs)
9
+
-[Reviewer Role](#reviewer-role)
10
+
-[Review Feedback](#review-feedback)
11
+
-[Merge Readiness](#merge-readiness)
12
+
-[Review Validity](#review-validity)
7
13
-[Environment Setup](#environment-setup)
8
14
-[Recommended Tools](#recommended-tools)
9
15
-[Setting up your local machine](#setting-up-your-local-machine)
@@ -87,6 +93,46 @@ Consider the benefits you get:
87
93
88
94
Most importantly, with every contribution you improve your skills so that future contributions take even less time and you get all the benefits above for free — easy choice, right?
89
95
96
+
## Contribution FAQs
97
+
98
+
### Reviewer Role
99
+
100
+
> *Instead of writing review comments back-and-forth, why doesn't the reviewer just write the code themselves?*
101
+
102
+
A reviewer is already helping you to make a code contribution through their review. A reviewer *may* even help you to write code by actually writing it for you, but is not obliged to do so.
103
+
104
+
GitHub allows reviewers to suggest and write code changes as part of the review feedback. These code suggestions are likely to contain mistakes due to the lack of code syntax checks when writing code directly on GitHub. You should therefore always review these suggestions before accepting them, ideally in an IDE. If you merge a code suggestion and the CI then fails, take another look at the code change before asking the reviewer for help.
105
+
106
+
### Review Feedback
107
+
108
+
> *It takes too much effort to incorporate the review feedback, why why can't you just merge my pull request?*
109
+
110
+
If you are a new contributor, it's naturally a learning experience for you and therefore takes longer. We welcome contributors of any experience levels and gladly support you in getting familiar with the code base and our quality standards and contribution requirements. In return we expect you to be open to and appreciative of the reviewers' feedback.
111
+
112
+
In a large pull request, it can be a significant effort to bring it over the finish line. Luckily this is a collaborative environment and others are free to jump in to contribute to the pull request to share the effort. You can either give others access to your fork or they can open their own pull request based on your previous work.
113
+
114
+
If you are out of resources stay calm, explain your personal constraints (expertise or time) and ask for help. Wasting time by complaining about the amount of review comments will neither use your own time in a meaningful way, nor the time of others who read your complaint.
115
+
116
+
This is a collaborative enviroment in which everyone works on a common goal - to get a pull request ready for merging. Reviewers are working *with* you to get your pull request ready, *not against you*.
117
+
118
+
**❗️ Always be mindful that the reviewers' efforts are an integral part of code contribution. Their review is as important as your written code and their review time is a valuable as your coding time.**
119
+
120
+
### Merge Readiness
121
+
122
+
> *The feature already works, why do you request more changes instead of just merging my pull request?*
123
+
124
+
A feature may work for your own use case or in your own environment, but that doesn't necessarily mean that it's ready for merging. Aside from code quality and code style requirements, reviewers also review based on strategic and architectural considerations. It's often easy to just get a feature to work, but it needs to be also maintained in the future, robust therefore well tested and validated, intuitive for other developers to use, well documented, and not cause a forseeable breaking change in the near future.
125
+
126
+
### Review Validity
127
+
128
+
> *The reviewer has never worked on the issue and was never part of any previous discussion, why would I care about their opinion?*
129
+
130
+
It's contrary to an open, collaborative environment to expect others to be involved in an issue or discussion since its beginning. Such a mindset would close out any new views, which are important for a differentiated discussion.
131
+
132
+
> *The reviewer doesn't have any expertise in that matter, why would I care about their opinion?*
133
+
134
+
Your arguments must focus on the issue, not on your assumption of someone else's personal experience. We will take immediate and appropriate action in case of personal attacks, regardless of your previous contributions. Personal attacks are not permissible. If you became a victim of personal attacks, you can privately [report](https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam) the GitHub comment to the Parse Platform PMC.
135
+
90
136
## Environment Setup
91
137
92
138
### Recommended Tools
@@ -453,7 +499,7 @@ The following changes are done in the `alpha` branch, before publishing the last
453
499
3. Pull all remote branches into local branches.
454
500
4. Create a new temporary branch `backmerge` on branch `release`.
455
501
5. Create PR to merge `backmerge` into `beta`:
456
-
- PR title: `<pr-name> [skip release]` where `<pr-name>` is the PR title of step 1.
502
+
- PR title: `refactor: <commit-summary>` where `<commit-summary>` is the commit summary of step 1. The commit type needs to be `refactor`, otherwise the commit will show in the changelog of the `release` branch, once the `beta` branch is merged into release; this would a duplicate entry because the same changelog entry has already been generated when the PR was merged into the `release` branch in step 1.
457
503
- PR description: (leave empty)
458
504
6. Resolve any conflicts:
459
505
- During back-merging, usually all changes are preserved; current changes come from the hotfix in the `release` branch, the incoming changes come from the `beta` branch usually being ahead of the `release` branch. This makes back-merging so complex and bug-prone and is the main reason why it should be avoided if possible.
0 commit comments