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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 9, 2016, 17:34 UTC
Message-ID: <xmqqh9atc0do.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160809113703.57irthzzpg6j3dmv@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes all what I wanted to say, and a lot more, so I don't have to say much ;-)

Show 13 quoted lines

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