Debugging the TTC

"If it bugs you, it's a bug."
Civic debuging

Applying software debugging principles of debugging to real-life problems that bug people in using transit. A transit system is not unlike a piece of software.

- There is a debugging system in place but it is really slow, and solutions don't come fast enough.
- Idea of submitting debugging requests gives a notion of ownership to people. Enlightened self-interest.
- Can be used to make incremental changes that could transit better for a lot of people
- There isn't a shortage of idea, there is a shortage in implementation of excellent ideas
- Current system - hiring consultants. Offer proprietary solution that just creates more work for them. Solutions process is top-down and it is very hard to make changes
- When you collect information from users, patterns of bugs emerge. A lot of potential in aggregating idea. We can catagorize data in a structural way.
- Getting bug reports is not a problem. If there is an avenue for the public to submit bugs, they will. The problems is aggregation. Need a way to identify and analyze patterns.
- Make it into political currency. Transform top bugs into political issues.
- Transit users as citizens and not consumers (?)
- Don't want to get into the issue of confronting power. For now, focus on collecting and aggregating data.

Quinn's Notes: (will reformat when feeling has returned to fingers)

Debugging the TTC - led by Geo

• if it bugs you, it's a bug" - Geo hoping to start with the website, expand to the entire city
• Quinn - analogy to software development implies, can agile development happen on physical spaces? rapid iterative development? clear evaluation measures? collecting relevant metrics?
• Mark Cascella - architecture student. Finding ways to improve getting around in a currently dysfunctional system.
• Goergie Ydreos - personal experiences make her want to help "fix" the TTC. Concerned about accessibility, physically and technologically.
• Daniel Hammond - has been doing transit advocacy, gotten involved recently. Transit is not unlike complex software. Mobile telecommunications background - professional organization/system changing. Transit system should be hiring mathematicians, because complexity has grown logarithmically. Change is reactive, not proactive. Feels that outside consultants are 'dangerous' - they propose solutions that are in their own interest, and take their tacit knowledge wth them when they leave.
• Joe - Debugging lends itself to taking ownership of the TTC by citizens, agency for affecting change.
• Sarosh - engineering student/intern. Interested in making small incremental changes to coordinate between TTC, city, property owners, etc. to improve experience.
• Mike - transit geek, writer at Now magazine. Debugging - not just what's wrong, but process of being a contributor in improving the system. Interested in tracking successes and failures in transit planning.
• Colin - rider, marketer, involved in open source projects. Is interested in harnessing this to improve the TTC.
• Sam - sociologist. Political problems faced by the TTC - lack of executional excellence. Changes are implemented too slowly to solve the original problems.
  
• Daniel says it is currently a top-down kind of thing. Culture of organization is in the staff - nobody is rewarded for innovation.
• Organizational change will probably be opposed by staff unless it demonstrably is in their interest (as well as that of management).
• Geo - focusing on tangential approaches - people are "disrupting" through collaboration and communication. Submitted bugs should be trackable, there can be accountability behind it. Aggregate, then look at the patterns to determine patterns. Accessibility and low cost of new media means new opportunities for media outlets to discuss issues of our time.
• Bryce - aggregating and quantifying the ideas is difficult - being able to collect it and structure it to make it relevant.
• Mark - whereever there is a problem, map it on Google?
• Daniel - TTC is paying lots of money to get Communication Information Systems(?) data. TTC wants data inaccessible - what would convince them of the value of opening it up?
• Sam - Qualitative reports with one/two line descriptions. Undergrad students volunteering time with social science profs to oversee process for qualitative themes.
• Geo (re: above suggestion) - try not to make it a problem of specialization.
• Sam - A tech-centered reporting system would gather limited feedback - no new Torontonians, no non-tech savvy opinions. Broaden the bug catching system.
• Quinn - SMS bug reporting.
• Sarosh - how do you make it relevant enough so that people care about it? How do top bugs become campaign issues? Why should the TTC be interested in improving their own system? Why would people at the top want to go with it?
• How do we get staff buy-in? Daniel's opinion - if we can get them to believe that money can be spent on the public as "outside consultants" rather than experts. We're not here to replace the staff but to make them more effective.
• Geo - strategy to go to those already in power is less effective in his opinion. If people are able to track / get updates on their bugs, there is a form of accountability.
• Does the TTC staff (of all levels) have time/permission to interact with the community?
• Many Torontonians are not citizens? No neighbouring interactions, little story sharing.
• Daniel - Case: an organization was completely dissatisfied with vendors' resonses, so they built it up themselves for what they wanted. The Transit Research corporation.
• Existing "Civic Debugging" projects - Demos, http://proboscis.org.uk