Unfortunately, I find this an issue of projection of overlapping
concerns.   If I am new to reporting issues to MRI and I want a new feature
then I will go to the most obvious place.  I might read the appropriate
documentation on how to submit issues, but let's face it...most people
don't.  Regardless of what is ideal, I think any proposed solution should
make the burden of handling a misreported issue (assuming ruby-trunk for
features is inappropriate) simple.

Whether tags are used to mark if something is a feature or whether there is
a simple process for converting those to CommonRuby I think any solution
has to acknowledge that people will probably predominantly put it in the
wrong place and some burden will be placed on the people maintaining and
triaging incoming issues.

As an implementer of an alternative Ruby runtime, I do desire a simple way
of seeing all changes to language features and API features.  It seems like
technology can solve this without making people do any extra work.  At
least, all new API changes or new language features should get marked in
any system in a way for people to query those easily and contribute to the
process.

-Tom



On Thu, Apr 11, 2013 at 3:00 PM, Charles Oliver Nutter
<headius / headius.com>wrote:

> I think we need to do more to encourage the use of the CommonRuby
> project in bugs.ruby-lang.org.
>
> There are currently 429 "feature" issues open in ruby-trunk. The
> majority of these would affect all Ruby implementations, and are not
> specific to MRI. I believe ruby-trunk should only house bugs and
> features that are specific to MRI (or at least, they initially seem to
> apply only to MRI).
>
> What can we do to encourage folks to use CommonRuby more?
>
> * A top-level link for CommonRuby that clearly states any new
> user-visible Ruby language/library features (or feature changes)
> should be filed here.
> * Migrate existing feature requests to CommonRuby if they apply to
> other Ruby implementations.
> * A period of auditing feature requests filed against ruby-trunk and
> other projects, migrating them to CommonRuby or recommending re-filing
> in CommonRuby.
>
> Encouraging use of CommonRuby would do a lot to show that the
> implementations are collaborating on the future of Ruby, and it would
> help us implementers filter out MRI-specific bugs/features from those
> that will affect our implementations.
>
> Thoughts?
>
> - Charlie
>
>


-- 
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo / gmail.com