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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Thu, 7 Jan 2021, Junio C Hamano wrote:

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

I fear that we're striking the balance on the side of expecting too much
knowledge about project-specific lore from contributors.

My goal with GitGitGadget was to allow competent contributors to focus on
addressing their pet peeve with Git, to produce a stellar patch with an
outstanding description and get that integrated into the next major Git
version, and not have to learn about the culture and mechanics of our
patch review process for what may very well be their single contribution
to Git.

Just look at the wall of text GitGitGadget first-time users _already_ have
to read through, and it does not even catch half of what is relevant for
every single contributor:
https://github.com/gitgitgadget/gitgitgadget/blob/HEAD/res/WELCOME.md

Note that this wall of text does not even begin to answer questions such
as "how do I know when this patch is accepted?".

The suggestion that the contributor should Cc: you explicitly when the
contribution is supposedly ready to advance (according to a set of rules
that is not formalized anywhere that I know of) could potentially be added
to that wall of text, but I doubt that it will make it easier to
contribute even for the most advanced and dedicated software engineers.

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

We already have a ticket suggesting to add reviewers:
https://github.com/gitgitgadget/gitgitgadget/issues/219

With this suggestion, too, we could go and extend that wall of text even
further and expect contributors to just know what they are supposed to do.
But I don't see how that would make this process more inviting to new
contributors.

BTW I get the sense that many Git mailing list regulars have this idea
that making the review process easier for one-time contributors would
invite too many low-quality contributions. However, I see the exact
opposite: professional software engineers I talk to refuse to jump through
all those hoops, even if they would be quite capable of producing a
stellar patch within no time. At the same time I see a lot of less
experienced developers delighting in the struggle^Wchallenge to set up
`git send-email` correctly _just_ to earn bragging rights to have their
typo fix in Git's commit history. I am exaggerating here, of course, to
make a point. And I think this is a very valid point. We lose
contributions (and potential future reviewers) because we make it harder
than necessary to contribute to Git.

Ciao,
Dscho