git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Nika Layzell via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Nika Layzell" <nika@thelayzells.com>
Subject: Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode
Date: Thu, 07 Jan 2021 13:25:23 -0800	[thread overview]
Message-ID: <xmqqft3cl9rw.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2101071718470.2213@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Thu, 7 Jan 2021 17:20:22 +0100 (CET)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I would not call that a fix. As mentioned, I could not come up with a way
> to Cc: Junio only when appropriate in a way that wouldn't surprise new
> users. So yes, I disabled the auto-Cc:ing, with no appropriate
> replacement.
>
>> I.e. now users need to explicitly add "cc: gitster@pobox.com" to the
>> description, no? So isn't in the same as for us who use the
>> format-patch/send-email flow in this regard?
>
> Right. And that is... intuitive? If you have to read the manual, the
> design is broken.

Let's step back and think when a patch submitter wants to CC
anybody.  People explicitly Cc area experts when touching certain
part of the codebase, so that they can ask for their input.  People
also explicitly Cc the maintainer when they see the reviewers
reached a consensus that it is a good idea to apply the patch.
These CC has value only because they came from conscious decision
by the submitter---they actively asks for help and that nudges the
recipient of CC to help them.

Even without such Cc:, stakeholders (both area experts and the
maintainer) often notice noteworthy patches and discussions, so
between having CC that is thrown around freely without thought and
crowds recipient's inbox and not having such thoughtless CC at all,
the latter is vastly preferred.  The former just diminishes the
value of Cc that are added manually by thoughtful people.  

In short, "now users need to explicitly add" is a GOOD thing.  

The best is to have only thoughtful CC, the second best is not to
have automated CC at all, and the worst is always throw automated CC
to hurt others who try to make CC mean something by making judicious
use of it.

Having said all that.

We may not be able to automate the thinking part to decide when
submitter may want to get help, but an automation can help by giving
the submitter cues and clues when to ask for help and from whom.

Is there a point in the end-user experience flow, starting at the
time when they push their proposed change to their repository, throw
a pull request at GitHub, say "/submit", and then GGG finally sends
out a patch e-mail, where the GGG machinery can inspect the change
and give the user (preferrably before the user says /submit) a hint
that says "you may want to add Cc: to these people in such and such
case, and if you think the situation falls into these cases, tell me
so by saying /submit-with-suggested-cc instead of the usual
/submit"?

And "these people" may include those who touched the affected code
within the past 6 months, and it may also include the maintainer
when the pull request is in its second or later iteration.

Thanks.

  reply	other threads:[~2021-01-07 21:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23 19:56 [PATCH 0/1] add--interactive: skip index refresh in reset patch mode Nika Layzell via GitGitGadget
2019-11-23 19:56 ` [PATCH 1/1] " Nika Layzell via GitGitGadget
2019-11-24  6:01 ` [PATCH 0/1] " Junio C Hamano
2019-11-25 14:24   ` Johannes Schindelin
2019-11-25 14:45     ` Johannes Schindelin
2019-11-26  1:13       ` Junio C Hamano
2021-01-07 14:18         ` Cc'ing the Git maintainer on GitGitGadget contributions, was " Johannes Schindelin
2021-01-07 14:57           ` Ævar Arnfjörð Bjarmason
2021-01-07 16:20             ` Johannes Schindelin
2021-01-07 21:25               ` Junio C Hamano [this message]
2021-01-08 14:56                 ` Johannes Schindelin
2021-01-08 19:48                   ` Junio C Hamano
2021-01-10 12:02                     ` Johannes Schindelin
2021-01-08 20:08                   ` Taylor Blau
2021-01-10 12:21                     ` Johannes Schindelin
2021-01-10 20:18                       ` Junio C Hamano
2021-01-11 19:18                         ` Taylor Blau
2021-01-12 23:22                           ` Junio C Hamano
2021-01-14  6:32                         ` 胡哲宁
2019-11-26  1:12     ` Junio C Hamano

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=xmqqft3cl9rw.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=nika@thelayzells.com \
    /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).