Michael Koziarski

Rails core member Michael Koziarski talks about Rails 2.0, the new patch process, and working on the core team.

From RailsConf in Berlin.

Interviewed by Geoffrey Grosenbach

Transcript

Geoffrey Grosenbach: So, Geoffrey Grosenbach, Rails Conf 2007 in Berlin talking to Michael Koziarski core member of the Rails team: chased him all over the world, he’s been in Seattle a couple of times, and I wasn’t there so finally we caught up. Good afternoon!

Michael Koziarski: G’day.

Geoffrey: I thought it was only Australians, but New Zealanders use “G’day” also.

Michael: Yeah. Er… sometimes. I tend to use it when I’m away from home, try to stand out a little bit more.

Geoffrey: [laughs] So everyone that I have talked to, at least on the core team, says Michael Koziarski is the best project manager I’ve ever known, do you do project management kind of things on the Rails team or are people self-organizing?

Michael: No, no. I’ve worked with a couple of people there on a few different projects, but as far as the Rails core team goes, we tend to be pretty self-organizing, which has its advantages: we do lots of work in spurts when we have the time available, but it means that timelines can be a little bit harder to guess, but because it’s open source rather than paying work it’s not necessarily a bad thing.

Geoffrey: I’ve heard too that on occasion, people will just kind of disappear for months and hey, it’s no big deal, when they’re ready, when they have time they come back and they contribute to patches or whatever.

Michael: Yeah, exactly. I mean, if you… one of the things that we think is kind of important is that we all have paying jobs as web developers as opposed to Rails developers. It means that we at least have some contact with the people who are going to be using our framework. We actually know the problems that we are trying to solve rather than just trying to guess… guess at solutions from some kind of ivory tower, we’re actually every day web developers. But the disadvantage of that is that we actually have to pay the bills, we have to continue working on these things and so from time to time if I’ve got two or three projects that are due, I’ll just sort of disappear for a week or two at a time.

Geoffrey: That seems a good question right now, what it’s… over a year ago, maybe even two years that the current members of the core team were established. Do you ever see that more members would ever be brought on? It seems there are different roles, even maintaining the wiki or other kinds of things, is that something that a core team member would be needed for?

Michael: Ideally no. We’ve… well, ideally no to the “we need you to be a core member to do those kind of things”. We’ve expanded out the patch review process so that more and more people from the community can contribute and actually start providing feedback to people on their patches as soon as they’re submitted, and raise the bar of quality and of review for the patches that actually end up in my inbox. So that gives us a couple of advantages: it means that instead of having 600 odd patches that I have to review, I only have two or three that are in the pending patches list at any given time, and it also means that there are a whole bunch of people who are getting excited about the implementation of Rails itself, are getting familiar with how the different bits of the internals work and actually can take a look at that stuff and say, “Well, I’m figuring out how this thing works, I’m going to focus on any Action View patches” and basically try to provide whatever value they can and that’s basically from a code review or an improvement perspective. And they tend to contribute more and more patches as they have been reviewing them. So that there might be a pathway for us to find additional contributors, but as it stands right now with the community looking after the main Rails mailing list, the community looking after the wiki to whatever extent that they can at present, it’s actually working pretty well. I don’t think we necessarily need to expand a whole bunch of managers for want of a better word, and we can sort of get everyone working on this and make it much more of a community effort.

Geoffrey: You mentioned your patch process that just dropped in the last week or so.

Michael: Mmm-hmm.

Geoffrey: Maybe it was even a surprise to you, but how does that work?

Michael: Well quite the opposite, it was my idea!

Geoffrey: Oh it was your idea? OK!

Michael: We’ve been working on a sort of beta for two months now, one of the goals there was if you look at the old patch list, I think report number three, there’s something like 700 patches in there. About two thirds of them don’t apply cleanly any more to Rails, so if we wanted to even try to work with them, download them, try to apply them, the patch gives us some kind of error, we have to close the ticket and report back to the user. So we kind of had to declare, like David said, patch bankruptcy on that list and just say, “We can’t keep up with it.”

And so instead of just getting us closing all of those tickets and pissing off all of the contributors, we’ve basically got it now that if you are really passionate about a patch or proposed patch that you’ve got in mind, you can contact people, either jump on the Rails core mailing list or into the IRC chat room and just get three people to have a look at your patch, both from a “I want this functionality” but also a “I checked out the implementation and it looks good”, once you’ve got those three votes you can add the verify tag to your ticket and then it will show up in a report that we check. Basically each of us checks it once a week or so and so it averages out to a couple of times a day, and we tend to have pretty good turnaround time on those patches. So gone are the days when you submit something and you hear nothing back for a very long time. And we’re sorry that it got like that, but I think if you look over the last two to three hundred change sets in Rails, almost all of them have come from external contributors rather than ourselves and so it’s working, hopefully it will continue to work and hopefully it will scale out now that it’s official rather than just some kind of beta process.

Geoffrey: Now I think it’s a great idea to let the community help themselves, voting, putting all the work in, changing the different statuses, but I look at that and I think, “That’d be a great little Rails app to have a bug reporting system that had that kind of thing built-in…” Is the current system just kind of a hack until that can be done or do you think Trac is going to be capable to just drive that system for the future?

Michael: Trac is an interesting project. I think that we are the largest Trac installation out there in terms of traffic that we get. We get an enormous amount of traffic, most of it not particularly legitimate; just bug spam and comment spam and that kind of stuff. But in terms of the volumes of traffic that we’re getting, it’s fairly large and in terms of just the number of requests that we have to handle. So we’re up at the outer edge of what Trac was intended for and works well for… I’ve had that same thought: do we need more software to actually manage the patches and I sort of tend to er back and forth, maybe we need something which automatically checks if these things cleanly apply and if it doesn’t then it can just close them… but then I sort of think maybe we’re kind of implementing distributed SCM in that case, just doing it in half-arsed way. It might be nice to have something which actually encoded that voting functionality plus one, plus one, plus one, and then automatically showed up on the list, but at present what we have works and I guess if someone on the core team for instance who runs a bug tracking tool for a job, maybe he wants to add some functionality that would let us do that, but for now we can definitely get by with Trac.

Geoffrey: Last question, David mentioned that Rails 2.0 is… at least there’s going to be some sort of release candidate, several release candidates probably and then Rails 2.0 coming out. Can we assume then that most of the features that are in the trunk right now are what are going to ship with Rails 2.0?

Michael: Absolutely. We’ll push a preview release at some point so that’ll mean an SCM tag but not a branch, and ship a release from that up to the beta gems service. And then we’ll expect a lot of people are going to try to do the upgrade, they’ll report things that don’t work any more because a lot of us… a lot of the people who contribute regularly have been running on edge for at least the last six months and so that means if we’ve broken something in the last six months in the upgrade path from 1.2 to 2.0 we’re probably not aware of it. So after that we’ll ship a beta release, ship a new 1.2 so that we can send some duplication warnings and that kind of stuff and then hopefully, 2.0 is five, six weeks away but who knows, it just depends upon how much stuff we’ve managed to break.

Geoffrey: Well thanks for the chat, you’re consulting… where can people find you? My web site is koziarski.com and I’m reasonably busy now but I’m always interested in hearing a new project so if there’s something up, drop me a line.

Michael: Well thanks!

Geoffrey: Cheers.