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
absen
On Saturday, 17 January 2015 at 11:52:03 UTC, Jacob Carlborg
wrote:
On 2015-01-16 19:50, deadalnix wrote:
It is better to have some kind of bot that comment on the PR
after a
while. Like "hey, this PR is hanging, can someone make thing
go forward
or I'll close in 2 more month". That generate a
On 2015-01-16 19:50, deadalnix wrote:
It is better to have some kind of bot that comment on the PR after a
while. Like "hey, this PR is hanging, can someone make thing go forward
or I'll close in 2 more month". That generate activity on the PR and is
often a wake up call for people.
Ruby on Ra
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
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
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 Carlb
On 2015-01-16 20:23, Walter Bright wrote:
Arbitrarily closing them means they get lost forever.
How so?
--
/Jacob Carlborg
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,
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 ma
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
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
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 se
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 invent
On 1/16/2015 12:48 PM, Vladimir Panteleev wrote:
On Friday, 16 January 2015 at 19:23:06 UTC, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
I'm thinking of something like: if there's $(legitimate) request for changes but
the author is dormant for more than $(X) days, then
On 1/16/2015 12:44 PM, Andrei Alexandrescu wrote:
On 1/16/15 11:23 AM, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
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.
That's also
On Fri, 16 Jan 2015 11:23:02 -0800
Walter Bright via Digitalmars-d wrote:
> On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
> > 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.
>
> That's also a
On Friday, 16 January 2015 at 19:23:06 UTC, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
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.
That's also a hamfisted policy. I've se
On 1/16/15 11:23 AM, Walter Bright wrote:
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
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.
That's also a hamfisted policy. I've seen PR's that were good,
On Friday, 16 January 2015 at 18:50:29 UTC, deadalnix wrote:
On Friday, 16 January 2015 at 16:22:13 UTC, ketmar via
Digitalmars-d wrote:
it sits in queue without any comments more than 20 days?
reject and
close it.
It is better to have some kind of bot that comment on the PR
after a while. L
On 1/16/2015 9:49 AM, Andrei Alexandrescu wrote:
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.
That's also a hamfisted policy. I've seen PR's that were good, but needed a bit
of work, but the author d
On Friday, 16 January 2015 at 16:22:13 UTC, ketmar via
Digitalmars-d wrote:
it sits in queue without any comments more than 20 days? reject
and
close it.
It is better to have some kind of bot that comment on the PR
after a while. Like "hey, this PR is hanging, can someone make
thing go forwa
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.
Andrei
Macros:
legitimate=?
X=?
legitimate= consen
On 1/16/15 9:41 AM, Tobias Pankrath wrote:
That reply was not about my pull request specifically. Since it
basically consists of two new files, it can stay there for months
without generating any additional work for me. But it is a good
counterexample to the »just close old stuff«-policy.
I agr
> >> On 1/16/15 7:50 AM, H. S. Teoh via Digitalmars-d wrote:
> >> > On Thu, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via
> >> > Digitalmars-d wrote:
> >> >> http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
> &
Bad idea. Take for example this one of mine
https://github.com/D-Programming-Language/phobos/pull/2793
that sits
there for more than 20 days. I've addressed all concerns and
now it's
waiting for someone who feels responsible for std.container to
pull it.
Now four things can happen:
1. Someon
On Fri, Jan 16, 2015 at 05:16:38PM +, Tobias Pankrath via Digitalmars-d
wrote:
> On Friday, 16 January 2015 at 16:22:13 UTC, ketmar via Digitalmars-d wrote:
> >On Fri, 16 Jan 2015 08:10:50 -0800
> >Andrei Alexandrescu via Digitalmars-d
> >wrote:
[...]
> >>I think it would be great if we defin
2PM -0800, Walter Bright via >
Digitalmars-d wrote:
>> http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
>>
>> I agree with pretty much everything in this article.
>>
>> tl,dr:
>>
>> "The more you make your reviewer work, the gre
mars-d wrote:
>> http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
>>
>> I agree with pretty much everything in this article.
>>
>> tl,dr:
>>
>> "The more you make your reviewer work, the greater the risk
>> is that
>> you
On Fri, 16 Jan 2015 08:10:50 -0800
Andrei Alexandrescu via Digitalmars-d
wrote:
> On 1/16/15 7:50 AM, H. S. Teoh via Digitalmars-d wrote:
> > On Thu, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via Digitalmars-d
> > wrote:
> >> http://blog.ploeh.dk/2015/01/15
On 1/16/15 7:50 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via Digitalmars-d wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
"The more you make
On Thu, Jan 15, 2015 at 08:20:32PM -0800, Walter Bright via Digitalmars-d wrote:
> http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
>
> I agree with pretty much everything in this article.
>
> tl,dr:
>
> "The more you make your reviewer work, the great
On Friday, 16 January 2015 at 04:20:37 UTC, Walter Bright wrote:
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
Most are intuitive, but "10. Avoid thrashing" is worthy.
http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/
I agree with pretty much everything in this article.
tl,dr:
"The more you make your reviewer work, the greater the risk is that your Pull
Request will be rejected."
33 matches
Mail list logo