The pitches have been made, the sessions have been voted on, and this is your CityCamp NC 2014 unconference schedule.

We will have four concurrent rounds of sessions happening at once.  Here are a few tips to have a successful session at CityCamp NC:

  • Do a quick round of introductions
  • Have the moderator restate the pitch/topic
  • Designate a scribe to take notes
  • Make sure everyone can contribute to the conversation
  • Stay on schedule, sessions are 50 minutes long
  • Before your session ends, determine any next steps or actions—forming a team to compete is a great action
 Time  Lecture
Hall		 Room
#111		  Room
#112		 Room
#113		 Room
#114
 10:30 am  Building
sustainable
apps		  The dull and
the difficult		  Durham County
library makerspace		  Triangle
Interactive
arts map		  Bike paths
for all
of NC
11:30 – 12:50 pm Lunch – Find a good place to eat
 1:00 pm  Re-humanize  Food
deserts		  NC food
inspector		  Open data
policy framework		  (open)
 2:00 pm  InstaRep  Mapping ideas
for vacant /
for sale
properties		 City
notifications
and
information
solution		 Open data
accessibility		  (open)
 3:00 pm  Raleigh food
corridor		  Explore
SeeClickFix		  Paint swap  Where the
people at?		 (open)
 4:00 pm How can we
create and
facilitate
citizens-centric
tech		  Council
agenda		  Sustainable
story-telling
for communities		  Trails  (open)

 

Food Deserts 1:00 PM

We did a lot of idea sharing about where and how to identify areas of need.

We need to take it to the next level and identify individuals.  Self Identify?  Sign up?  Referrals?

An Uber for those in need.

 

Building Sustainable Apps (10:30 am)

Question: how do we take stuff we build during hackathons and similar types of events/programs and make them sustainable and usable?

  1. Web based: Design mobile-friendly, web-based applications rather than platform-specific, standalone apps (iOS, Android, etc.).
  2. Use common frameworks and consider the tech stack: use common development frameworks (ex: Bootstrap) and appropriate programming languages to make it easier to support long-term maintenance, enhancements, and extensions.
  3. Ownership: If working with a developer or third-party organization, specify in the agreement that the code becomes open source in order to avoid situations where a developer controls/owns the code.
  4. Support: What’s an appropriate business model? How to get from individual/small group to community ownership to commercial support? How to bridge the gap between open source and community and commercial ecosystem?
  5. Build for scale: If an app solves 1 specific project, could it be designed in such a way that it could be more useful in a broader scale?
  6. Build for future development: In order to encourage adoption and uptake by municipal departments or agencies, it will need to be maintained, extended, and enhanced in the future. Will departments have in-house resources to do so? Could they will minimal training?
  7. Data sources: If something relies on data, is it using a static data set or a dynamic data set? “I have a hard time trusting an app that relies on a static data set.”
  8. Data governance: How recent is the data? How often is it updated? What information about the data is provided so users can understand data source(s).
  9. Set realistic expectations: It is unlikely that an app, tool, program, website, etc. developed in a weekend or during a hackathon will be able to be deployed as is. It will take further development, documentation, and a community to support. Be realistic.

 Next steps: continue development of this list into a checklist or set of guidelines for hackathon developers. 

Edit tags