git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
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: Sat, 09 Nov 2019 13:55:32 +0900	[thread overview]
Message-ID: <xmqqtv7dlkcb.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20191109020037.GB60198@google.com> (Emily Shaffer's message of "Fri, 8 Nov 2019 18:00:37 -0800")

Emily Shaffer <emilyshaffer@google.com> writes:

> 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. 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.
>
> But to me, this seems like a sort of Sisyphean task ...

Yeah, I would not stop Dscho if he likes doing so, but it does sound
like a waste of talent.

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

Personally, I think that it would not help, it would be a waste of
our time to set up, and it would be a waste of our attention having
to worry about giving yet another external read/write access to PRs
to a third-party tool.

I've looked at those PRs, and noticed that the issues that the ones
with unedited prefilled template try to address are mostly those
that would cost more to give help polishing the patch into an
acceptable shape than some of us redo them outselves (more
clarifications below).

Quite honestly, "drive-by contribution" is overrated.  Surely it is
nice if those little typoes and forgotten free()s and off-by-ones
got fixed by somebody without taking too much of our attention, and
it would be nicer if we can help those who started from "drive-by"
status eventually grow to full fledged contributors.

But step back and think about these two a bit.

Those tiny typoes, missing calls to free(), etc. that are low
hanging fruits tend to be "bugs" that have only one obvious way to
"fix", without leaving much room to express the patch in any other
way.  It's not like that they now own the bug and the right to make
a patch to fix it because they found and sent a PR first.  If
somebody else makes the same fix with patch text that happens to be
identical, that is perfectly fine.  The _only_ real contribution to
us made by such a PR is to let us know where such a trivial problem
resides; once that is identified, anybody would fix it the same way.

It would be far more effective use of the time of the community to
make the same fix by any member who already knows how such a patch
should look like, while giving a proper credit for discovering the
issue.

I can already hear people saying that by investing to educate the
original drive-by contributors (instead of "stealing" their patch
and doing it outselves) would yield a larger value in the longer
term, as it could help grow the drive-by contributors into our
community.  I would agree with that argument in principle, but
I do not think that would apply to the drive-by stuff with unedited
prefilled template still intact.

The thing is, I do not think we can expect those who do not even
bother to read the prefilled template to grow to full fledged
contributors.  Certainly before they start paying attention to what
are told to them.

So, I would certainly not veto auto-closing, but I do not think it
would help.

Thanks.

  reply	other threads:[~2019-11-09  4:55 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 [this message]
2019-11-13  5:29   ` Stephen Smith
2019-11-12 19:11 ` Johannes Schindelin
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=xmqqtv7dlkcb.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --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).