Using bug tracking for code vs. the real world

[dsernst]

There's a long history of bug trackers being used for collaboration among software developers: http://en.wikipedia.org/wiki/Bug_tracking_system

Joel Spolsky calls it one of the "hallmarks of a good software team".

In 2012, @iangilman explored the idea of using this paradigm in a wider range of problems in Issue Tracking for the Real World.

Then in December '13, I began asking similar questions, separately at first, leading to Letsfix (earlier called MTM).

"If bug trackers work so well to facilitate programmers' collaboration across the world, could a similarly open system help with real world issues too?"

[dsernst]

But in what ways are real-world issues unlike software bugs? Where do we predict a bug-tracking system may work well & not?

[dsernst]

Typically bug trackers assign "owners". Makes sense in a software context when these are non-controversial, but questionable in our context.

[iangilman]

One of the obvious differences is you're not at your computer when you're dealing with the real world. To integrate with the real world, it needs to either be available on a smartphone, or it needs to be okay to interact with the issue tracker when you're removed from the issue you're dealing with. The former is especially critical for tracking physical infrastructure things, and the latter makes sense for big picture things that don't have a specific physical location anyway.

I think there are a lot of real world issues where it does make sense to have an owner assigned… Particularly the localized infrastructure sorts of things. Of course when you get to large scale things like "climate change", it doesn't make sense to have an owner, at least at the top level issue. I would imagine something on that scale should be broken into subissues, and it's possible some of them could indeed have owners. On the other hand, there are issues where it makes sense for many people to be contributing… A large issue might have a subtask called "collect signatures for ballot measure", for instance.

One of the other big differences of course is that you can assume programmers are generally pretty good at using computers and not put off by complicated forms and databases. An issue tracker meant for the general populace needs to be friendly and easy to use. Furthermore, it needs to provide real and noticeable utility to those who use it, otherwise it will be ignored.

I suppose another difference is that many real world issues don't have a specific authority in charge of approving changes, so it's hard to know if a specific issue has been properly addressed.

I'm sure there's more… We need to find actual real-world communities who are willing to try it out in ways that are meaningful to them, so we can get some road test feedback.

[dsernst]

We're on the exact same page on all points. Glad to see ya here, Ian!

Re "has this been fixed" I envisioned periodic prompts

On Saturday, July 12, 2014, iangilman notifications@github.com wrote:

One of the obvious differences is you're not at your computer when you're
dealing with the real world. To integrate with the real world, it needs to
either be available on a smartphone, or it needs to be okay to interact
with the issue tracker when you're removed from the issue you're dealing
with. The former is especially critical for tracking physical
infrastructure things, and the latter makes sense for big picture things
that don't have a specific physical location anyway.

I think there are a lot of real world issues where it does make sense to
have an owner assigned… Particularly the localized infrastructure sorts of
things. Of course when you get to large scale things like "climate change",
it doesn't make sense to have an owner, at least at the top level issue. I
would imagine something on that scale should be broken into subissues, and
it's possible some of them could indeed have owners. On the other hand,
there are issues where it makes sense for many people to be contributing… A
large issue might have a subtask called "collect signatures for ballot
measure", for instance.

One of the other big differences of course is that you can assume
programmers are generally pretty good at using computers and not put off by
complicated forms and databases. An issue tracker meant for the general
populace needs to be friendly and easy to use. Furthermore, it needs to
provide real and noticeable utility to those who use it, otherwise it will
be ignored.

I suppose another difference is that many real world issues don't have a
specific authority in charge of approving changes, so it's hard to know if
a specific issue has been properly addressed.

I'm sure there's more… We need to find actual real-world communities who
are willing to try it out in ways that are meaningful to them, so we can
get some road test feedback.

—
Reply to this email directly or view it on GitHub
#14 (comment).