Re: RFC: Moving git-gui development to GitHub

[Junio C Hamano <gitster@pobox.com>]

Pratyush Yadav <me@yadavpratyush.com> writes:

> Arguments in favor of moving to GitHub:
>
> - Easier for new and one-off contributors.

It is uptimately up to you, the maintainer of the project, but
personally I feel "new and one-off" are way overvalued, after
considering if it serves the project and its users better to make it
easier for "new and one-off" contributors, or if it serves these
"new and one-off" contributors more than it benefits the project and
its users.

A quick rule of thumb I use is that it is worth spending my time on
training a new contributor (with hand-holding on workflows,
conventions, etc.) if it takes less than 3 times of effort compared
to doing the task myself (if I had infinite amount of time, that is)
for the first few topics the contributor works on.  You can usually
tell good ones after a few e-mail exchanges---their brilliance shine
through, even before they become familiar with particular conventions
of the project.

> - We reduce the noise on the Git list. Most people subscribed to the 
>   list probably don't care about git-gui. So all git-gui related emails 
>   are essentially noise for them. And while the volume has been 
>   relatively low, it is not negligible.

As long as the subject is marked clearly that the discussion is
about git-gui, it is easy to skip such an e-mail thread if a reader
is not interested in it.

This is related to the "we lose the audience" item on the other
list, but as a project that consumes the product of the git-core,
the needs of git-gui developers are of interest to git-core
developers.  If I am not mistaken, I think the recent topic about
logs/HEAD.lock by Dscho was to support what he's doing with git-gui,
and what the particular git-gui topic wanted from us happened to be
simple enough that we didn't have to dig too deeply the consumer
side in order to decide if the changes to git-core made sense, but
that may not always the case.

With a git-gui developer who is less experienced with git-core than
Dscho, it would be entirely plausible that the developer would try
to solve an issue on git-gui side with a lot more effort than
necessary because the developer is not familiar with git yet, and it
may turn out that it can be achieved easily with much less effort on
the git-gui side if we made a minimum and generic change on git-core
side.  The other way around is also possible; an inexperienced
git-gui developer may dream that miracles would solve an issue at
hand, and expect that git-core side may bend over backwards to
support an unreasonable one-off feature, which may never happen.