# Contributing to Rubinius
There are as many ways to help with Rubinius as there are people. The
following are just some ideas. Understand that Rubinius is a large,
fast-moving project, so you will likely need to coordinate your efforts with
others. A great deal of communication occurs on the #rubinius IRC channel.
There are logs for the channel and a mailing list. See link:community.txt
## Triage Tickets
* Revive or close old tickets.
* Build minimalist cases that reproduce the bugs
## Write docs
Annoy people on the channel by asking how things work. Then write them down so
that the next doc writer can be annoying with other questions.
## Fix Failing Specs
1. Run `bin/mspec tag --list fails` to show specs tagged as failing
1. Run `bin/mspec spec/frozen/1.8/<some dir>`
## Write Specs
1. Run `bin/mspec tag --list incomplete` to show specs that have been tagged
as incomplete. These specs may simply need review, or there could be specs
missing for a particular class.
1. Find unspecified behaviors. Be vicious! Once you found a nice
corner-case, write a spec. See 0Howto - Write a
spec](/howto/write_a_spec.html)
1. Fix the specs by running them against MatzRuby. Use `rake
spec:check` OR `bin/mspec -t ruby spec/ruby` to run all the specs that
should pass on MatzRuby
## Run Your Code
Your code it often more vicious than the specs. Run your pet project under
rubinius and report crashes! See [Howto - Write a
ticket](/howto/write_a_ticket.html)
## Cleanup Code
Search for tags like TODO, HACK, FIXME in the code and fix them. Once you're
finished, submit a ticket with the [PATCH] tag and a small description. See
[Howto - Write a ticket](/howto/write_a_ticket.html)
I use : `grep -re "@todo\|TODO\|HACK\|FIXME" .`
You can also run failing specs and try to fix them. I use `bin/mspec
spec/frozen`, `rake todo`, or `bin/mspec tag --list fails spec/frozen`.
## Ask For Help
Anything that we can do to help, we will. Make sure to do your own research
too, if possible. We will certainly accept and appreciate simple bug reports,
but it is extremely helpful if you can actively help us identify (and maybe
even fix) the problem. Again, see [Howto - Write a
ticket](/howto/write_a_ticket.html)
Q. It is all so confusing! There is the VM, the kernel, the libraries, the
specs, polymorphic caches, pneumatic stegosauruses... How can I possibly
understand all of this?
A. You do not need to know or understand everything immediately. You should
just have a great time exploring the codebase, not feel like it is some
kind of an exam cram. In fact, it is highly recommended that you start off
focusing on a narrow area and work your way to how it fits in the big
picture. While Rubinius is actually an exceptionally straightforward and
elegant VM and language implementation (MatzRuby 1.9, for example, is two
orders of magnitude larger), there is still a lot of information to
discover and absorb. Ask questions!
Q. I don't like the style of the specs or the kernel or the vm, can I clean
it up and you'll accept the patch?
A. That depends. The implementation is pretty straightforward and idiomatic
Ruby (or C++.) However, out of necessity many parts of the kernel are
implemented using simple constructs and could perhaps be expressed more
succintly. There is almost always a good reason for this, ranging from
compiler support to maybe not having a certain method or class available
yet. If it really bothers you, ask us first, we'll discuss it.
Q. Will you reject my patch if my style is "more Rubyesque"?
A. If the patch works (e.g. does not use features that cannot be guaranteed
to exist in all cases), it will not be rejected based on a stylistic
qualm. The code is most welcome. But "clever" or obscure code is not.
