On Mon, Apr 15, 2013 at 4:00 PM, Thomas E Enebo <tom.enebo / gmail.com> 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