Subject: Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

From: Junio C Hamano <[email-masked]>
Date: Tue, 09 Aug 2016 10:34:11 -0700

Jeff King <[email-masked]> writes all what I wanted to say, and a lot
more, so I don't have to say much ;-)

>  - I really like the flow of having conversations next to patches. I can
>    look at the index of the mailing list folder and see what people are
>    talking about, how big the threads are, etc, at a glance. Moving
>    between messages and threads involve single keystrokes.
>
>    Similarly, having local storage is _fast_. I think GitHub is fine for
>    a web app. But when I'm reading a high-volume mailing list, I really
>    want to flip around quickly. If there's even 500ms to get to the next
>    message or thread, it feels clunky and slow to me. Obviously I spend
>    more than 500ms _reading_ most messages (though for some I see the
>    first paragraph and immediately jump away). It's just the latency
>    when I've decided I'm done with one thing and want to move to the
>    next.

Viewing threads in a threaded mail client to help prioritizing
various topics being discussed is what I value the most and I am
not sure how I can be as efficient with the pull-request page.

>    The threading in GitHub comments and pull requests is also not great.
>    Each PR or issue is its own thread, but it's totally flat inside.
>    There are no sub-threads to organize discussion, and it's sometimes
>    hard to see what people are replying to.

It may be a good UI that is optimized for drive-by contributors.  It
is just that it is not very well suited (compared to mailing list
discussions) to conduct high-volume exchange of ideas and changes
efficiently.