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!

There’s a nice post from David Eaves today on the need for a “MuniForge” — a repository for open source municipal software.  Without getting too into the details, I wanted to point out one line that really struck a chord with me, discussing the conundrum that governments find themselves in when procuring proprietary software:

…most solutions are proprietary and so lock a city into the solution in perpetuity.  This not only holds the city hostage to the supplier, it eliminates future competition and worse, should the provider go out of business, it saddles the city with an unsupported system which will be painful and expensive to upgrade out of.

Talking to many government IT folks recently, I’ve heard this story over and over again.  The notion of a city being “held hostage” by a software vendor is a bit abstract, and is probably hard for people outside the business to grasp, but it’s a real and important problem.  To make it more concrete, and to continue to make the case for open source and open data, we should focus on telling these stories.

So, what’s your proprietary government software horror story?

At last night’s PlanningTech workshop, we diagrammed out planning processes to see where the insertion of technology might have been helpful.  The processes we looked at ranged from seemingly simple (getting a bike rack installed on your street) to massively complex (advocating for funding for MTA’s capital plan). Keep an eye out for digitized versions of the diagrams, as well as the opportunity to help expand them.

One idea that stood out, and that solicited some good discussion, was the notion of a “living plan” — a planning document that, rather than being static and falling out-of-date quickly, would evolve as a community’s context, needs, and priorities evolved.  Of course, such a plan would be unthinkable in an analog world, and seems  ridiculously obvious in a wikipedia world.

But that’s not to say it would be easy to implement.  Last night’s group raised a handful of questions, including: “what about dealing with large, complex expensive projects? (e.g., transit expansion)” and “what about blowback from early participants when the plan changes over time?”, and “what about ‘planning fatigue?’”.  All important questions to ask, and I won’t try to answer them here.  But the gist of the idea was that given a set of guiding principles (a constitution, if you will), a “living plan” might allow for more flexible planning and easier decisionmaking down the line.

It was good timing, then, that I came across this post on Streetsblog, covering some potential street design changes around Brooklyn’s Grand Army Plaza.  There’s debate over a DOT proposal to remove eastbound parking on Union Street and add a traffic lane, in order to reduce traffic buildup entering the plaza.  Community advocates are concerned that such a proposal won’t solve the fundamental “traffic vortex” problem, and doesn’t take into account the broader goals of creating a more livable and “world class” public space at GAP.

One section by the Grand Army Plaza coalition’s Robert Witherwax stood out to me:

All the tweaks to the plaza, so far, have been consistent with the planning principles GAPCo and its partners have promoted. The problem, says Witherwax, is the city’s piecemeal approach, which the Union Street proposal has cast into sharp relief. “DOT has been an excellent partner,” he said. “It’s not so much that what they have done, or are proposing, is bad — it’s that they aren’t going far enough.”

Witherwax is calling for a “buildable master plan” — a blueprint that would help guide planning and transportation decisions throughout the plaza area according to consistent goals. “Once you have that structure in place, you can say what happens if you do X, Y, and Z over here,” he said. But to date, he added, DOT has resisted the idea of a comprehensive plan.

Perhaps a “living plan” is somewhere in between the current, incremental planning that DOT is practicing an Witherwax’s notion of a “buildable master plan” — something that nurtures the development of guiding principles and longer-term projects, while still allowing for short-term experiments and responsive design.

This whole discussion makes me wonder how technology, in the form of a living plan or otherwise, might inform the debate here.  I can think of a few ways, to start:

• A website that visualizes competing plans or visions for the future of GAP, where each idea could be discussed, analyzed, and tweaked.
• An online traffic simulator (for all of Brooklyn?!) that lets anyone make tweaks and see the impacts, in a sim-city sort of way.
• A tool that explains, via an interactive diagram, the planning process as it’s currently laid out.  Who the decision makers are, where the input points are, and what the schedule is.
• Anything that generally increase sthe “touchability” of the proposed changes, moving them away from the abstract, wonky world. Perhaps this is something that our friends at the Environmental Simulation Center would be able to help with.
• (insert your idea here)

<shameless-plugs>
If you dig this kind of thing, head over to the PlanningTech google group and come to one of our upcoming meetups.  If you want to help TOPP and others build tools like these in the near future, check out the (as yet vaporware) Cosm project.
</shameless-plugs>