tannerburson

> Here's the idea: companies that rely on Ruby contribute money to a pool. The board of directors > authorizes spending money out of that pool. They authorize this money towards supporting core > Ruby infrastructure and projects. All of this is through a non-profit, so it's tax deductible for > everyone.

That summary should appear somewhere on the website, as it includes the core of what you're doing much more succinctly than anything I found clicking through the links.

Thanks for the details, and thanks for working to improve the Ruby community!

As someone who relies heavily on the Ruby ecosystem to do my job day-to-day, this is really interesting. But I can't tell from the site what exactly it's doing. Are the membership "dues" going to fund an individual (André?) or a team to work on this full-time? Part-Time? Can I influence with my membership which projects my money is allocated towards? Will the accounting for the money be published within the "membership"?

As it's presented, I have too many questions to even begin to be able to put this in front of my organization and feel comfortable that what I'm pitching provides good value for the money spent.

  "Think of YAML as a human readable Marshal."

That's what people missed. YAML is a marshaling format, full stop. The Ruby community has to absorb this idea, and quickly, because YAML is everywhere.

So you're wanting to reinvent XMPP?

So a guy hacks github, he's a hero. A guy hacks a bunch of media organizations, and he's a villain. I really don't understand the groupthink these days.

How is one of these okay, and the other not?

I agree, the original piece was a decent explanation of how to refactor some helper type code into a more Presenter like model. But he completely skipped out on the question of why it's a useful thing, and when it's a good fit. If that post had been by DHH or another Rails core member, we'd see it instantly picked up into the current cargo-cult trend of the month.

That said, I do appreciate Steve's work on finding ways outside of "the one true path" to simplify Ruby code, and hope he'll continue writing these sorts of things going forward. If nothing else, the discussion surrounding the technique and it's alternatives is extremely worthwhile.