[Audacity-devel] old pull requests

[Steve the Fiddle]

I notice that we have quite a few very old (3 to 15 months) open pull
requests. That must look very discouraging to potential new developers
who may not see the larger number of pull requests that have been
merged.

I presume that after this amount of time those old requests are
unlikely to be accepted, so perhaps someone that understands what's
wrong with them could close them with a note as to why. I'm sure that
we're all keen to see new developers contributing to Audacity, so I
think that dealing with pull requests promptly will help to convey
that publicly.

Steve

------------------------------------------------------------------------------

[James Crook]

Steve,

Problem is no one has authority to make decisions on these, not even RM
(who only has rights over what is in their release).
I only pull or reject requests which I am very sure about. Additional
problem is that the pull requests may be for platforms/build
environments that the reviewer doesn't have experience with.

Is there a way to make it clearer to people who make pull requests that
they need to visit audacity-devel and talk about their change , if it is
to be accepted?

Started a wiki page for it. Advantage of wiki is we can keep the
comments up to date (and see history). Idea is only to record the
borderline ones (borderline is wide). So completely rejected don't go
in and accepted don't go in.

http://wiki.audacityteam.org/wiki/Github_Pull_Requests

We will need time to bring this up to date!

--James.

Post by Steve the Fiddle
I notice that we have quite a few very old (3 to 15 months) open pull
requests. That must look very discouraging to potential new developers
who may not see the larger number of pull requests that have been
merged.
I presume that after this amount of time those old requests are
unlikely to be accepted, so perhaps someone that understands what's
wrong with them could close them with a note as to why. I'm sure that
we're all keen to see new developers contributing to Audacity, so I
think that dealing with pull requests promptly will help to convey
that publicly.
Steve

------------------------------------------------------------------------------

[Gale Andrews]

Post by James Crook
Steve,
Problem is no one has authority to make decisions on these, not even RM
(who only has rights over what is in their release).
I only pull or reject requests which I am very sure about.

That's all anyone can do, really,

Post by James Crook
Additional problem is that the pull requests may be for platforms/build
environments that the reviewer doesn't have experience with.
Is there a way to make it clearer to people who make pull requests that
they need to visit audacity-devel and talk about their change , if it is
to be accepted?

We could update or replace
http://wiki.audacityteam.org/wiki/SubmittingPatches .

Meantime I made it clearer on
https://github.com/audacity/audacity/wiki .


Gale

Post by James Crook
Started a wiki page for it. Advantage of wiki is we can keep the
comments up to date (and see history). Idea is only to record the
borderline ones (borderline is wide). So completely rejected don't go
in and accepted don't go in.
http://wiki.audacityteam.org/wiki/Github_Pull_Requests
We will need time to bring this up to date!
--James.

Post by Steve the Fiddle
I notice that we have quite a few very old (3 to 15 months) open pull
requests. That must look very discouraging to potential new developers
who may not see the larger number of pull requests that have been
merged.
I presume that after this amount of time those old requests are
unlikely to be accepted, so perhaps someone that understands what's
wrong with them could close them with a note as to why. I'm sure that
we're all keen to see new developers contributing to Audacity, so I
think that dealing with pull requests promptly will help to convey
that publicly.
Steve

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

[Vaughan Johnson]

thx for this work, guys! -- V

Post by Gale Andrews

Post by James Crook
Steve,
Problem is no one has authority to make decisions on these, not even RM
(who only has rights over what is in their release).
I only pull or reject requests which I am very sure about.

That's all anyone can do, really,

Post by James Crook
Additional problem is that the pull requests may be for platforms/build
environments that the reviewer doesn't have experience with.
Is there a way to make it clearer to people who make pull requests that
they need to visit audacity-devel and talk about their change , if it is
to be accepted?

We could update or replace
http://wiki.audacityteam.org/wiki/SubmittingPatches .
Meantime I made it clearer on
https://github.com/audacity/audacity/wiki .
Gale

Post by James Crook
Started a wiki page for it. Advantage of wiki is we can keep the
comments up to date (and see history). Idea is only to record the
borderline ones (borderline is wide). So completely rejected don't go
in and accepted don't go in.
http://wiki.audacityteam.org/wiki/Github_Pull_Requests
We will need time to bring this up to date!
--James.

Post by Steve the Fiddle
I notice that we have quite a few very old (3 to 15 months) open pull
requests. That must look very discouraging to potential new developers
who may not see the larger number of pull requests that have been
merged.
I presume that after this amount of time those old requests are
unlikely to be accepted, so perhaps someone that understands what's
wrong with them could close them with a note as to why. I'm sure that
we're all keen to see new developers contributing to Audacity, so I
think that dealing with pull requests promptly will help to convey
that publicly.
Steve

------------------------------------------------------------

------------------

Post by James Crook
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Thanks for updating the github wiki Gale.


I've done lots of work on pull requests today, closing a number of them,
and organising the remaining 15 that are currently open.
https://github.com/audacity/audacity/pulls

The key improvement I made is we now have labels on the PRs, which are
explained here:
http://wiki.audacityteam.org/wiki/Github_Pull_Requests
I hadn't been aware of the label feature before.

The labels also explain to me/us why some of the PRs aren't progressing!
If anyone has input on the 'who can test?', or the 'do we want this?' of
a PR, they can add that to the comments of the PR.

There is almost no way to tell people making PRs about the meaning of
the labels, or the wiki page. To work around that I created a fake
milestone, and we can add every new PR into the fake milestone as it
arrives. That will then alert the person who made the PR, as they will
see it in the events of the PR.

--James.

Post by Gale Andrews

Post by James Crook
Steve,
Problem is no one has authority to make decisions on these, not even RM
(who only has rights over what is in their release).
I only pull or reject requests which I am very sure about.

That's all anyone can do, really,

Post by James Crook
Additional problem is that the pull requests may be for platforms/build
environments that the reviewer doesn't have experience with.
Is there a way to make it clearer to people who make pull requests that
they need to visit audacity-devel and talk about their change , if it is
to be accepted?

We could update or replace
http://wiki.audacityteam.org/wiki/SubmittingPatches .
Meantime I made it clearer on
https://github.com/audacity/audacity/wiki .
Gale

Post by James Crook
Started a wiki page for it. Advantage of wiki is we can keep the
comments up to date (and see history). Idea is only to record the
borderline ones (borderline is wide). So completely rejected don't go
in and accepted don't go in.
http://wiki.audacityteam.org/wiki/Github_Pull_Requests
We will need time to bring this up to date!
--James.

Post by Steve the Fiddle
I notice that we have quite a few very old (3 to 15 months) open pull
requests. That must look very discouraging to potential new developers
who may not see the larger number of pull requests that have been
merged.
I presume that after this amount of time those old requests are
unlikely to be accepted, so perhaps someone that understands what's
wrong with them could close them with a note as to why. I'm sure that
we're all keen to see new developers contributing to Audacity, so I
think that dealing with pull requests promptly will help to convey
that publicly.
Steve

------------------------------------------------------------------------------

[Thomas Fehér]

Thank you Steve and James for bringing this to the table. This was one
of the reasons for me to stop contributing to Audacity.

Post by James Crook
Steve,
Problem is no one has authority to make decisions on these, not even RM
(who only has rights over what is in their release).
I only pull or reject requests which I am very sure about. Additional
problem is that the pull requests may be for platforms/build
environments that the reviewer doesn't have experience with.
Is there a way to make it clearer to people who make pull requests that
they need to visit audacity-devel and talk about their change , if it is
to be accepted?
Started a wiki page for it. Advantage of wiki is we can keep the
comments up to date (and see history). Idea is only to record the
borderline ones (borderline is wide). So completely rejected don't go
in and accepted don't go in.
http://wiki.audacityteam.org/wiki/Github_Pull_Requests
We will need time to bring this up to date!
--James.

Post by Steve the Fiddle
I notice that we have quite a few very old (3 to 15 months) open pull
requests. That must look very discouraging to potential new developers
who may not see the larger number of pull requests that have been
merged.
I presume that after this amount of time those old requests are
unlikely to be accepted, so perhaps someone that understands what's
wrong with them could close them with a note as to why. I'm sure that
we're all keen to see new developers contributing to Audacity, so I
think that dealing with pull requests promptly will help to convey
that publicly.
Steve

------------------------------------------------------------------------------

------------------------------------------------------------------------------