Speakerline

Edit a proposal

Title Tags (comma-separated, max 3) Body

## Abstract
There are gems out there solving very common problems that could easily be contributed back to Ruby itself. Suggesting a new Ruby feature isn't as daunting as it sounds. As long as you're diligent, you too can push ruby forward.

## Details
After an introduction covering a few examples of gems that solve problems which could be reasonably submitted as Ruby features, I'll look at gems that became Ruby feature in the past.

The linearly, I'll present the process for submitting a new feature to bugs.ruby-lang.org.

## Outline

### 1 — Research
Determine whether such a feature has been suggested in the past and why it may have been rejected originally; or to find out how the Ruby community has been coping with the absence of the suggested feature (gems, ad-hoc solutions, etc).

### 2 — Sanity Check
Verify that the feature suggestion actually makes sense by running it by other members of the Ruby community before proposing it to the core team in order to respect their time.

### 3 — Proposal
Craft a succinct and intelligible proposal (I'll show some bad and good examples) for the core team to examine, with a clear use case, examples, and — why not — a tentative patch if you have some C skills.

### 4 — Support
An essential phase in order to gather community support by for example writing a longer form blog post explaining the motivations behind the proposal in order to seek out other Ruby developers who may benefit from the proposal or have helpful suggestions to make on the proposal issue inside bugs.ruby-lang.org.

### 5 — Follow-through
After members of the core team and other community members contribute feedback to the proposal, offer any requested clarification or remain civil if you're turned down.

### 6 — Documentation/Promotion
If the feature is accepted and scheduled for a Ruby release, take the time to document it thoroughly to increase the chances that other Ruby developers will discover the feature or hear about it. And why not start conversation with gem maintainers in order to tell them about the new feature and how it could make their lives easier.

### 7 — Maintenance
If conflicting use cases ever arise from other (past or future) Ruby feature, participate in the resolution process proactively.

## Conversation

I'd love to close the talk with a short conversation involving the audience in order to identify low-hanging fruits we could propose solutions for.

## Pitch

Whenever something doesn't make sense in Ruby, some either dismiss the language as a whole or build a gem to solve the solution immediately. Taking the time to try to push Ruby forward would potentially benefit the community as a whole. I want to show fellow Rubyists that it's not nearly as complicated as they might imagine to suggest new Ruby features.

After noticing that some gems were doing work that Ruby itself should be doing, I wrote a simple blog post proposal earlier this year. I talked about it with a few people in Ruby core and I'm about to submit a proper feature suggestion myself so this talk will be based (partly) on personal experience.

I've been following Ruby core proceedings closely for the past year thanks to core meeting notes and help from some contributors. I'd love to make this part of the process more accessible to the community.

Back to Speaker Directory