Thread (18 messages) 18 messages, 4 authors, 2019-11-26

Re: Should we auto-close PRs on git/git?

From: Johannes Schindelin <hidden>
Date: 2019-11-12 19:11:31

Hi Emily,

On Fri, 8 Nov 2019, Emily Shaffer wrote:
It seems to me that the friendly template text we prefill when someone
opens a pull request in github.com/git/git isn't being fully appreciated
by many interested contributors.
That is probably due to our confusing use of the template as a stop sign
;-)
For some time now, Johannes has been slogging through the list to try
to narrow it down to folks who are still interested in contributing,
and yesterday on #git-devel said he was pretty happy with the progress
so far.
I don't mind it, and quite honestly, it does not take a lot of time,
most of the time.
But to me, this seems like a sort of Sisyphean task - more folks will
want to make contributions and not read the template text, and we will
have more PRs being ignored forever, especially if Johannes decides he
doesn't want to shepherd those changes anymore (I would have decided
that long ago, in his shoes).
The PRs are not bad. What is bad is all those comments on commits coming
in as of recent, some developers thinking that they do not need to
research the best way to reach the Git contributor community and instead
just assuming that adding comments via GitHub's UI is a valid way.

I should probably refrain from trying to help those developers because
it makes me very cranky, but I just don't want Git to be an unfriendly
project.
To that end, I wonder if we should add an Action to automatically
close PRs on that repo. It looks like
https://github.com/dessant/repo-lockdown would do the trick. We could
close incoming PRs automatically with a kind, maybe more succinct or
prescriptive version of the prefill text encouraging folks to open the
exact same PR against gitgitgadget/git instead.
I am rather certain that that would not be a good thing to do.

There are some people who open git/git PRs solely for the PR builds,
others to facilitate code review, and yet others just because it is the
intuitively obvious way to contribute to Git.

Even some long-running PRs are worth keeping open, e.g. the Plan 9
support (which will just take time), the GET_OID_GENTLY one or the one
clarifying the documentation of `git submodule update` (which both need
to wait for a time when the respective contributor is less busy), and
the likes.
Here's the prefilled template now:

  Thanks for taking the time to contribute to Git! Please be advised
  that the Git community does not use github.com for their
  contributions. Instead, we use a mailing list (git@vger.kernel.org)
  for code submissions, code reviews, and bug reports. Nevertheless, you
  can use GitGitGadget (https://gitgitgadget.github.io/) to conveniently
  send your Pull Requests commits to our mailing list.

  Please read the "guidelines for contributing" linked above!

Maybe we can close PRs with something like this:

  Thank you for taking the time to submit a patch!

  However, Git does not accept submissions via GitHub pull requests.

  You can open an identical pull request to this one against
  https://github.com/gitgitgadget/git and follow the instructions there
  to submit it to the Git mailing list, where reviews are performed.

  If you don't want to subscribe to the mailing list, you can keep an
  eye on your patch at https://public-inbox.org/git, or by watching
  comments on your GitGitGadget pull request.

  More info on GitGitGadget: https://gitgitgadget.github.io

I was aiming for "same message, but firmer", and "write down something
so we have a place to start". I look forward to the discussion.

 - Emily

PS: Today we have 17 PRs open against git/git, and I think all of them
have been nudged by dscho in comments to open against GGG instead. Many
are in a state where dscho is sending a ping every few weeks to see if
the committer is interested in following through.

https://github.com/git/git/pulls
They all have been nudged, sometimes to clean up the patch first, or to
suggest that maybe the goal of the PR might not be all that desirable.

Some of the PRs probably can be closed, but as I said, I would like to
think of Git as a friendly project, a helpful one, so I want to err in
favor of talking to the contributors rather than shutting the door in
their face, so to say.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help