Thanks a lot for commenting. We are getting great feedback on this thread.
The take-aways are:
1. In general people prefer having explicit reasons why pull requests
should be closed. We should push committers to leave messages that are more
explicit about why certain PR should be closed or not. I
bq. there should be more committers or they are asked to be more active.
Bingo.
bq. they can't be closed only because it is "expired" with a copy and
pasted message.
+1
On Mon, Apr 18, 2016 at 9:14 PM, Hyukjin Kwon wrote:
> I don't think asking committers to be more
>>>By the way, some people noted that closing PRs may discourage
contributors. I think our open PR count alone is very discouraging. Under
what circumstances would you feel encouraged to open a PR against a project
that has hundreds of open PRs, some from many, many months ago
I don't think asking committers to be more active is impractical. I am not
too sure if other projects apply the same rules here but
I think if a project is being more popular, then I think it is appropriate
that there should be more committers or they are asked to be more active.
In addition, I
Relevant: https://github.com/databricks/spark-pr-dashboard/issues/1
A lot of this was discussed a while back when the PR Dashboard was first
introduced, and several times before and after that as well. (e.g. August
2014
During the months of November / December, the 30 day period should be
relaxed.
Some people(at least in US) may take extended vacation during that time.
For Chinese developers, Spring Festival would bear similar circumstance.
On Mon, Apr 18, 2016 at 7:25 PM, Hyukjin Kwon
I also think this might not have to be closed only because it is inactive.
How about closing issues after 30 days when a committer's comment is added
at the last without responses from the author?
IMHO, If the committers are not sure whether the patch would be useful,
then I think they should
It would be better to have a specific technical reason why this PR should
be closed, either the implementation is not good or the problem is not
valid, or something else. That will actually help the contributor to shape
their codes and reopen the PR again. Otherwise reasons like "feel free to
Having a PR closed, especially if due to committers not having hte
bandwidth to check on things, will be very discouraging to new folks.
Doubly so for those inexperienced with opensource. Even if the message
says "feel free to reopen for so-and-so reason", new folks who lack
confidence are going
The cost of "reopen" is close to zero, because it is just clicking a
button. I think you were referring to the cost of closing the pull request,
and you are assuming people look at the pull requests that have been
inactive for a long time. That seems equally likely (or unlikely) as
committers
>From committers' perspective, would they look at closed PRs ?
If not, the cost is not close to zero.
Meaning, some potentially useful PRs would never see the light of day.
My two cents.
On Mon, Apr 18, 2016 at 12:43 PM, Reynold Xin wrote:
> Part of it is how difficult it
Part of it is how difficult it is to automate this. We can build a perfect
engine with a lot of rules that understand everything. But the more
complicated rules we need, the more unlikely for any of these to happen. So
I'd rather do this and create a nice enough message to tell contributors
bq. close the ones where they don't respond for a week
Does this imply that the script understands response from human ?
Meaning, would the script use some regex which signifies that the
contributor is willing to close the PR ?
If the contributor is willing to close, why wouldn't he / she do it
+1 and at the same time maybe surface a report to this list of PRs which
need committer action and have only had submitters responding to pings in
the last 30 days?
On Mon, Apr 18, 2016 at 3:33 PM, Holden Karau wrote:
> Personally I'd rather err on the side of keeping PRs
Personally I'd rather err on the side of keeping PRs open, but I understand
wanting to keep the open PRs limited to ones which have a reasonable chance
of being merged.
What about if we filtered for non-mergeable PRs or instead left a comment
asking the author to respond if they are still
Cody,
Thanks for commenting. "inactive" here means no code push nor comments. So
any "ping" would actually keep the pr in the open queue. Getting
auto-closed also by no means indicate the pull request can't be reopened.
On Mon, Apr 18, 2016 at 12:17 PM, Cody Koeninger wrote:
I had one PR which got merged after 3 months.
If the inactivity was due to contributor, I think it can be closed after 30
days.
But if the inactivity was due to lack of review, the PR should be kept open.
On Mon, Apr 18, 2016 at 12:17 PM, Cody Koeninger wrote:
> For what
For what it's worth, I have definitely had PRs that sat inactive for
more than 30 days due to committers not having time to look at them,
but did eventually end up successfully being merged.
I guess if this just ends up being a committer ping and reopening the
PR, it's fine, but I don't know if
We have hit a new high in open pull requests: 469 today. While we can
certainly get more review bandwidth, many of these are old and still open
for other reasons. Some are stale because the original authors have become
busy and inactive, and some others are stale because the committers are not
19 matches
Mail list logo