Contributing to Rails Issues

at May 15th, 2012

Rails Has Issues.

No, seriously. As of May 7th, 2012, there are 572 open issues on Rails. This is
not a negative reflection on the core team, nor is is something that they can
change, without stopping their ongoing work on Rails. They could drop all of the
issues in what is called “Issue Bankruptcy.” This raises a couple of its own
issues, forgive the pun. Bankruptcy would cause all of the tricky problems to go
unnoticed. It would lose any great ideas in the open backlog. It would, in my
opinion, show that the core team couldn’t handle it.

However, there is a way that we, the users of Rails, can help. It takes no extra
programming knowledge. It takes no time at all.

Triage

Triage (n)
the sorting of patients (as in an emergency room) according to the urgency of
their need for care

As consumers of Rails, we find issues and inconsistencies all the time. It could
be as simple as an odd syntax, or something as specialized as
query-optimization. It is a good thing that there is a culture that wants to
make things better. However, there is a point when even the most critical of
issues gets lost in the noise. When there are so many open issues, it can be
extremely difficult to know what is still relevant. The core team, while
perceived to be superheroes, are only human. They can only do so much.

As members of the community, this is where we can shine. We can work to confirm
issues. We can see if stale issues still exist. Sometimes, the only thing that
you need to do to get an issue closed is ask the OP if it still is a problem.

Triage

All you need to do is ask.

How to Triage Issues

There are a couple different types of issue commonly found in Rails Issues.

Bugs

Bugs can be triaged by asking if it still exists, trying to reproduce it,
writing a failing test that illustrates that issue, or sending a Pull Request.

Patches (Pull Requests)

Pull Requests are common in Rails Issues. As of May 7th, there are 215 open Pull
Requests, more than a third of the open issues. When triaging Pull Requests, it
is best to see if anyone has any thoughts about it, usually by getting the
attention (by @’ing them in a comment) of a member or two of the core team, or
the Pull Requester. You can provide a code review, or advise that they rebase to
make for a clean merge.

Feature Requests

During a session of Issue Triage, you may come across a Feature Request. This is
an issue that someone opened because they have thought of something that they
believe should be part of Rails. To triage this, you should give your opinion on
the request and bring it to the attention of a core team member.

What Now?

After initially triaging an issue, it is important to continue to communicate
with the people involved.

The reason the issue is still open is because someone did not continue to push
things forward. If things go stale in an issue, then push the participants to
make a decision.

Conclusion

Rails is a wonderful project, and we all have something to offer it. I have
contributed some of my time to answering issues, and I have found it to be
something that is effective and enjoyable. Understanding how to approach the
issue, based on its nature, is the hardest part.

I am issuing a challenge to all of you now. Go and answer 5 of the stalest
issues. It doesn’t have to be much, just a question will do. If we all take 10
minutes of our day to answer 5 issues, we can have a massive effect on Rails and
its future.

No Tags


No comments yet


Leave a Reply

Your email address will not be published. Required fields are marked *