将您的想法作为附加包实现。如果您提出的是对核心 R 功能的更改，这当然会困难得多（另一方面，这种更改也更难被接受）。另一方面，您可以在附加包中实现您想要的任何内容，并且它有几个优点。 (1) 您的代码将立即可供所有人使用（如果您在 R-forge、Rforge、GitHub 或 CRAN 上发布）； (2) 这是一种在没有 R 核心支持的情况下开发和完善想法的方法； (3) 即使它从未在 R-core 中被接受，它仍然会作为一个包存在。
尝试找到一个现有的实用程序或“misc”包来贡献（例如，我为 Jim Lemon 的 plotrix 包做出了贡献，它是小型绘图实用程序的编译），并联系维护者/作者。
将您的愿望清单项目发布到 R bug 跟踪器（带有代码附件等）。然而，与使用选项 #1 或 #2 相比，看到它们的人会少得多，因此更有可能在错误跟踪器中消失而永远不会出现。
This is a great question. While really liking R a lot, I find its development model frustrating at times. I would say the best options are
(Based on a comment from @Matifou) Check whether your idea has been previously discussed on [email protected]. Although the archives don't provide a search interface, you can do a Google search prefixed with site:stat.ethz.ch/pipermail/r-devel (e.g. site:stat.ethz.ch/pipermail/r-devel sweep). Nabble also provides a searchable interface but is ugly and ad-heavy ...
post the initial idea (without extensive code) to R-devel and see if you can get discussion/enthusiasm going. You have to be willing to push: for example, I managed to get some additional error-checking incorporated in sweep a few years ago (having it actually complain about mismatched dimensions rather than silently returning the wrong answer), but only after proposing the idea; waiting a week; re-raising the idea; sending some prototype code; testing it to make sure it didn't cause a performance hit; further discussion ...
implement your idea as an add-on package. This is of course much harder if what you propose is a change to core R functionality (on the other hand, that kind of change will also be much harder to get accepted). On the other hand, you can implement just about anything you want in an add-on package, and it has several advantages. (1) Your code will be available for everyone to use immediately (if you post on R-forge, Rforge, GitHub, or CRAN); (2) it is a way for the ideas to get developed and refined without buy-in from R core; (3) even if it never gets accepted in R-core, it will still be around as a package.
Try to find an existing utility or "misc" package to contribute to (for example, I have contributed to Jim Lemon's plotrix package, which is a compilation of small plotting utilities), and contact the maintainer/author.
Post your wish-list items to the R bug tracker (with code attachments etc.). However, they will get seen by many fewer people than if you use options #1 or #2, and as a result are more likely to languish in the bug tracker without ever seeing the light of day.
您不太可能将新功能添加到基础 R 本身中，除非 i) 它激起了 R 核心开发团队之一的兴趣，或者 ii) 是现有功能的扩展，可以改进其工作方式或使其更加高效< em>并且 R Core 的成员对此非常感兴趣。您当然可以根据愿望清单标准提交错误，并提供代码，但如果 R 核心团队不接受全新功能，即使它们附带代码，也不要感到惊讶。
采取这一立场的原因之前已讨论过；即使您提供实现新功能 X 的代码以包含在 R 中，您也会将维护负担转嫁给 R 核心团队，而这些人执行此操作的资源和时间有限。 R 核心团队根据自己的兴趣/研究/需求有效地开发 R 基础。
由于 R 包几乎是一等公民，因此没有理由要求 R 核心实现或包含功能 X 的代码。因此，正如其他人所说，在您自己的包中实现您的想法功能或 将它们贡献给另一个包，该包已经提供了与您的新功能 X 相关的代码。
即使是广泛使用的非常有用的包，例如 data.table 也不太可能在短期内将其纳入基础 R 中 -从中期来看，因为它们增加了代码库的复杂性，给系统带来了维护负担R 核心团队，和/或不会替换现有代码； data.table 提供了类似数据框架的扩展，速度非常快，并且更适合大型数据集和对这些数据的“查询”。但它与 R 的数据框架不兼容，采用不同的约定。它作为一个包可以很好地工作，并且可以继续这样做，而无需在 R 中。
上面描述了我在新功能中看到的情况。对于错误报告，请提交错误报告！然后考虑在 R-Devel 上引用错误报告 ID 进行进一步讨论。为支持错误报告而提供的补丁将使修复错误或添加新功能/增强功能变得更加容易。该补丁应包括需要更改的 R 源以及因此需要更改的任何文档的补丁。该补丁应该针对 R SVN 服务器 中找到的 SVN 树。正如 @BenBolker 在评论中提到的，错误报告最好在 R 的错误报告网站中提交。 R-Devel 上有关该错误的任何讨论都应链接到该错误报告。这样，错误就不会陷入裂缝并被遗漏。
You are very unlikely to get new features into base R itself, unless i) it piques the interest of one of the R Core Development Team, or ii) is an extension of existing functionality that improves the way it works or makes it more efficient and a member of R Core is sufficiently interested. You can of course file a bug under the Wish list criterion, and provide code, but do not be surprised if the R Core Team don't accept totally new features even if they come with code.
The reasons for this stance have been discussed before; Even if you provide code implementing new feature X for inclusion in R, you are passing the maintenance burden on to the R Core Team and these guys have limited resources and time to do this. The R Core Team effectively develop the base of R for their own interests/research/needs.
As R packages are almost first-class citizens, there is little reason to even ask R core to implement or include your code for feature X. So, as others have said, implement your ideas features in your own package or contribute them to another package that already provides code related to your new feature X.
Even incredibly useful packages that are widely used, e.g. data.table are unlikely to make it into base R in the short-medium term because they increase the complexity of the code base, have a maintenance burden on the R Core Team, and/or are not drop in replacements for existing code; data.table provides a data frame-like extension that is incredibly fast and better suited to large data sets and "queries" on those data. It is not compatible with R's data frame though, employing different conventions. It works well as a package and can continue to do so as such without needing to be in R.
The above describes the situation as I see it for new features. For bug reports, file a bug report! Then consider following up with further discussion on R-Devel quoting the bug report ID. Patches provided to support your bug report will make it easier for bugs to be fixed or new features/enhancements added. The patch should include both the R sources that need changing plus a patch to any documentation that needs to change as a result. The patch should be against the SVN tree found at the R SVN server. As @BenBolker mentions in the comments, bug reports are best filed in R's bug reporting website. Any discussion of the bug on R-Devel should link to the bug report. This way bugs don't fall into cracks and get missed.
通常的方法是编写一个包，并将其放到 CRAN 上。 （发送到包列表的所有公告都会复制到 rhelp。）然后在 rhelp（或者也许是 SO）上演示其高效使用将引起人们的注意。我在这里想到的是 Hadley Wickham、Dirk Eddelbuettel、Terry Therneau、Gabor Grothendieck、Frank Harrell 和 Matthew Dowle 多年来的努力，仅列出我想到的前六位贡献者，他们使我的 R 工作更加富有成效。事实上，当我写这个列表时，它变得越来越长，我向其他几个为我经常使用的贡献的人道歉。
The usual way is to write a package, and get it onto CRAN. (All announcements sent to the package list get copied to rhelp.) Then using demonstrating its productive use on rhelp (or perhaps SO) will get it noticed. I'm thinking here of the efforts over the years of Hadley Wickham, Dirk Eddelbuettel, Terry Therneau, Gabor Grothendieck, Frank Harrell, and Matthew Dowle, to name the first six contributors coming to mind who have made my R efforts more productive. Actually as I was writing that list, it kept getting longer and I apologize to several other people that have made contributions I use often.
At useR this year, Brian Ripley told an anecdote that explains the R-core team's stance. He said he accepted a two line patch to a function from a well respected R programmer (John Chambers, if I remember rightly). The two lines of code contained three bugs (!), which he then had to fix. Since then, R-core's default position is to refuse feature requests for R-base, even those with supplied code. (Bug fix requests are fine, as long as you've treble-checked that it really is a bug. Use the R Bug Tracking System for this.)
While it isn't impossible to get something into R-base it is almost always significantly (p < 1e-6) easier to create a package yourself or add to an existing one.
发布评论
评论（4）
这是一个很好的问题。虽然我非常喜欢 R，但有时我发现它的开发模型令人沮丧。我想说最好的选择是
[电子邮件受保护]。尽管存档不提供搜索界面，但您可以进行前缀为site:stat.ethz.ch/pipermail/r-devel的 Google 搜索（例如site:stat.ethz.ch/pipermail/r-devel）。 ch/pipermail/r-devel 扫描）。 Nabble 还提供了一个可搜索的界面，但丑陋且广告较多……sweep中加入了一些额外的错误检查（让它实际上抱怨尺寸不匹配，而不是默默地返回错误的答案） ，但只有在提出想法之后；等待一周；重新提出这个想法；发送一些原型代码；对其进行测试以确保它不会导致性能下降；进一步讨论...plotrix包做出了贡献，它是小型绘图实用程序的编译），并联系维护者/作者。This is a great question. While really liking R a lot, I find its development model frustrating at times. I would say the best options are
[email protected]. Although the archives don't provide a search interface, you can do a Google search prefixed withsite:stat.ethz.ch/pipermail/r-devel(e.g.site:stat.ethz.ch/pipermail/r-devel sweep). Nabble also provides a searchable interface but is ugly and ad-heavy ...sweepa few years ago (having it actually complain about mismatched dimensions rather than silently returning the wrong answer), but only after proposing the idea; waiting a week; re-raising the idea; sending some prototype code; testing it to make sure it didn't cause a performance hit; further discussion ...plotrixpackage, which is a compilation of small plotting utilities), and contact the maintainer/author.您不太可能将新功能添加到基础 R 本身中，除非 i) 它激起了 R 核心开发团队之一的兴趣，或者 ii) 是现有功能的扩展，可以改进其工作方式或使其更加高效< em>并且 R Core 的成员对此非常感兴趣。您当然可以根据愿望清单标准提交错误，并提供代码，但如果 R 核心团队不接受全新功能，即使它们附带代码，也不要感到惊讶。
采取这一立场的原因之前已讨论过；即使您提供实现新功能 X 的代码以包含在 R 中，您也会将维护负担转嫁给 R 核心团队，而这些人执行此操作的资源和时间有限。 R 核心团队根据自己的兴趣/研究/需求有效地开发 R 基础。
由于 R 包几乎是一等公民，因此没有理由要求 R 核心实现或包含功能 X 的代码。因此，正如其他人所说，在您自己的包中实现您的想法功能或 将它们贡献给另一个包，该包已经提供了与您的新功能 X 相关的代码。
即使是广泛使用的非常有用的包，例如 data.table 也不太可能在短期内将其纳入基础 R 中 -从中期来看，因为它们增加了代码库的复杂性，给系统带来了维护负担R 核心团队，和/或不会替换现有代码； data.table 提供了类似数据框架的扩展，速度非常快，并且更适合大型数据集和对这些数据的“查询”。但它与 R 的数据框架不兼容，采用不同的约定。它作为一个包可以很好地工作，并且可以继续这样做，而无需在 R 中。
上面描述了我在新功能中看到的情况。对于错误报告，请提交错误报告！然后考虑在 R-Devel 上引用错误报告 ID 进行进一步讨论。为支持错误报告而提供的补丁将使修复错误或添加新功能/增强功能变得更加容易。该补丁应包括需要更改的 R 源以及因此需要更改的任何文档的补丁。该补丁应该针对 R SVN 服务器 中找到的 SVN 树。正如 @BenBolker 在评论中提到的，错误报告最好在 R 的错误报告网站中提交。 R-Devel 上有关该错误的任何讨论都应链接到该错误报告。这样，错误就不会陷入裂缝并被遗漏。
You are very unlikely to get new features into base R itself, unless i) it piques the interest of one of the R Core Development Team, or ii) is an extension of existing functionality that improves the way it works or makes it more efficient and a member of R Core is sufficiently interested. You can of course file a bug under the Wish list criterion, and provide code, but do not be surprised if the R Core Team don't accept totally new features even if they come with code.
The reasons for this stance have been discussed before; Even if you provide code implementing new feature X for inclusion in R, you are passing the maintenance burden on to the R Core Team and these guys have limited resources and time to do this. The R Core Team effectively develop the base of R for their own interests/research/needs.
As R packages are almost first-class citizens, there is little reason to even ask R core to implement or include your code for feature X. So, as others have said, implement your ideas features in your own package or contribute them to another package that already provides code related to your new feature X.
Even incredibly useful packages that are widely used, e.g. data.table are unlikely to make it into base R in the short-medium term because they increase the complexity of the code base, have a maintenance burden on the R Core Team, and/or are not drop in replacements for existing code; data.table provides a data frame-like extension that is incredibly fast and better suited to large data sets and "queries" on those data. It is not compatible with R's data frame though, employing different conventions. It works well as a package and can continue to do so as such without needing to be in R.
The above describes the situation as I see it for new features. For bug reports, file a bug report! Then consider following up with further discussion on R-Devel quoting the bug report ID. Patches provided to support your bug report will make it easier for bugs to be fixed or new features/enhancements added. The patch should include both the R sources that need changing plus a patch to any documentation that needs to change as a result. The patch should be against the SVN tree found at the R SVN server. As @BenBolker mentions in the comments, bug reports are best filed in R's bug reporting website. Any discussion of the bug on R-Devel should link to the bug report. This way bugs don't fall into cracks and get missed.
通常的方法是编写一个包，并将其放到 CRAN 上。 （发送到包列表的所有公告都会复制到 rhelp。）然后在 rhelp（或者也许是 SO）上演示其高效使用将引起人们的注意。我在这里想到的是 Hadley Wickham、Dirk Eddelbuettel、Terry Therneau、Gabor Grothendieck、Frank Harrell 和 Matthew Dowle 多年来的努力，仅列出我想到的前六位贡献者，他们使我的 R 工作更加富有成效。事实上，当我写这个列表时，它变得越来越长，我向其他几个为我经常使用的贡献的人道歉。
The usual way is to write a package, and get it onto CRAN. (All announcements sent to the package list get copied to rhelp.) Then using demonstrating its productive use on rhelp (or perhaps SO) will get it noticed. I'm thinking here of the efforts over the years of Hadley Wickham, Dirk Eddelbuettel, Terry Therneau, Gabor Grothendieck, Frank Harrell, and Matthew Dowle, to name the first six contributors coming to mind who have made my R efforts more productive. Actually as I was writing that list, it kept getting longer and I apologize to several other people that have made contributions I use often.
在今年的 useR 上，Brian Ripley 讲了一个轶事来解释 R 核心团队的立场。他说他接受了一位备受尊敬的 R 程序员 (John Chambers，如果我没记错的话）。这两行代码包含三个错误（！），他必须修复这些错误。从那时起，R-core 的默认立场是拒绝对 R-base 的功能请求，即使是那些提供了代码的请求。 （错误修复请求没问题，只要您仔细检查它确实是一个错误即可。使用 R 错误跟踪系统 为此。）
虽然将某些东西放入 R-base 中并非不可能，但自己创建包或添加到现有包中几乎总是显着（p < 1e-6）更容易。
At useR this year, Brian Ripley told an anecdote that explains the R-core team's stance. He said he accepted a two line patch to a function from a well respected R programmer (John Chambers, if I remember rightly). The two lines of code contained three bugs (!), which he then had to fix. Since then, R-core's default position is to refuse feature requests for R-base, even those with supplied code. (Bug fix requests are fine, as long as you've treble-checked that it really is a bug. Use the R Bug Tracking System for this.)
While it isn't impossible to get something into R-base it is almost always significantly (p < 1e-6) easier to create a package yourself or add to an existing one.