What is the correct protocol/etiquette for forking a Ruby/Rails gem on Github that may be maintained as an ongoing, parallel fork?

Question

Recently I used a nice gem created by a single developer, which is hosted on Github.

During my work, I had to modify it somewhat substantially, adding some improvements. Some were project-specific, others were gem-specific, and others were, well, standalone improvements.

For the gem-specific improvements (e.g., a bugfix), I forked the repo, applied the fix, and made a pull request.

Then, however, I noticed that the standalone improvements kind of fell into the category of a parallel, ongoing, fork of the original gem. To be clearer, you've seen it before; I rewrote the views of the original gem to work with the Twitter Bootstrap framework. So, I pushed this up to Github as well, but, of course, didn't make a pull request–instead, I updated the README to explain what was different, and to credit the original author of the gem.

My question is, what else is one supposed to do in this case, presuming the gem is something anyone else wants to use and is to be published on rubygems, etc? Should I simply edit the .gemspec and keep the original author's info intact, but augment my information to the authors/email fields, and rewrite whatever else has changed? Or should one completely rewrite the .gemspec?

Also, if the original distro has in place remote testing frameworks (like travis.yml), should these be removed, or left in place?

Are there other files that generally must be changed/recreated?

So far I have updated

.gemspec
README.md
CHANGELOG.md
lib/libraryname/VERSION.rb #called as a constant in .gemspec

The last one raises a separate bonus question in itself, how does versioning work in parallel distros?

Answer 1

Sounds like you handled the bugfix / fork properly already.

Depending on the license of the gem, release it as yourname-originalname.

You've made substantial changes which the community as a whole may be interested in and this is the accepted standard for forking and releasing.

It also solves your bonus question. Change whatever you want for your release. It's essentially a new project now. Still good to credit the original dev of course :)