10 Tips for Better Pull Requests

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Fri Jan 16 15:49:24 PST 2015


On Fri, Jan 16, 2015 at 03:33:00PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/16/2015 2:59 PM, H. S. Teoh via Digitalmars-d wrote:
> >Github already has a feature for sorting the PR list by most recently
> >updated, least recently updated, oldest, newest, etc., etc..
> >
> >It's just a matter of setting the *default* sorting order. I don't
> >know if github supports that, but for a long time now I've been
> >wishing that the PR page should default to "most recently update"
> >instead of "newest", as it is now.
> 
> Yes, I'd like to change the default.

Does github have that option? If so, can somebody who has the rights
make this change?


> >Some companies, in the name of reining in the number of open bugs,
> >resort to closing "inactive" (but nonetheless valid) bugs after a
> >given amount of time. Sure, it reduces some integer on somebody's
> >statistics page, but did it increase the quality of the product?
> >Nope. Did it reduce the amount of work needed? Nope, on the contrary,
> >it *increased* it, since later on some other customer inevitably runs
> >into the same problem whose bug report got closed down, so now we
> >have extra overhead for (re)processing the "new" bug, and repeating
> >the research that has been buried in the dusts of bugtracker history
> >in order to get back up to speed with the problem.
> 
> Yup. I fail to see how automatically closing PRs after X days can
> possibly result in an improved quality of the product.

It may not directly impact the quality of the product, but it *could*
affect morale (potential contributor looks at the PR list, sees it's
90+, and feels that it's unlikely his contributions will ever get
accepted, so gives up before even trying), which in the long run does
have impact on product quality. Unfortunately, contributors are not
machines, so such emotional factors can and do make a difference.


> And even worse, it can result in someone unwittingly doing work to
> submit a new PR that solves the same problem. We can't afford people
> wasting effort like that.

Actually, we're already at risk of that. If the PR list is 5-6 pages
long, how likely is it that a potential contributor will scan through
all of them before deciding that his work isn't duplicated work? In
theory, everyone *should*, but I highly doubt anyone submitting a PR
actually reads beyond the first page (if even that!).


T

-- 
People tell me that I'm paranoid, but they're just out to get me.


More information about the Digitalmars-d mailing list