When you think of iterative development, you’re unlikely to also think “government agency.” You’re even less likely to think “MTA.”

But that might not be the case in the future, as today the MTA showed a strong sign that the situation is changing: They listened to feedback and responded. Quickly.

In my post yesterday, I identified several aspects of the new developer resources page that could be improved. On Thursday and today I had more communications with representatives from the agency and provided some additional feedback.

This afternoon — less than 48 hours after my post went online — they addressed several of my suggestions for improvement. First, they’ve significantly streamlined the download process, replacing a form requiring lots of personal information with an optional one that simply asks for your email address — so you can be notified of data updates — and what you plan to use the data for. This information is entirely optional as there is also now a link to take you directly to the download page.

Second, they explicitly added information about how frequently the schedules are updated, as well as upload dates for each of the datasets.

Lastly, they’ve posted GTFS data for the MTA Bus Company. This is another big milestone, as it means that now every single MTA transit agency has its data online, for free, in GTFS.

These changes — along with the rapidity with which they were made — show that the MTA is serious about open data and proactively working with the developer community.

For an agency that gets a lot of flack (both unwarranted and warranted), they deserve credit where credit is due. Bravo, MTA!

The Open Planning Project is partnering with the PenTales Storytelling Projects to develop an interactive web app for the New York City Department of Parks and Recreation. The application will serve as an interactive platform for New Yorkers of all ages to share and collaborate on stories they have produced through hand-writing, digital-writing, photography, moving pictures, voice media and other forms of communication. The platform will first pilot in New York City and will later be expanded to include other American urban and rural communities.

PenTales is seeking a talented, civic-minded volunteer developer to make the project happen. The developer will work very closely with PenTales and NYC Department of Parks and Recreation staff from start to finish, with guidance from TOPP’s developers.

The app will be built using the python-based open source Community Almanac code base. This same code is also being actively developed with other projects.

You can view the full job description on our jobs page. Please pass it on!

Tonight at 7:30 EST, tune in as Brian Lehrer interviews Philip Ashlock of TOPP Labs. You’ll be able to view the webcast here.

6:30pm update from Philip Ashlock:

I just came back from the studio taping and thought I’d mention a few things I didn’t have a chance to cover during the interview.

One good example of civic technology we’re developing is trip planning software for public transportation. We’ve worked with Portland’s TriMet to provide their trip planner and we’re bringing other cities together to share and collaborate on technology like this with the Open Trip Planner project. You can find more information about our technology projects on this website, on the TOPP Labs website, and on the OpenGeo website.

Also, The Open Planning Project helps bring developer communities together to better support their efforts. We’ve done this with the other transit developers in the region, including Chris Schoenfeld of StationStops, with the New York Public Transit Data Summits and NYTransitData.org. We’re now working to facilitate a healthy and productive dialogue between these developers and the MTA. We’re following this same model for the Open311 initiative by bringing 311 developers and city governments from across North America together to share technology and best practices to create better more connected city services.

On the subject of opening up city data, it’s worth noting that both Vancouver, BC and Portland, Oregon have recently passed legislation that makes open data and open technology a core part of city government.

Delicious data inside. Photo by Anabadili via Flickr.

The effort to open municipal data is an initiative with momentum. Inspired in part by the transparency mandate on the federal level that gave us the first ever White House CIO and data.gov, cities across the country are opening up. One city in particular set the scene before this all hit the national stage: Washington D.C. has delivered precedents like the first online city data directory, the first open API for 311 service requests, and open invitations for developers to produce apps with city data using initiatives like Apps for Democracy.  D.C. has laid the groundwork for a national model by delivering some killer apps. Previously the CTO for D.C., Vivek Kundra is now the national CIO. This model has not yet been fully embraced by New York City, but it’s getting close. In fact the New York State Senate Office of the CIO has been paving the way for opening government data on the state level.

(more…)

Some CapitolCamp inspired wiki-thoughts:

My first session was facilitated by Karen A., who works in Senate Tech Services. Karen came with a kernel of an idea for a ‘New York State Senatepedia’…a wiki where people could explain Senate jargon, document the histories of different legal actions, and connect items with related information.

A Senatepedia has a ton of merit. It would facilitate peer-to-peer learning between private citizens. It would put in plain view the machinery of the NY Senate. It would be a living document, with articles updated over time by interested citizens (wikis that follow twists and turns can get really active). And it would be a large-scale shared archaeology project that could make visible what are today largely invisible topics, histories, and relationships. Ultimately, it would help the public follow and assess the legislature.

For those who pick up a new app every day, wikis are as basic as water, but when integrated into public processes they can have real transformative power. At the federal level, OpenCongress.org (don’t miss their wiki) offers a lot of great information. Senatepedia would be a similar – though surely not identical – venture at the New York State level. There is a lot to be said for a state legislature that would embrace such a concept and treat it as a serious resource by integrating it with the other information on NYSenate.gov.

The alternative – an edited dictionary about the Senate, produced by Senate staffers – would require a comparatively large investment, and it could become stale fast. Remember the last time you landed on a ‘More Info’ page and found a list of broken links? Yuck.

Karen’s Senatepedia idea encountered a fire-hose of input. We talked a lot about risks. I don’t know about Karen, but after all that feedback I might not have felt empowered to actually begin the project. The experience was instructive. Roadblocks and responses:

1. Moderation was a big concern. If you let the public edit your site, they will go crazy! They might lie! They might link to porn! We would need a full-time moderator!

Whoa, there. There is no incentive to contribute to a community (and a wiki is a community) if the site sponsor doesn’t value that contribution. You don’t encourage contribution by controlling the content in a top-down way, and re-editing every article is a bit silly anyway.

There are probably, say, a couple of thousand people across New York State who really care about the intricacies of the Senate’s legislative machinery. This group is a nascent community of interest. A set of people scattered across the state who may or may not know one another. These folks come across awkwardly at cocktail parties. “Well starred bills have been around since 1974, when they came about as a way to…” Total snooze at the party, but for someone, somewhere, this knowledge is powerful. The better citizens understand their government, the more they can do to help it work.

Imagine if this distributed cabal of citizen experts were set loose upon a Senatepedia, to explain and edit and debate. These are the stewards of quality and community, the people who make peace by setting the basic rules of the road (stay on topic, cite your sources, be respectful).

Wikipedia started with simple rules, and over time the site has evolved along with the community (see, for example, warning notes on controversial articles and rules on handling disputes). Those who contribute a lot gain the authority to moderate. A lively Senatepedia community would function similarly. A few passionate people can prune a large garden, making it ever easier for casual users to contribute. Ian pointed out that the smallness of the initial community is part of the point: the purpose of the wiki is to distribute knowledge more widely.

2. False legitimacy also came up. Some were concerned that visitors to the site would think of the information on the wiki as immutable, each word ‘vetted by the New York State Senate.’

This point is valid. The ‘discuss and consense’ areas of wikis are too often hidden. Most Wikipedia readers never realize that many articles are the result of an ongoing discussion that is happening elsewhere.

As a timely example, the article on the New York State Senate saw some action today due to drama, and updates to the article were not without controversy. But few people visiting the article would ever notice, unless of course they happened to click on the tiny Discussion tab.

Making the Discussion portion of a wiki more visible would reinforce the notion of the website as a living, community-created document, and it could create new incentives to contribute (both to the discussion and to the article itself). Including recent discussion or information about recent contributors in the sidebar might go a long way. Streetswiki literally ‘puts a face’ on contributors, a reminder that ‘people just like you’ wrote the articles.

Good page layout, in particular clarity about which content is wiki content, also helps avoid ‘false legitimacy.’ Clear design can remind people that the wiki is community-created and distinct from vetted Senate resources.

3. Incentives. Would people really contribute? If you frame Senatepedia the right way get #1 and #2 right, you have a pretty good shot. There are plenty of incentives to contribute to a wiki: sharing new information, correcting someone else’s infuriating mistake, seeing your name in lights, gaining virtual street cred. Latour laid out similar incentives years ago when studying publishing scientists (research funds aside), and plenty of sites reward superstar community members.

Senatepedia is a great idea, and straightforward best practices from other successful wikis could really give it legs. I hope the NY State Senate considers setting it up.

Short(er than this post, I promise) thoughts about CapitolCamp.