Skip to content

Hacknight #25: Jan 19

Twenty-fifth hacknight – 40 participants.

Presenter: James McKinney (@mckinneyjames), founder of Open North.

Breakout groups:

  • Civic Tech 101 – Matthew
  • Design research on the Syrian refugee private sponsor experience – Dorothy
  • Open Cabinet – Alex
  • Toronto budget project – Henrik
  • Data viz workshop on City of Toronto 2016 preliminary operating budget – Gabe
  • Societal measure / Indicators – Steven

Thanks to Architech for hosting, and for dinner!

5 thoughts on “Hacknight #25: Jan 19”

  1. Data viz workshop: 2016 City of Toronto preliminary operating budget
    Gabe, Joey, Tim

    We talked about the challenges of preparing the budget, and how in the analysts notes there’s a section on […] which are items that are not included in the base budget, but which ideally would be included.

    We talked about money coming out of reserves to balance the budget, and Tim dove into the data to better understand how much is coming from reserves, and where it’s going.

    We also plugged the data into Tableau Public and made a basic treemap. With help from Richard, Bernard and Zeena.

  2. Workgroup: Toronto Budget Project
    Participants: Henrik, Marc L, Emily

    Henrik and Marc reviewed details of server provisions, including local vagrant virtual machine and eventual public digital ocean server.

    Emily completed revision of budget timeline data into tabular format, in preparation for export to json format, for use by initial static website

  3. [Speaking points from James]

    Main points:

    1. Steal code. This means monitoring the civic tech space to know what code is out there. Some good repositories to browse (I’ve often used code from these) are:

    2. Request data from government. Maintaining scrapers becomes expensive. Start a conversation, so that even if you’re writing scrapers now, there’s a chance you won’t have to forever.

    3. Solving boring problems for everyone else is important. Many civic tech projects lose steam, because you need to solve a lot of boring problems (e.g. scraping) before you get to do the thing that excited you in the first place (e.g. vote analysis). Even if all you do is write a scraper and dump the clean data to GitHub, you’re making it easier for the next person!

    4. Solving problems in multiple jurisdictions forces you to find efficiencies (e.g. adding more automation to your processes), such that your maintenance burden is roughly the same as if you were inefficiently solving a problem for one jurisdiction. Working on multiple jurisdictions at once makes your solution better (more robust) and easier to replicate.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.