Pratyush Yadav <me@xxxxxxxxxxxxxxxxx> 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.
