git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Emily Shaffer <emilyshaffer@google.com>
Cc: git@vger.kernel.org, peff@peff.net
Subject: Re: Should we auto-close PRs on git/git?
Date: Tue, 12 Nov 2019 20:11:06 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1911121946480.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20191109020037.GB60198@google.com>

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

  parent reply	other threads:[~2019-11-12 19:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-09  2:00 Should we auto-close PRs on git/git? Emily Shaffer
2019-11-09  4:55 ` Junio C Hamano
2019-11-13  5:29   ` Stephen Smith
2019-11-12 19:11 ` Johannes Schindelin [this message]
2019-11-13  1:10   ` Jeff King
2019-11-13 12:04     ` Johannes Schindelin
2019-11-14  7:41       ` Jeff King
2019-11-14 23:03         ` Johannes Schindelin
2019-11-18 18:37           ` GitGitGadget on git/git, was " Johannes Schindelin
2019-11-21 10:54             ` Jeff King
2019-11-22 13:50               ` Johannes Schindelin
2019-11-22 14:43                 ` Johannes Schindelin
2019-11-25 14:30                 ` Jeff King
2019-11-26 20:55                   ` Johannes Schindelin
2019-11-26 21:56                     ` Eric Wong
2019-11-26 22:22                       ` Johannes Schindelin
2019-11-26 22:40                         ` Eric Wong
2019-11-26 22:52                           ` Johannes Schindelin
2019-11-26 23:58                             ` Eric Wong
2019-11-27  1:52                       ` Junio C Hamano
2019-11-27  2:37                         ` Eric Wong
2019-11-13 21:09   ` Emily Shaffer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1911121946480.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).