10 Tips for Better Pull Requests

[H. S. Teoh via Digitalmars-d]

On Fri, Jan 16, 2015 at 02:17:02PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/16/2015 12:48 PM, Vladimir Panteleev wrote:
[...]
> >Add an "abandoned" label, and assign it when closing? Then they won't
> >get lost, but also won't clutter the list.
> 
> What should happen is the list of PRs should be sorted on a basis of
> most-recently-touched-is-first. The older PRs then naturally fade to
> the 'next' pages. 'clutter' is not a problem, unless we decide that
> number of open PRs is a proxy for quality of the project.

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.


> We should be very careful about working metrics like "number of open
> PRs".  Focus on such can generate an illusion of progress, and
> actually make things worse.
> 
> I've worked at companies that would rate engineers based on the "bug
> count".  That ended very badly, it was so bad it was comical, how
> working that number actually wrecked the quality of the product. I've
> seen similar disasters with use of metrics on inventory minimization,
> and others. Ever since it has made me deeply suspicious about basing
> quality on such numbers.

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.

Perhaps what *should* have happened, is that somebody's statistics page
should have included a filter that limited the scope of the query to the
last X months for some suitable value of X, rather than count *all* bugs
from the beginning of time until now.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.