How do I Create a Challenge Brief?

Originally created by the amazing Lindsay Oliver over on the Geeks Without Bounds blog, and reposted with permission here.

Why create a challenge brief?

Useful challenge briefs are the key to producing robust solutions for a hackathons. They do this by limiting, not expanding, the parameters of solutions to challenges. It’s easy for participants to overextend themselves on solutions that try to address too many components of a problem at once. By creating challenge briefs that break the problem up into parsable, bite-sized chunks that can be tackled in the time span of an event, participants are able to create more viable results when they focus on one component or feature.

Remember that hackathon challenges aren’t necessarily software development challenges. Most Geeks Without Bounds and Random Hacks of Kindness affiliated hackathons allow the opportunity to work on challenges around software, hardware, and open data. Many are also open to citizen science projects, educational resource creation, and the development of other commons resources. Be sure to explain in your brief what sorts of resources you would like to see in response to your challenge.

What are the key pieces of effective challenge briefs?

  • Background
  • Challenge Statement
  • Scenarios (optional)
  • Components
  • Resources

Background

Provide your participants with contextualizing information on the problem, the requesting organization, etc. This will help lay the groundwork for them to determine what solutions might be valuable in this use case, and how those solutions might need to be tweaked for the benefit of the end user.

Sample:

Kiva is a microfinancing platform with the goal of bringing an end to poverty through giving. They focus on individual empowerment to create opportunities, ensuring that marginalized populations are the ones in charge of their own development, prosperity, and independence.

Challenge Statement

This is the heart of your brief. The challenge statement boils down the problem(s) that are being presented to participants. Be sure to state the need and explain why solving this issue is necessary. Indicate how a solution to this challenge would impact the stakeholders, and provide any needed caveats for special cases of use.

Sample:

Kiva needs a better way to understand its own donor data and extract meaningful/actionable information from it, provide avenues for external partners and wealth managers to interpret and share impacts of this data, and use this information to further drive engagement of donors both individual and donor-advised. Any tool created for this challenge will need to take into consideration the internal and external potential uses for this tool, and implement reasonable flexibility to address these end users.

Scenarios (optional)

This is an optional component for your challenge brief that is dependent upon any special cases of use that the solution will be addressing. For the example provided below, the end user of this tool may be outside of the organizational structure that created it. This information helps participants craft solutions that provide flexibility for implementation of the tool.

Sample:

Many of Kiva’s donors come from a pool of donor-advised funds via institutions like Morgan Stanley. These wealth managers provide reports to their managed investors on how their money is being used, what the return rate of those investments are, and what the impact of those investments are for the recipients. Wealth managers need the ability to track these funds at a variety of levels (geographic area, type of loan, amount, theme, etc) and provide this information to their investors. This will enable donors to provide feedback, see the actual positive human outcomes generated by their investments, and direct their wealth managers toward targeted groups in need.

Components

This is where you break up the challenge into parsable chunks for teams to choose from. Stress to your teams that this is not a checklist of items to complete, but a starting place for ideas. Only one portion of the possible solutions should be addressed by individual teams, NOT the entire list.

Sample:

1. Refined Loan Information Processing
-Accessing information on donated/invested funds more easily
-Calibrated for intaking both individual donors and larger firms
-Both for external firms and internal Kiva usage
2. Funds Tracking
-Tracking of funds both individual and donor-advised to provide a holistic overview of where, how, and why funds are spent
-The ability to import funds data from sources outside of Kiva
3. Impact Visualization
-A flexible, adaptable, and editable visualizations generator
-Framed for use both internal and external

Resources

Give your participants shiny new toys to play with. Platforms, APIs, datasets (with PII, personally identifiable information, SCRUBBED), media, use case studies, etc, should be made available to teams. Don’t overdo it, though, as too much information may bog the teams down and prevent out of the box problem-solving.

Sample:

  • Developer Site, Kiva API, and Sample Data
  • Datasets: Incorporated into provisioned hackathon NetSuite accounts
  • Kiva Media and Image Gallery

Good luck, and happy hacking!

Should I Offer a Prize at My Hackathon?

Consider: what do you want the prize to do for the event, and for the attendees, and for your cause?

Your humble author usually steers clear of cash and large prizes because of the people it brings around, and how they influence the crowd. Do you want to prioritize large attendance / an opportunity for undergrads to be exposed to this topic? Or do you want to prioritize sharing stories and collaborating on potential solutions with no strings attached? Any of these priorities (or others) are totally fine, but decide what you’re going for, and pick how to handle prizes based on that.

Building Capacity

At things like StartUp Weekend, prizes help teams move their project forward – time with a lawyer, some startup cash, access to expensive dev tools, etc. At GWOB events, we usually give prizes which are coding books, comics, and hardware kits; all to get people thinking in new spaces. Another set of prizes might be qualifying to work towards a bounty of DELIVERING a working prototype (or some other milestone) by X months after the hackathon. Or just use prize money towards that, and use the hackathon as a time to onboard people to the ideas. (I think I would even wait to tell people about the bounty until the hackathon itself).

Attracting Attendees

Prizes sure can be great for attracting attendees. For people with many options in front of them for how to spend their time, prizes can incentivize attendance. This can also mean attendees might view the prize as compensation for their time – a strange mental space to be in, especially if not a winner. Prizes can also incentivize people to focus and to push themselves out of friendly (or unfriendly) competitiveness.

Other Considerations

Smallish prizes as indications of appreciation are awesome. Definitely need to be able to be divvied up across a team (no ONE LAPTOP PRIZE – how can 4 people deal with that?). Too big/prestigious, and people don’t collaborate or share what they’re up to (being protective of people “stealing” their good ideas).

Hackathon Consent Form

Purpose and general description of the study

Study on the history, use, and troubles of the hackathon, or codefest, model of engagement. The goal is to end up with a clearer understanding of the tension between the formal sector taking on the idea of “hackathon” while actively combatting the context of “hacking.” More appropriate methodologies for organizers, facilitators, and participants would be published and workshopped back into the community of hackathons and the people who make them happen.

This study is conducted by Willow Brugh, a research affiliate at Center for Civic Media at MIT’s Media Lab, with Ethan Zuckerman as Principal Investigator. You, along with 3-10 other individuals, are requested to participate in the study due to your connection and history with the groups which exemplify the topic. These groups were chosen based on a wide ranging view of hackathons and engagement roles.

The research is anticipated to include a one-hour interview with participants and followup questions via email. Summaries will be sent to participants for feedback and approval before being posted to a public website. Research is currently slated to end in December 2013.

Participation

Your participation in this research is completely voluntary.  You can withdraw from the study at any time without penalty or loss of the benefits to which you are otherwise entitled. You do not have to answer any questions that you do not want to answer.

Data Collection

Data will be collected via interviews via Jitsi, G+, Skype, Phone, Jabber, or some other conversational platform of the interviewee’s choice, or possible in-person interaction. Dependent upon the consent of the interviewee, data will be logged mentally, textually, and/or audibly. All data will be released to the interviewee within 2 weeks, and later to the public if single-instance consent is expressed after review.

Topics

During the interviews, expression of beliefs around hackathons, their purpose, and methodologies will be examined. Questions will revolve around history, best practices, success stories, and future expectations.

Identifiers

Due to the co-creative nature of this research, participants will determine if they would like to be identified or not. Each node of analysis of interviews will be released to the interviewee for approval and clarification, and at that time the interviewee will be asked if they would like the node to be anonymized or credited. If any subset of interviewees desires anonymity, Willow Brugh will consult with the participants to determine if all groups must be anonymized to protect the indicating party, or if a mix-and-match is possible.

Confidentiality

Confidentiality in this study is determined by the participants. After agreeing to take part in the study, each interviewee will indicate what level of confidentiality they prefer:

  1. Anonymity to the best of the researcher’s ability.
  2. Association with group, but individual anonymity.
  3. Identified by name and group affiliation.

Based upon how all interviewees respond, Willow Brugh will work with the participants to determine if mix-and-match is plausible, or if all respondants must be identified or anonymous. If in question, anonymity will be defaulted to. Any quotes or exact attributions will rely upon a per-instance specific consent.

All data will be retained on a hard drive encrypted via TrueCrypt (http://www.truecrypt.org) and stored with Willow Brugh and an encrypted backup drive stored in a locked cabinet at MIT’s Media Lab. All interviews and email exchanges will take place via OTR, PGP mail,  Jitsi, or Red Phone. Any documentation will be offered to the interviewee and transmitted via encrypted channels (as listed above), but it is their perogative to store in a secure fashion if desired. Assistance in setting up encryption methods is provided upon request.

If anonymity is desired, any audio will be destroyed after analysis of the interview is responded to and approved by the interviewee. The name of the interviewee will at no point be stored in plaintext, and will be erased from stored data after encoding occurs.

If explicit consent is given on a per-instance basis, audio and transcript (when available) will be published to the web in an open format.

Risks, Costs, and Benefits

Risks of Participating in the Research

There are no known risks for participating in this research, other than the violation of confidentiality if confidentiality is desired. I have indicated above/below the steps I am taking to preserve your confidentiality.

Benefits to the Subject or Others, or Body of Knowledge

In understanding and making explicit the benefits and difficulties of the hackathon space, these communities can become more self-aware and thereby more effective in achieving their goals.

Compensation

No compensation is provided to participants.

Questions about the research and rights of research participants

If you have any questions about this study at any time, please feel free to contact either me, Willow Brugh, at 812.219.4056 or bl00@media.mit.edu, or Ethan Zuckerman, director of Center for Civic Media at ethanz@gmail.com. We will do everything possible to prevent or reduce your discomfort and risk to you, but it is not possible to predict everything that might occur.  If you experience unexpected discomfort or think something unusual or problematic is occurring, please contact any of the people listed above.

Signature Block

By filling in your name, you indicate your desire to participate in this study.

Please indicate your preferences for overall anonymity (you can change this at any point for future publication, but existing research updates will either have been credited directly to you or stripped of all information). Each node will pass through you for feedback and approval before being published.

  1. Anonymity to the best of the researcher’s ability.
  2. Association with group, but individual anonymity.
  3. Identified by name and group affiliation.

Theorizing the Web Talk

Nate and Willow’s talk at Theorizing the Web 2014 on Hackathons are More than Hacks starts at 50:12

  1. Set up the mismatch between media and practice (3 mins max
    1. Introduce ourselves
      1. Willow
      2. Nathan
    2. N: If you’ve read about hackathons in the press, you’ve probably seen
      1. clever young hackers winning prizes for making tech
      2. rather than a community of all ages learning together
    3. W: show a quote by an organiser
    4. W: and a quote from a participant
    5. N: In this presentation, we share some early results from research on hackathons. We’re seeing a mismatch between media narratives and the stories participants themselves tell, a mismatch that is colouring critiques of hackathons.
    6. (describe our methods and context) (45 seconds) (brief)
      1. w: what is a hackathon, based on our experience and our interviews
      2. w: we interviewed around 15 participants, organizers, and facilitators.
      3. n: we analysed around 640 articles and blog posts about hackathons
      4. w: we’re involved
  2. W: In my interviews: Hackathons at the intersection of community building and engagement with institutions (who are the players, and what are their goals) (2 min)
    1. What hackathons we’ve looked and been involved in
      1. (slide) with a big list of logos and what years are covered with us and the people we’ve talked to
      2. (zoom) Communities (slide with lots of examples) (open source, disaster response, entreprenuers)
      3. (zoom) Organisations (slide with lots of examples) (businesses, governments, non profits)
    2. Who attends (front end, back end, subject matter experts, students) or just (do this for THEIR LIVING, professionals who want to volunteer their tech skills on a weekend, folk who want to learn more about a subject, folk who are passionate about a subject but don’t know how to engage)
  3. W: What actually happens at and after hackathons (3 mins) include a bunch of quotes
    1. People learn about new disciplines and challenges
    2. People find a way their skills can change the environment they’re in
    3. People find others with shared interests
    4. What happens with projects & initiatives
  4. N: How hackathons get portrayed (2 mins)
    1. Slide of what media we analyzed, including list of sources, MediaCloud mention, and histograms for Hackathon and Civic Hacking (640 articles)
    2. Simple revolutionary solutions
    3. Civic Hacking (80 articles & blog posts)
      1. equal measure PR
      2. project documentation
      3. critiques of the idea
    4. Superstars & Startups
    5. last point: mismatch between media narratives and interview results
  5. Major critiques of hackathons – coming from theorists, critics, and funders
    1. slide that points to hackathon critique articles & minisites (don’t try to respond)
      1. example: MELISSA GREGG & CARL DISALVO “The Trouble with White Hats” (New Enquiry) (http://thenewinquiry.com/essays/the-trouble-with-white-hats/)
      2. example: National Day of Hacking Assumptions & Entitlement (http://nationaldayofhacking.info/) voices from people in those communities. Disconnect causing animosity.
      3. Morozov “Making It” New Yorker: http://www.newyorker.com/arts/critics/atlarge/2014/01/13/140113crat_atlarge_morozov?currentPage=all
      4. David Sasaki (Omidyar, now Gates Foundation): On Hackathons & Solutionism http://davidsasaki.name/2012/12/on-hackathons-and-solutionism/
    2. List Critiques (willow)
      1. Produces incomplete & short-lived projects (prototyping) – addressed when about the community rather than about the media.
      2. Free labor for companies & gov’t
      3. Doesn’t create fundamental change
      4. Props up existing structures, making them more efficient
      5. Inauthentic citizenship as alternative to meaningful change
      6. Only addresses technically actionable solutions
      7. It’s impossible for tech to support meaningful structural change
      8. False Empowerment: Solutionism in a weekend
      9. Distraction: People feel good about shiny ideas that never have impact
      10. Emphasizes superstars rather than communities
      11. Entrenches exclusion by favoring people with technical skills
    3. Nathan: What ties these critiques together is an emphasis on media portrayals and less a focus on actual community practices we’re seeing
      1. Media doesn’t emphasize learning
      2. Media doesn’t emphasize community building
      3. Media supports an overly simplistic solutionist narrative
      4. Media prefers a one hero story about shallow revolution
      5. Media attention focused around the hackathon event, with limited follow-up: if projects proceed beyond prototype, we don’t hear about on going effort
      6. All of these things can obscure what really happens
  6. W: Based on what we’ve found: Responsibility for hackathons, media, and researchers, for a method that’s still growing and evolving (3 minutes)
    1. W: Impart a sense of what these become as what we make of them. By their very nature, they are malleable. People with skin in the game need to be engaged with responsibly.
    2. W: Solid as a working method – especially cross-culturally (closing technological gaps as well as socioeconomic / access gaps)
    3. W: So you’re organizing a hackathon – think about how you’re portraying it to all parties, and make sure to amplify communities and practices, not just projects
    4. M: So you’re reporting on a hackathon – reporting on projects is lazy – look deeper into the community practices, learning, and engagement with institutions
    5. M: So you’re researching hacker culture – find a stance that acknowledges and respects the voices, experiences, and work of the communities whose outcomes and potential will be directly affected by the arguments you make from a position of power and privilege. Go beyond critique and simple media criticism for a deeper engagement with communities and practices
    6. W: Use & contribute to hackathonFAQ.com

Missing Persons Application!

This is a draft of a blog entry. The idea needs further refinement, and we welcome your feedback!

When a disaster occurs, whether fast like an earthquake or slow like a drought or war, people go missing. As outsiders wishing to contribute to restoring the stability of our worlds, the desire to reunite friends and loved ones through the technology we know so well can be tempting. Making use of our knowledge of social platforms, geotagging, and databases is far easier than addressing the long-term systemic injustices which allow these crises to affect entire populations in the way they do, afterall. But let’s say a typhoon has just made landfall, or that there’s a sudden influx of refugees from a drought-blighted country, and you and a group of your friends have gathered to see what you can do about it. This is beautiful — we need to learn how to work in solidarity with those in other geographies. But it’s also a delicate space. This particular post is about whether or not you should build that missing persons app, or spend your time contributing to something like Google Person Finder, OpenStreetMap, Sahana, or Standby Task Force instead.

The missing persons/reunification domain of humanitarian response is not just about people logging themselves so as to be findable by those missing them. It’s also about those individuals being protected during the process, having support in finding those they’ve been separated from, and the infrastructure which surrounds these actions. Software has a lot to contribute to connection, information security, and sorting through indexes, but missing persons is a delicate space with real humans in the mix.

This is an inhabited space


There are already missing persons tools and organizations which have been vetted for capacity and integrity for follow-through and security. Here are the few most successfully used ones: American Red Cross’ Safe and Well, Google Person Finder, Sahana, Refugees United, International Committee of the Red Cross’ Restoring Family Links, National Center for Missing & Exploited Children. Please offer to help improve and maintain these existing tools (code repos and communities are linked to from each name)! If you are uncomfortable or unsure of how to contact them, please let me/Tim know!

However, we also understand that the world changes. We gain access to new technologies, there are new clever people in the world, and our understandings of situations change. There is *always* room for improvement in this space, just as any other. Want to do something substantively “better” or different than what the existing tools and organizations already do? Here’s what you need to know:

A component, not a solution

The software-based frontend and backing database are a TINY FRACTION of the overall system of missing persons reunification efforts. People are often missing for a *reason*, possibly because of political unrest, domestic violence, or displacement. If your platform publishes photos of someone or their geographic location, will someone try to come after them? Can you protect their physical and emotional wellbeing? There are national and international laws in place to protect such individuals, especially children, and your component of the system must be in alignment with those laws (or have a damn good and intentional reason for not being as such). Ethically, you should also respect an individual’s desire or need for privacy. In the Missing Persons Community of Interest, organizations handling missing persons data are reviewed by external parties for their ability to perform long-term maintainence and protection of said data. You and your tool will need to undergo the same rigor before being launched.

Complications versus easing interaction

Your goal is to make finding loved ones easier, right? Think about how many tools are already in play (see “This is an inhabited space” section above), and what adding one more to the mix would be like. Every new missing persons platform is another point of decision-making stress on the missing persons and those seeking them. Imagine being asked for personal information about yourself while under extreme duress over and over and over again.. or having to repeatedly enter in the details of someone you love and are deeply worried about while on a desperate search for them. The listed existing tools have gone through (and in some cases, are still working out) data sharing flows to reduce these stressors while still maintaining their committments to privacy and security of the data they hold. If you launch your tool, you’ll need to adhere to the same levels of empathy, respect, privacy, and sharing. (Side note, please don’t start a “uniting platform,” either, lest we get here. That’s what sharing standards are about.)

We look forward to your heartfelt, well-thought out contributions to this space.

Tim and Willow

Heatwave Hackathon

Hugs and thanks to Lindsay Oliver and the Kenya Red Cross team for their contributions to this entry.

On November 15th, I helped facilitate the Red Cross Crescent Climate Center’s HeatHack 2014, a gathering of amazing people to collaborate on solutions to climate-related challenges. This event focused on the risks and impacts of heatwaves, and how to provide community care and safety nets for at-risk people during extreme weather episodes.

In case you wonder what a hackathon is:

A hackathon is a gathering of diverse people who form teams to work on addressing challenges over a short period of time. These challenges can be technical, physical, resource-based, or even social. During HeatHack, participants learned about heatwave challenges from climate experts and people who have experienced heatwaves firsthand. Teams formed around potential ways to address these challenges, and worked together to come up with solutions to present to the judges. Prizes were awarded based on innovation, documentation, usability, and inclusiveness.

Why “HeatHack”?

Heatwaves can cause power outages, wildfires during a drought, buckling and melting roads, burst water lines, and serious health effects such as severe sunburn, heat cramps, heat exhaustion, heat stroke, and death.

  • According to NASA, when the temperature hits 95*F (35*C) your ability to function drops by 45%. Your loss of accuracy is 700%.
  • MPR News reports that body temperature can rise to 105*F (40.6*C) if working outside in a heatwave. Death occurs usually when a body temperature reaches 107.6*F (42*C).

Despite the severity of heatwaves, the health risks often go unnoticed because the people most affected are easily overlooked in a large population, especially if they are poor. We need to create ways of responding to these challenges to care for people who are currently at risk and to prepare for future heatwaves. As the effects of climate change become more severe, the number, length, and temperature of heatwaves will increase – including in Nairobi! Climate change affects the entire globe, and Kenya can lead the way in creating solutions that help as many people worldwide as possible. Continue reading

The “Make the Breast Pump Not Suck” Hackathon

Author’s note: I go to, organize, and facilitate a *lot* of hackathons, and while I’m thrilled about most of them as chances for people to learn and get involved in a field of research, I’m also fairly skeptical of them. So I’ve limited myself lately to events that can really make a difference, not only for the participants, but for the people who would benefit from the things they work on. Most recently, I’ve been doing events in Dar es Salaam with Taarifa and Geeks Without Bounds around water point mapping. I think this event has an opportunity for significant impact as well – this event especially in the arenas of health and gender equality. The following post was written by the hackathon team, of which I’m honored to nominally be a part.

Why Breastmilk and Breast Pumps?

Breast pumping is an experience many women dislike, yet it saves the lives of premature babies and permits working women to continue a nursing relationship with their babies. The health benefits of breastfeeding for both mother and baby are numerous, and include reduced risk of type 2 diabetes, hypertension, female cancers, heart disease, and osteoporosis. Despite the overwhelming data and worldwide endorsement of breastfeeding for the first two years of life, many women do not breastfeed at all or wean after several months. In particular, low-income, working women are rarely able to take extended maternity leave, afford the cost of a pump, or pump breastmilk at their workplace. In emerging economies around the world, women who go back to work wean their babies rather than using a breast pump.

breastpump1

The breast pump is the rallying cry for the event because it is a symbol of a technology that could be better integrated into people’s everyday lives in order to save lives, save money, and lead to healthier and happier families. At the same time, our goal is to make space for innovation in family life more broadly, and to support a wide variety of different kinds of projects at the hackathon- and beyond.

This is the second of these events, with a writeup of the first here. Check out some challenge definitions and inspirations on the Tumblr, and join us if you can!

When: Saturday, September 20 & Sunday, September 21, 10am-6pm

Where: MIT Media Lab

Win! World-class judges will be giving cash prizes to the best ideas

Register Now (Registration is free but space is limited)

Bringing together parents, medical professionals, designers, policymakers, MIT students, and engineers to radically redesign the breast pump, as well as explore other innovations in maternal and pediatric health to improve the lives of families and children around the globe.

Our generous supporters of this event include Vecna TechnologiesMedela and Naia Health.

Presented by the MIT Media Lab with organizational support of iKatun.

Pre-Hackathon Movie Screening

Join us for a free public screening and discussion of Breastmilk: The Movie on Wednesday, September 10, at 7pm at MIT Bartos Theater, 20 Ames Street, Building E15, Lower Level, Cambridge, MA.

No RSVP required! Babies welcome.

Questions? Check out our website or contact us at breastpump-organizers@media.mit.edu.

Projects from the Boston Aaron Swartz Hackathon

Written with Erhardt GraeffSJ Klein

Intro Talk Ethan led us out by talking about the breadth of Aaron’s work, and what it is to be an “effective citizen.”

https://youtube.com/watch?v=1Pn3mm3bK6U

(Second day’s talks are written up already on the Civic blog here.)

Projects We Worked On We are deeply appreciative of all of the hard work done at the event, and about the social bonds built in our time together.

Ableson Report TL; DR Distillation and restating the Report to the President on MIT’s role (or lack thereof) in the arrest and suicide of Aaron Swartz, such that more people can join in the conversations around the issues specific to MIT.

https://youtube.com/watch?v=cJxP3jOdO-I

Finished with: Prioritized and referenced questions for the FAQ doc, this prezi (which can still be expanded upon, but this is a start), and a super pretty interface to put it all into as we work.

http://prezi.com/embed/9r2agd3u8ule/?bgcolor=ffffff&lock_to_path=0&autoplay=0&autohide_ctrls=0&features=undefined&disabled_features=undefined

Emerson Working with Mozilla’s web API structures to to wrangle control of personal data across the web back into the hands of users.

https://youtube.com/watch?v=VFjmcoWufRk%3Flist%3DUUbqhCwZfmeKwMhaXyW4tUtw

Repeal the CFAA Repeal the CFAA: The CFAA is broken; no one but prosecutors like it. Building a constructive, normative replacement, and strategies for getting support at all levels: executive, policy, law, prosecution, activists, cyberwar. Cooperating with Aaron’s Law and EFF work; but also tackling. Most discussions of “CFAA reform” have been incremental, in a framework of discussing what changes to current law are possible and would help fix recent problems; as opposed to describing why CFAA is broken and what proportionate and moral laws in that space wold look like. We’re trying to describe what effective policy would look like, starting from scratch. Policy, Legal, Social, Tech/Security, and Prosecutorial norms which make sense. Project details and analysis

https://youtube.com/watch?v=tr1g9MmOXZM

Strong Box A platform for whistleblowers to transfer documents to newspapers directly. Initial code by Aaron Swartz.

https://youtube.com/watch?v=SAGoft_e-PY

This gentleman fixed a bug in how to delete files which a journalist may no longer find relevant.

Tor2Web Set out to work on tor2web, which makes it possible for internet users to view content from Tor hidden services. It’s online in a (mostly) functioning form at http://tor2web.org. Worked on by Aaron Swartz.

https://youtube.com/watch?v=wzs-TScDqk0

Finished with: a WORKING simple anonymous editable pastebin (no public code yet; on AWS w/ sponsorship). Hot damn!

What’s Next? Keep going, of course!

Recurring Calls We’ll have an ongoing call—once a week on Mondays for November, then monthly. These are to touch base about our work, to help solve issues and celebrate successes. If you’d like to be added to the calendar, invite, please leave a comment or email Willow

Open Atrium We’ll track our progress and objectives on this open source project management platform. It’s a way for us to remain ambiently aware of each other while still being accountable. If you’d like to hop on a project, or be aware of how projects are progressing, check out atrium.aaronswartzhackathon.org

IRC As always, you can join us in the OFTC IRC room #aaronswhack

Expectations

There’s something about the fantastic Saving The Hackathon blog post on TokBox, that gets to the crux of the cognitive dissonance around hackathons. People expect the next technological tool or application that will change the world to come out of these. Sometimes they do, but rarely. (Insert side-rant about the expectation of perfectly-formed tools, objects, or people appearing from anywhere; as specifically articulated in my comments to this blog post). As I’m sure we’ve talked about before, I deeply believe that technologies only amplify human intent. I have yet to see anything that contradicts this. When it comes to disaster and humanitarian response hackathons, they get a lot of press. But what is the tangible output? What expectations can we set for ourselves and attendees?

So far as tools which can immediately be deployed in the field, not much. Not to say it doesn’t happen at all, but it is rare. The amount of forethought and digging which must happen to find the specific pain point which tech can help ease or automate is not something the affected population or the responders really have time to deal with while they are also doing response. Even when something appropriate is built, you have to worry about dissemination, training, and failure modes. Thus why the most useful things come out of things like Random Hacks of Kindness and CrisisCamps are awareness building and warm fuzzy feelings.

Yes, both warm fuzzies and awareness are legitimate, useful things. Too often, as technologists, we are separated from our world. We spend time behind screens, acutely aware of crises and issues but detached from the response and ownership of those situations. Civic media is an exceptional example of how technology has helped to close that detachment rather than deepen it. I see the same reclamation of involvement at the heart of the maker movement also at the heart of digital humanitarian work. No, this is not something we can leave up to some organization that we don’t know about, that isn’t accountable to us, and that doesn’t have mechanisms for listening to the very people it claims to serve. This is something we must do ourselves, calling upon the institutional knowledge and resources of those large organizations as needed. The things we create, which work, including processes, need to be codified. Sometimes into consensual hierarchies, sometimes into bureaucracy (both of which can be useful, as painful as that might seem). These assumptions of interaction allow us to operate at the next higher level, just as a language allows us to converse more easily, and a shared word set (for a discipline, say) allows us to have even more specific and deep conversation.

rhythmic tapping will solve everything!

rhythmic tapping solves everything

And on the institutionalized side of another false dichotomy, the awareness and warm fuzzies remove the mysticism of tech. People in traditional sectors all too often see applications and networks as some ruby slippers, easily deployed and perfectly aligned if you just knew the right phrase. And the same fear that goes along with a belief in such power, the misunderstanding of a very real (but also not ultimate) power. It’s not just developers who think the thing they build will be the next big thing – it’s also the people in response-based orgs not knowing that they need one section of a workflow automated, not a geotagged photo sharing platform (we already have those).

So response hackathons are a great place for the amplification of human intent and desire to assist the rest of humanity. That’s great. Now – how do you make those intentions deployable? IE, now that you’ve had the cancer walk, who’s doing the research and implementation? That’s a smaller group of people, who are willing to take the risk of plunging into work that doesn’t pay like the rest of the software world. That’s a small group of people who are willing to suffer the heart break and soul crushing that seeing the horrors of the world can cause, in order to see your tiny steps (maybe) make way against that. That’s an even smaller group of people who also understand how to support and care for themselves while they do that work, to find sustained income (sometimes from the people you are wanting to help most – which is still a cognitively sticky bucket for me), so they can keep going. And the fight isn’t just to make things better, it’s also about how that exists in the current world, with policy and with culture.

Response hackathons absolutely have a place in this system of engagement. But it’s one part. Without the continuation programs like Geeks Without Bounds and SocialCoding4Good, we all just pat ourselves on the back and go home. We start to wonder if it’s even worth going to the next one. But accomplishment takes hard work, and sometimes working on the fiddly bits. And that means deep learning and conversations with the user. That means advance work, and continued work. Which I believe you can do. Don’t just create in response to things going pear-shaped. Build things to better understand them. Create to make the world better. Make with purpose. The disasters and obstacles we face in the near future are unpredictably complicated and massive. We have no way to train for them. But we also have massive untapped resources in the sharing of our brains and hearts, brought out when we create, and share, and build.

It is with all this in mind that I am excited about how Geeks Without Bounds is starting to look at how we will interact with OpenHatch, in an effort to contribute to (and learn from) the open source community. It is with all this in mind that I am excited about DataWind, and AppsToEmpower, and shipping low-cost tablets into developing area pre-loaded with useful tools. It is with these things in mind that I am excited about the continuation of EveryoneHacks, and how it creates space for new creators.

Gender-Based Violence hackathon in Port-au-Prince

Originally posted at Digital-Democracy’s website.

Apply to join Digital Democracy for a Hackathon in Port-au-Prince, Haiti from November 8-12, 2012.  We are inviting American and Haitian developers & designers to address these questions and support the inspiring work of Haitian women’s organization KOFAVIV. For over 8 years, KOFAVIV has provided critical, life-saving services to survivors of rape & gender-based violence.

With generous support from Abundance Foundation and partners ESIH (Ecole Supérieure d’Infotronique d’Haïti) & Willow Brugh of Geeks Without Bounds, the Hackathon is focused on developing tools to help scale the impact of our current systems in two areas, resulting in three outputs that will dramatically improve the work of our partners.

1) EXPANDING THE CALL CENTER TO NATIONAL SERVICE
Last fall, Dd & local partner KOFAVIV launched Haiti’s first Emergency Response Hotline for Gender Based Violence (GBV). In May, 2012, the hotline transitioned to 24 hour service and currently provides women survivors of violence free access to information on services for medical, legal and psychosocial care in Port-au-Prince. In order for the Call Center to serve national clients, operators need easy access to a map of resources outside of the Port-au-Prince area.

Hackathon goal:
•  Build a web platform to map/aggregate information on service providers throughout the country. Skills in SMS, GIS, and Drupal are especially useful.

2) BETTER VISUALIZING DATA
Since 2010, Dd has worked with local partners to develop a cloud-based database to digitize information on incidents of violence. The system currently includes 50+ points of data on over 900 reports of rape and domestic violence in Haiti between 2010 and 2012. KOFAVIV is seeking to improve their ability to use data to advocate for increased security for Haitian women & girls.

Hackathon goal:
•  Develop live data visualization to generate visual monthly reports on cases received by local partners. Skills in Drupal, design, dynamic code, especially useful.
•  Identify new trends in existing data and develop creative ways to visualize data for advocacy and outreach. Skills in design, big data, and community engagement especially useful.

Join us!

If you or someone you know has skills in the following and would be interested in participating, please submit an application here (bit.ly/PaPhack) by October 9, 2012. Specifically, we’re looking for participants skilled in:

  • Drupal
  • Front end design
  • Graphic design
  • Dynamic code
  • Dataviz
  • Big data
  • Mapping / GIS

Participation includes Hackathon, travel, lodging, food and transport in country. All logistics taken care of by Digital Democracy. Estimated total travel and accomodation per participant is $5,000 with some scholarships available. For more information, about attending as a participant email Emilie Reiser – ereiser(at)digital-democracy(dot)org.

Become a Sponsor!

Help make the Hackathon possible. We are looking for premier sponsors as well as scholarship sponsors to help bring the right participants to the Hackathon. To discuss potential sponsorship, contact Emily Jacobi – ejacobi(at)digital-democracy(dot)org.