##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.

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 it 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.