As you might have heard, the Office of the Managing Director in Philadelphia recently launched myPhillyRising.com, which we built. Here’s some more info about tech behind the the app, and what we’re doing to create an engaged community of developers around it.
We at OpenPlans have been admirers of the PhillyRising program and team for a while. They are very aware of how much time it can take to resolve difficult urban issues. And their work is all about creating healthy relationships with the communities they’re working in. What’s more, the myPhillyRising.com app was a good example of effective prototyping by government — the RFP and selection process was conducted through GitHub. Check out Mark Headd’s talk from the Code for America Summit for all the details.
What powers myPhillyRising.com?
We use a mix of technologies to make myPhillyRising possible. Celery workers periodically collect and store events, resources, and stories from sources that the Philly Rising team identifies. This information is then served through a Django REST Framework API to our Backbone/Marionette-based client app and rendered into Handlebars templates.
There’s an admin page to add data feeds, and to assign them to neighborhoods — so a calendar feed that’s relevant to Kingsessing can be set up to always show up on the Kingsessing events list. Items from feeds can also be individually assigned, using a moderation queue interface.
Open source from the start
Like most of our projects, we wanted to run myPhillyRising as open-source from the jump for a couple of reasons. First, the project is a relatively small engagement for us, and we wanted to make sure people would be able to contribute to it after OpenPlans’ official role was over. Secondly, it’s a compelling project for the civic tech community to get involved in.
Making it easy to get involved
Open code by itself doesn’t help build a community of active developers. The ‘to do’ list for the project matters too. For this, we use GitHub’s Issue tracker.
We track development internally using a Pivotal Tracker, with one board for all our projects. This works well for us, but because the board is private, it’s hard for everyone else to see where a project is at. To help others get up to speed with myPhillyRising, we moved all the issues and ideas out of our Pivotal backlog and into GitHub Issues.
We also worked on tagging and expanding the stories:
- Instead of being an issue graveyard, we want the GitHub issue list to help people get going with the project. To that end, we’ve added a “get started” tag to any issues that have clear steps to completion in them.
- Our stories in Pivotal Tracker tend to contain our shared assumptions and references to internal conversations. Moving our stories and bugs to GitHub Issues gives us an opportunity to be more clear. We’ve tried to write the issues as if the person reading them has little prior knowledge of the project internals. We include both a clear description of the problem, as well as the rationale for the change.
So, get started!
To get involved, head over to Code for Philly and join the project team. No contribution is too small: typos, code formatting, ideas for future features… And if you’re looking for something more to do, grab an issue from the tracker and get going!