Re: Cc'ing the Git maintainer on GitGitGadget contributions, was Re: [PATCH 0/1] add--interactive: skip index refresh in reset patch mode

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 7, 2021, 21:25 UTC
Message-ID: <xmqqft3cl9rw.fsf@gitster.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.2101071718470.2213@tvgsbejvaqbjf.bet>

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

Show 11 quoted lines

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