Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

[Philip Oakley <philipoakley@iee.email>]

Hi Dscho,

On 06/10/2019 21:27, Johannes Schindelin wrote:
> Let me provide you with some data, then. Granted, it's not necessarily
> all Git GUI, but it includes Git GUI patches, too: Git for Windows'
> contributions.
>
> As should be well-known, I try to follow Postel's Law when it comes to
> Git for Windows' patches: be lenient in the input, strict in the output.
> As such, I don't force contributors to use GitHub PRs (although that is
> certainly encouraged by virtue of Git for Windows' source code being
> hosted on GitHub), or send patches, or send pull requests to their own
> public repositories or bundles sent to the mailing list. I accept them
> all. At least that is the idea.
>
> I cannot tell you how many contributions came in via GitHub PRs. I can
> tell precisely you how many contributions were made_not_  using GitHub
> PRs. One one hand. Actually, on zero hands.
>
> So clearly, at least Git for Windows' contributors (including some who
> provided Git GUI patches) are much more comfortable with the PR workflow
> than with the mailing list-based workflow.
Just to say that most of the numbers are governed by the strength and 
experience with the particular infrastructures.

Tonight I had wanted to send in patches for G-f-W because of branch 
placement confusion. Eventually I had to throw in an extra rebase to a 
fresh branch, just so I could create a PR, all because of the zero 
experience you mentioned with using a G-f-W 2-patch series.

The Git list is strongly patch based and it's infrastructure works 
adequately, even if it is 'antiquated' by millennial standards.

The G-f-W interaction is almost totally via Github, and a few 
notification emails and occasional google-groups interactions. It's 
still imperfect, just like the Git list emails, but with it's own, 
different issues for trying to build its community.

Most community bondings actually build through their common adversity, 
rather than the apparent ease of joining/leaving.

The main bit I wanted to say (I think), was that having a maintainer who 
accepts input is probably the most important aspect, no matter the 
particular route used for the input. So thanks to both of you (Dscho, 
Pratyush) for *facilitating* the contribution flow.
-- 
Philip