On 1/16/15 2:17 PM, Walter Bright wrote:
> 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.

One anecdote is what it is. There is a lot of value in informative proxies. -- Andrei

On 1/16/2015 2:28 PM, Andrei Alexandrescu wrote:
> On 1/16/15 2:17 PM, Walter Bright wrote:
>> 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.
>
> One anecdote is what it is. There is a lot of value in informative proxies. --
> Andrei
>

Informative is fine. Basing decisions on metrics unleavened by contextual judgement isn't going to work well.

It isn't just one metric. I've personally seen it multiple times with various metrics, and regularly read in the news about counterproductive results obtained by using metrics absent judgement. The "zero tolerance" policies schools have are a stellar example, where students get punished for chewing a pizza into the shape of a gun.


http://www.thetruthaboutguns.com/2011/12/daniel-zimmerman/zero-tolerance-idiot-of-the-day-principal-steve-luker/

Want more? Consider "work to rule" tactics used by unions.

  http://en.wikipedia.org/wiki/Work-to-rule

I agree we have a problem with good PRs left twisting in the wind. Deleting them simply because they are old is worse.

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.

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.


> 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.

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.

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.

On Friday, 16 January 2015 at 23:51:40 UTC, H. S. Teoh via Digitalmars-d wrote:
> 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.

I agree, H.S... nurturing the contributor experience should be the only consideration. But I doubt people care about numbers. Instead, they care that *their* suggestion, *their* improvement is responded to. I'd venture to say that nothing matters more than knowing that one has been heard.

On 2015-01-16 18:49, Andrei Alexandrescu wrote:

> I agree that a hamfisted policy would do more harm than good. That's why
> it's so hard to define!
>
> I'm thinking of something like: if there's $(legitimate) request for
> changes but the author is dormant for more than $(X) days, then close.

Does the opposite apply? If no reviewer has comment anything in $(X) day the pull request is merged ;)

-- 
/Jacob Carlborg

On 2015-01-16 20:23, Walter Bright wrote:

> Arbitrarily closing them means they get lost forever.

How so?

-- 
/Jacob Carlborg

On 2015-01-16 21:44, Andrei Alexandrescu wrote:

> Look for a champion after $(X) days? It looks like once a pull request
> is open it's impossible to close it. There's got to be some garbage
> collection somehow :o). -- Andrei

It's always possible to add a label to the pull request.

-- 
/Jacob Carlborg

On 2015-01-17 00:49, H. S. Teoh via Digitalmars-d wrote:

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

Not as far as I can see. The settings page for a project doesn't contain much.

-- 
/Jacob Carlborg