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

Whether tags are used to mark if something is a feature or whethe= r 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.=A0

As an implementer of an alternative Ruby runtime, I do desire a s= imple way of seeing all changes to language features and API features.=A0 I= t seems like technology can solve this without making people do any extra w= ork.=A0 At least, all new API changes or new language features should get m= arked in any system in a way for people to query those easily and contribut= e 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.rub= y-lang.org.

There are currently 429 "feature" issues open in ruby-trunk. The<= br> 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=A0 =A0 =A0=A0 twitter: tom_enebo=
mail: tom.enebo@gmail.com