Hello

[Alexander Clark]

My name is Alexander Clark. I wanted to introduce myself and offer to help out in any way I can. Seriously, any way. I'll write documentation, write specs, write ruby, fetch coffee*, answer questions, look into issues, whatever is useful.

I've been building with Rails for about 3 years now and using RSpec for most of that time. I've also used RSpec 1 with Rails 2.3 quite a bit due to legacy code at my day job.

Per the newsletter I've updated a couple of personal projects - one Rails 3.2, one Rails 4 to 3.0.0.beta1 and everything seems to be passing with no warnings.

If there's anything specific that needs testing, let me know and I'll see what I can do.

Cheers,

Alexander

* $3.00 out of pocket expense limit per occurrence including coffee, gas, and plane ticket ;)

[Xavier Shay]

Hi Alex,

That all sounds fantastic! A good place to start is checking the issues labeled "small" on each project:

https://github.com/rspec/rspec-core/issues?labels=small&page=1&state=open
https://github.com/rspec/rspec-mocks/issues?labels=small&page=1&state=open
https://github.com/rspec/rspec-expectations/issues?labels=small&page=1&state=open

Triaging issues is also really useful, particularly ones that haven't seen any activity recently. Can you repro bugs on latest master? What is the next obvious step?

I'm on IRC in #rspec most of today if you wanted to chat.

Cheers,
Xavier

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/d4e096de-c304-4bf6-a97d-e700094453c4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Myron Marston]

Hello Alexander!  Thanks for offering to help out.  In addition to what Xavier said, here's some specific things you (or anyone, really) can do to help:

• Improve the documentation of any of the rspec gems.  A good starting point for this is to checkout one of the rspec repos and run `yard stats --list-undoc`.  This will give a list of classes and methods that are not documented.  A lot of the undoc'd stuff is not intended to be part of the public API (and should be labeled with `# @api private` as a means to document that it's not part of the public API).  If there's something you're unsure about, you can either leave it be and focus on the parts that you know enough about to document, or take a stab at it anyway and open the PR as a starting point to discuss.  We usually iterate on PRs quite a bit anyway.
• Trying out the pre-releases is super helpful, and it sounds like you are already doing that.  If you're feeling particularly cutting edge, you can take this a step further and pull the gems directly from the master branches on github.  Then you can report any issues you notice soon after the issue arises.

Thanks!

Myron