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

Hi Taylor,

On Fri, 8 Jan 2021, Taylor Blau wrote:

On Fri, Jan 08, 2021 at 03:56:20PM +0100, Johannes Schindelin wrote:

quoted

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

quoted

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.

I think that this could be reasonably addressed. When someone opens a PR
(but before the hit /submit), GGG could say:

    Your change touches these files, and so suggested reviewers include
    X, Y, Z. When you believe your submission is in its last round,
    please also include the maintainer, M.

That is an option.

Is it the best option to reach the goal where competent software engineers
can focus on improving Git's source code?

Maybe it is not possible do automate what I wish for.

quoted

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.

Yeah, I agree that adding this as a separate step does not make sense,
since it's hard to discover such things (especially by individuals who
merely want to send a single contribution to the project). Having this
happen automatically upon creating a PR would make more sense to me.

Right.

I always have this contribution in mind: Improve the readability of `log
--graph` output (https://github.com/gitgitgadget/git/pull/383)

This was an excellent contribution. I doubt that we would have received it
without GitGitGadget, as the contributor could really focus on the code
change instead of the contribution logistics.

We did not exactly make it easy, and I fear that we are losing a lot of
potential contributions because of that.

For example, Git is often ridiculed for being hard to use, and I can
understand. There has been research into ways to improve that, but little
of that research resulted in contributions on the Git mailing list. I
would not at all be surprised if that was because of the review process we
put up.

Usability is only one area where I think we would benefit from attracting
talent. Accessibility is another one. Or UI improvements (consistency,
self-explanatory navigation, etc). Or...

Ciao,
Dscho