[ruby-core:54297] Re: Encouraging use of CommonRuby

On Mon, Apr 15, 2013 at 4:00 PM, Thomas E Enebo <[e-mail]> wrote:
> 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.

Honestly, I think having a big top-level project that says "FEATURES
GO HERE" would be far less confusing than the current situation, where
people don't know if they should file under "trunk" or "ruby193"
(since that's what they're running) or what.

I will grant that the separate project would work best if
bugs-that-become-features can be migrated trivially. I think that's
possible, based on other replies in this thread.

> 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.

The problem with tags is that they're usually unstructured (if it's an
open tagging system) or they're completely different for features and
bugs (approved_by_matz makes no sense as a tag for bugs; "reported
version" makes no sense as a field for features).

The metadata that goes along with a feature discussion/approval
process is (in my mind) quite different from the metadata that goes
along with bugs. Moving features to CommonRuby will allow us to evolve
that metadata to make the process more visible and easier to track
without major upheaval of current processes.

> 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.

I agree that we need better metadata in any case. I just don't believe
that single bits of information (has tag or does not have tag) provide
enough structure for an ongoing feature/design process.

- Charlie