For a while, I’ve been hearing reports from project maintainers that OpenHatch’s volunteer opportunity finder has not been entirely up-to-date. Some projects reported that we didn’t index all of their bitesize bugs; others said we showed old ones that had already been closed. So I’ve gone through and radically simplified the way we import bugs.

Now I can say with confidence that any change to a bug inside a project’s bug tracker is reflected on OpenHatch within a day. You can always check on the health of our bug tracker imports and our other background tasks at http://openhatch.org/+meta/.

Here’s what it says:

Bugs last polled more than than one day + one hour ago: 0

Zero is a good number! When you’re measuring how many of our volunteer opportunities are stale, you’d better hope there aren’t any. It means we’re making good on the promise of keeping our index of bugs fresh.

If you’re interested in technical details, here’s the skinny. A year ago, when this all began, we were using the celery task queue (as an interface to rabbitmq) to manage our bug tracker import jobs as “periodic tasks.” This worked fine for a while, but for some reason, when we upgraded to celery 1.0, things fell apart. It could have been caused by something wrong on our end, but I took the opportunity to remove the celery dependency from the bug tracker import code. Now, there’s a Django management command (like “runserver”) that updates all the bugs, and we run that once a day. That’s as simple as can be.

Celery is still pretty important for us. We use it in the profile importer; when you enter a username or email address, we query other networks where you might have left your digital trail. Thanks to celery, we can run those jobs in the background. Right now, there still seem to be some deployment-related problems with making sure those all run when they should. That’s high-priority in the queue of what to work on next.