ruby-on-rails - 在 Github 上 fork Ruby/Rails gem 的正确协议(protocol)/礼仪是什么，可以作为持续的并行 fork 进行维护？

Question

最近我使用了一个由单个开发人员创建的不错的 gem，它托管在 Github 上。

在我的工作中，我不得不对它进行一些实质性的修改，添加一些改进。有些是特定于项目的，有些是特定于 gem 的，还有一些是独立的改进。

对于特定于 gem 的改进(例如，错误修复)，我 fork 了存储库，应用了修复，并提出了拉取请求。

然后，然而，我注意到独立的改进有点属于原始 gem 的并行、持续的分支类别。更清楚地说，你以前见过它；我重写了原始 gem 的 View 以使用 Twitter Bootstrap 框架。因此，我也将它推送到了 Github，但是，当然，我没有提出拉取请求——相反，我更新了 README 以解释不同之处，并感谢 gem 的原作者。

我的问题是，在这种情况下还应该做什么，假设 gem 是其他任何人都想使用的东西并且要在 ruby​​gems 上发布，等等？我是否应该简单地编辑 .gemspec 并保持原始作者的信息完整，但将我的信息增加到作者/电子邮件字段，并重写其他更改的内容？还是应该完全重写 .gemspec？

另外，如果原始发行版有远程测试框架(如 travis.yml)，这些是应该删除还是保留？

是否还有其他通常必须更改/重新创建的文件？

到目前为止我已经更新

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

最后一个本身提出了一个单独的奖励问题，版本控制在并行发行版中是如何工作的？

Answer 1

听起来您已经正确地处理了错误修复/ fork 。

根据 gem 的许可，将其发布为 yourname-originalname。

您做出了整个社区可能感兴趣的实质性更改，这是公认的 fork 和发布标准。

它还解决了您的奖励问题。更改任何你想要的版本。它现在基本上是一个新项目。当然，还是要归功于原始开发者 :)