>> * Opens Ruby development to a wider range of contributors. Ruby- and
>> non-Ruby-based projects alike have shown a dramatic upswing in contributions
>> after moving to Git.
>
> This is scientifically proven?

Heh, I confess not to have orchestrated a wide-scale statistical study
on the matter, no. The anecdotal evidence, however, is very much in
keeping with my claim. The experience of Rails
(http://www.igvita.com/2009/01/27/ruby-swarms-visualizing-rails-git/)
and the Linux kernel
(http://www.linuxfoundation.org/publications/whowriteslinux.pdf)
mirror those of other major projects which made the transition. If you
require numerical arguments to be convinced, I will endeavor to
assemble the requisite data.

>> * Allows tickets to be handled by de facto topic branch maintainers. A
>> contributor interested in improving documentation, for example, could review
>> the documentation tickets, apply the relevant patches to his 'doc' branch,
>> then propose it be merged periodically. The core team could, and should,
>> still monitor this branch's progress, and intercede where necessary.
>> Ultimately, development would suffer less from the current bottleneck
>> effect, allowing contributers to play a larger role.
>
> This sounds like more work than what happens now. How is more work supposed
> to make ruby development faster?

It is indeed more work than happens now. Now being the time of severe
ticket backlogs on Redmine (the statistics for which I cannot provide
as Redmine is, again, unresponsive), and more requests than I have the
decency to reference languishing without so much as an acknowledgment.
I am but an insignificant player, yet can vouch that I have a
multitude of tickets in my buffer which remain locally because
similar, submitted requests have been left to perish. The workflow we
propose will alleviate this situation by distributing this work to
extra and eager pairs of hands. It will require slightly more work to
the benefit of significantly more progress.

>> * Complicated feature proposals would take the form of branches. This
>> solves the current problem of patches rotting in Redmine because `rebase`
>> and Git's superior merging capability allow the patch to be kept in step
>> with the trunk. Further, this allows parties interested in the feature to
>> collaborate on the branch; only submitting a pull request when they deemt
>> mature.
>
> Can't this be done now with git-svn?

Such an approach can be poorly approximated by an intermediate user of
said gateway. But as the MBARI patches, the recent interest in the
win32-unicode branch, my trifling work on Onigurma, and many more
cases in recent memory serve to illustrate, this process is clumsy and
inelegant.

Put simply, while git-svn may flawlessly translate SVN to Git; the
converse can never be true: Git users must degrade their work, casting
aside the rich metadata Git supplies, so SVN can stomach it.  Your
argument may be more properly put if reversed: Can the few who prefer
to retain the SVN toolset be accommodated by git-svn in conjunction
with a Git repository? Why yes, they can.

>> * Working with the trunk becomes more pleasurable due to Git's advanced
>> toolset and significant performance benefits.
>
>
> I've found git less pleasurable and it's "advanced" toolset cumbersome and
> unfriendly. It's largely been a performance detriment to me.

Perhaps if you could explain your difficulties, we may assist you in
overcoming them? If you desire to use Git as SVN, the interface is so
similar, that if one establishes compatiability aliases, the key
remaining difference is Git's superior speed. By "performance
benefits", I was referring to these magnificent speed benefits, which
are especially noticeable with large repositories such as Ruby's. :-)