I'd like to take care of issue #20027 (and issue #20239), concerning std.zip. As this are actually lot's of small issues I'm not sure, how to handle this:

a) One big PR with lot's of small commits?
b) One small PR after another?
c) Like b) but trying to submit some nonclashing PRs in parallel? (not sure if this is possible at all)
d) ???

What's best?

On Wed, Sep 25, 2019 at 05:02:02PM +0000, berni via Digitalmars-d wrote:
> I'd like to take care of issue #20027 (and issue #20239), concerning std.zip. As this are actually lot's of small issues I'm not sure, how to handle this:
> 
> a) One big PR with lot's of small commits?
> b) One small PR after another?
> c) Like b) but trying to submit some nonclashing PRs in parallel? (not
> sure if this is possible at all)
> d) ???
> 
> What's best?

I haven't contributed a PR for a while now, but based on past
experience, my advice is to go with (b) or (c).

I recommend against (a) because, based on my past experience as PR
reviewer, large PRs tend to be:

1) Too big to review in one sitting, and so reviewers are more liable to put off reviewing it.

2) Too big to fully comprehend without some major dedicated effort at understanding the affected code, and since reviewers are volunteers, this is a big disincentive to review it (I can spare 5-10 mins here or there, but the prospect of taking 2 hours off my day job just to review a PR is not very attractive, to say the least).

3) Easily stuck for a long time over one or two points of controversy while the rest of the uncontroversial changes remain languishing in the PR queue instead of being merged. Breaking your change into smaller, more-or-less independent chunks makes it more likely that non-controversial changes will get merged to the benefit of all, even while some of the other changes are stuck due to discussion, etc..

4) Hard to keep up-to-date as the master branch continues to change and merge conflicts arise. Big PRs tend to have more conflicts over time, and the amount of effort required to resolve these conflicts on an ongoing basis while the PR languishes in the queue can be very off-putting. It can easily add up to more effort than writing the PR in the first place, and not many people can stomach that.

So, don't do (a). Go with (b) or (c).


T

-- 
May you live all the days of your life. -- Jonathan Swift