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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxxxxx" 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux