Hi Anja, Le 24/01/2023 à 23:19, Anja a écrit :
A new contributor might not look at this section of the documentation, because it is written for reviewers, not PR authors.
That is true. Perhaps it would be desirable to split that document in two: one with general guidelines for what makes a PR ready for merging, one with specific guidelines for reviewers.
Things to consider are: * Would it make sense to mention that a PR could be adopted, and the circumstances in which it might be adopted, in the Lifecycle of a PR: https://arrow.apache.org/docs/developers/guide/step_by_step/pr_lifecycle.html. * What is a decent standard for "waiting for response to ping" (1 week? 2? Context dependent?).
One week or two sounds fine to me. It's certainly context-dependent (is the contribution strongly needed, is it a prerequisite for other changes? perhaps there's a release looming and it would be a welcome addition? is the author usually responsive and collaborative, or did they already abandon PRs?).
* Are there community norms for credit attribution in the Squashed merge commit, if multiple authors worked on a PR over time?
I don't think there are any. Usually I would try to keep credit to the "main" author, which is a subjective estimate but should be correlated to the number of lines of code changes (even if most of this code is "boring" and someone else contributed a small critical change).
* What is the process if OP has not set "allow contributions to this PR" on GitHub or if the adopted is not an Arrow committer? Does someone fork their fork?
Personally, I would create a branch on my fork with the same changes (but with authorship potentially lost, if I just apply them as a patch).
Regards Antoine.
