Tag Archives: bugtracking

Bughunting in the city’s software

Ah, internet serendipity – a few days after my post about SeeClickFix and systems for crowdsourcing bugfixes in the urban system*, Adam “Speedbird” Greenfield posts about improving “frameworks for citizen responsiveness” [via Chairman Bruce]:

So how would you close the loop? How would you arrange things so that the originator, other members of the public, the city bureaucracy itself and other interested parties are all notified that the issue has been identified and is being dealt with? How might we identify the specific individuals or teams tasked with responding to the issue, allow people to track the status of issues they’re reported, and ensure that observed best practices and lessons learned are gathered in a resolution database?

In a talk I heard him give a few months back, technology entrepreneur Jyri Engeström suggested stealing a page from the practice of software development as a way of addressing shared problem spaces more generally. He pointed out that, during his time at Google, employees turned the tools developed to track open issues in software under development toward other domains of common experience, like the shuttle buses the company provides to haul them back and forth between San Francisco and Mountain View.

When hassles arose with the bus service, employees treated them just like they would known issues in some application they were working on: they entered their complaints into an existing bug tracker, which provided each case with a unique identifier, a space to characterize it more fully…and perhaps most importantly, the name of a party responsible for closing out the ticket.

The general insight Jyri derived from his experience got me to thinking. An issue-tracking board for cities? Something visual and Web-friendly, that’s simultaneously citizen-facing and bureaucracy-facing? Heck, that begins to sound like a pretty neat way to address the problems with systems like 311 and FixMyStreet.

Seems pretty logical (and pretty much what SeeClickFix are aiming towards, albeit a lot more fully featured and comprehensive). That said, the system relies on the same sort of user tenacity that any big collective project requires: making it easier to see where pressure needs to be applied still requires that the pressure to be applied, if you see what I mean, and maybe it’s naive to hope that the majority of citizens will care enough to get involved (because the vast majority of, say, Ubuntu users, certainly don’t bother doing much beyond turning up and asking n00b questions that five minutes of searching would solve for them**). Then again, lowering barriers to participation, so on and so forth… maybe if it’s done right, people would use it.

Or perhaps this is the natural outcome of geeks developing ideas for the wider world: they’re gonna be geeky ideas, and geeky ideas don’t always float the boats of everyone else. Is Greenfield’s framework just another case of everything looking like a nail when you’re well-versed in hammer deployment?

[ * “… crowdsourcing bugfixes in the urban system…” Yeah, I know, I felt awful typing it, but there’s no less pretentious way of saying the same thing without using another two dozen words, so Web2.0 speak was the only way out. I blame the future. ]

[ ** I fully include myself under this admittedly damning and sweeping indictment. ]