During the long drive back to Toronto from Québec City, I had plenty of time to think about my GSoC project, and where I want to go with it once GSoC is done.
Here’s what I came up with.
Detach Reviewing Time from Statistics
I think it’s a safe assumption that my reviewing-time extension isn’t going to be the only one to generate useful statistical data.
So why not give extension developers an easy mechanism to display statistical data for their extension?
First, I’m going to extract the reviewing-time recording portion of the extension. Then, RB-Stats (or whatever I end up calling it), will introduce it’s own set of hooks for other extensions to register with. This way, if users want some stats, there will be one place to go to get them. And if an extension developer wants to make some statistics available, a lot of the hard work will already be done for them.
And if an extension has the capability of combining its data with another extensions data to create a new statistic, we’ll let RB-Stats manage all of that business.
The reviewing-time feature of RB-Stats will become an extension on its own, and register its data with RB-Stats. Once RB-Stats and Stopwatch are done, we should be feature equivalent with my demo.
I kind of breezed past this in my demo, but I’m interested in displaying “review karma”. Review karma is the reviews/review-requests ratio.
But I’m not sure karma is the right word. It suggests that a low ratio (many review requests, few reviews) is a bad thing. I’m not so sure that’s true.
Still, I wonder what the impact will be to display review karma? Not just in the RB-Stats statistics view, but next to user names? Will there be an impact on review activity when we display this “reputation” value?
This is a big one.
Most code review tools allow reviewers to register “defects”, “todos” or “problems” with the code up for review. This makes it easier for reviewees to keep track of things to fix, and things that have already been taken care of. It’s also useful in that it helps generate interesting statistics like defect density and defect detection rate (assuming Stopwatch is installed and enabled).
I’m going to tackle this extension as soon as RB-Stats, Stopwatch and Karma are done. At this point, I’m quite confident that the current extension framework can more or less handle this.
Got any more ideas for me? Or maybe an extension wish-list? Let me know.
I love your blogposts on Review Board. We are waiting for RB 1.5 to be released for testing it.
Will your code only be available as an extension or will it be in the core of RB ?
I was wondering, you used to develop with Rails and now you are using Django (I think RB is based on Django, isn’t it ?) : what are, for you, the pros and cons of this two frameworks ?
What framework do you prefer ? 🙂 (I know you love Python, but… I wanted to ask the question !)
Thank you and good luck for you GSoC
@Benjamin: Hey! Thanks for commenting. 😀
RB-Stats, and all the rest will be available as extensions. The core of RB (or rather, Djblets) has seen the most modification to expand the framework.
> RB is based on Django, isn’t it?
Hard to say. Might be the other way around. I think they both hit the sidewalk around the same time.
The pros and cons of these two frameworks are worthy of (and the subject of) blog posts of their own. From my experience with both, here’s what I think:
I eventually got used to it, but one thing that really bugged me about Rails was the “magic”. These magic functions just happened to exist in certain modules, and I sometimes never knew where they came from. Diving through the Rails source code was always a bit of a nightmare.
Django, on the other hand, is much clearer in “where it gets stuff”. Several times now, I’ve spelunked into the Django core, and thanks to the way Python deals with packages, I more or less always knew where everything was, and how most things worked.
So, opinion one: Django possesses a lot of the Rails magic, but the magic is more transparent…
What I really miss about Rails is all of the awesome testing tools that we have. Shoulda, Mocha, Machinist, etc…Rails tests are almost a joy to write. The tests I write for RB/Django are less readable and more tedious to construct.
So, opinion two: when it comes to testing, Rails is the victor.
But which do I prefer? I like both of them, actually. However, if I could get the Rails testing tools into Python, I’d probably prefer Django.
I might turn this into a whole blog post after the summer is over. We’ll see. 🙂
Thanks for posting!
Some thoughts for the extension wish list:
Git/Subversion/Mercurial integration. Most importantly Git (IMHO). It would be cool to be able to push to a “reviewboard” clone. Once the review gets X ship-its, it’ll get pushed to master. Something like pre/post hooks would be nice.
Bug tracker integration. It would be nice if ReviewBoard would be able to post back-and-forth conversations between reviewer and reviewee to Bugzilla/Trac/etc. if an appropriate bug is associated.
Eclipse other IDE integration. It would be nice to create a review request faster. Right click somewhere => “post diff as new review”. I know there’s post-review or some such. Never really played with it a lot…
I know those are big things and I’ll stop dreaming now 🙂 Cheers!
Great ideas! Thanks! 😀
All the best,
Love this RB-Stats extension!
That’s really helpful!
When can we really try this on ReviewBoard? Or maybe it’s already published somewhere?
The RB-Stats extension was an experiment / exercise to see if we could get the Review Board extension framework working.
The extension framework is now available in the release version of Review Board, but the extension is almost certainly broken for it.
You can see the old code here: https://github.com/mikeconley/RB-Toy-Extensions/tree/d060963287fc1b25fd07397cd19dec38a0649c1d/rbstats
If you wanted to polish it up and get it working again, I’d be happy to answer questions about it. 🙂