On Being a Lightning Rod

The Gathering Storm

Thus far, I’ve avoided following much of the drama in the Ruby and Rails community. The Rails community prides itself on opinionated software, which naturally lends itself to drama.

During DHH’s keynote at Railsconf 2012, it felt to me that he was attempting to draw fire away from the other members of the Rails core. Regardless of intention, I believe he has it right. Let the creator of Rails, our flag bearer, be the lightning rod.

During the Rails Panel session, one of the attendees asked about the Github issues count. At the time, there were 840 open issues. That is a lot. And there was rightful concern about this.

A challenge was issued that everyone attending should go out and work at updating 3 of the tickets. If everyone did that, we could knock out the queue.

I went and did my part, but unfortunately, all I could do was add comments. I had no power to close a ticket. In fact, its likely that I simply added to the chatter of a ticket.

Declaring Bankruptcy

As I see it, there are two bankruptcy options. The first is closing all the issues. This has been done before when Rails transferred issue tracking from Lighthouse to Github. It was  suggested, perhaps offhandedly, that it needed to be declared again. The second option that I see is delegating the work.

When I was working at my previous job, we had a growing number of issues, and it was a lot to handle. New features were being requested alongside fixes and changes.  I found the issues system to be overwhelming.  I not only had to prioritize, but request more information, then wait for that information to arrive, during that time I’d go through the list again, trying to find work.  There was a tremendous amount of noise.

To solve the problem, a new project manager stepped in and immediately took charge of the issues.  He was hands off about everything else, instead wanting to get a handle on what was obviously causing mental drag on the development team.

Initially, he went through and curated the list…determining each ticket’s state; Was more information required (if so what), was the problem so old that it needed to be re-verified, etc. In doing this, the team was able to get an assessment of where things stood.

Both methods work, but the first method is kind of like Congress punting issues onto next year’s Congress. Things can will done in the short term, but a greater storm is brewing.

Proposed Solution

My proposed solution is that a small group of people (perhaps even one person) be given access to http://github.com/rails/rails to curate issues. I don’t know if the current setup at Github would allow granular permission for managing issues, without managing the code base, but that would be ideal. Failing that, granting someone contributor rights to rails/rails with the express purpose of managing tickets.

To be clear, members of the Issues team would not be writing any Rails production code.  The Issues team would instead focus on making sure that the Development team can easily find actionable issues.

It would be a matter of creating the heuristics for handling bugs. Think about it, presently the rubyonrails.org “Bugs/Patches” link goes directly to the open Github issues. We, as a community, are not providing a lot of guidance for submitting well-formed issues. Yes, I know the Rails Guides has help for submitting issues.

I firmly believe the Rails core members should focus on executing the best technical direction for a framework. There needs to be someone else managing the chatter of the Issues; This chatter creates a mental drag on the day-to-day development of Rails.

I’m willing to be part of the proposed small group who’s responsibility it is to close stale tickets, request further information from those that are insufficient, and make sure a issue for Rails Core is in the best state possible.

I have a day job and a family, but believe that I can contribute a portion of my time to making Rails better, and I see a particular itch that needs scratching.