Why Volunteer for HTBox? Use Your Powers for Good!

Monday, September 19, 2016

Whether you want to explore new ideas or learn specific skills, sharing your time and expertise can save lives.

HTBox is a charity that supports disaster relief organizations with open source software and services. Here, we are developers, designers, testers, analysts, copywriters, program managers and industry professionals who want to contribute our unique skills into disaster relief aid. Humanitarian Toolbox strives to create software and programs for relief organizations that are ready in times of need; for example, volunteers may create apps that map the spread of disease or maintain software that optimizes the delivery of relief supplies.

Why do we emphasize open source software?

Open source software allows us to maintain our focus on sustainability. In fact, much of the software used in disaster relief is outdated or built in the haste of a current crisis. HTBox is committed to the routine development of all of our projects to keep them current and always improving.

Additionally, openly sourced software lifts barriers for contributors and users of our software. This makes it an ideal choice for volunteer developers looking to make a difference and the organizations that need help. Additionally, it allows anyone to access the software and take it for a spin.

How do you build the optimal program or app for the right folks?

Some of our projects are developed from scratch by working closely with a specific relief organization. In this case, HTBox gathers the requirements for the project from the relief organization, breaks it down into work items in GitHub, and then runs code-a-thons to get the software written with the generous help of our volunteers. This way developers can concentrate on development and work can continue remotely which allows volunteers to work wherever and whenever they like.

To view our repositories, visit our GitHub account here

Why is HTBox interested in preserving and maintaining older software?

During a crisis, software may be developed within a disaster relief organization. When the crisis is over, however, the individuals involved in creating it often move on; otherwise, the software languishes on a shelf. Instead of allowing valuable resources to deteriorate, HTBox takes on these projects to archive and maintain for future use.

How can I become a volunteer for Humanitarian Toolbox?

First, we recommend signing up for our mailing list so that we can keep you up to date with the latest.

Second, head over to GitHub and, take a look at our projects! If there are any items that you think you could contribute todo, go for it! Work items marked, “Up for GrabJump In,s” mean we’re looking for someone to get developing on it. There are many contributors to HTBox projects that work on their own time weekly by picking up work items from the repository and contributing new code.

Of course, If you're not a developer but still want to contribute to HTBox, oour volunteer base is not limited to developers! It takes many skills to build great software and we're always on the lookout for designers, testers, analysts, copywriters, program managers, project leaders and more.

If you want to volunteer but are unsure how your skills can be put to use, shoot us an e-mail at volunteer@htbox.org!As the software continues to improve, whenever new disasters strike and disaster relief organizations are able to go into the toolbox and pick up the software they need.

We believe your time is valuable – it can save a life.

 

 

Thank you for reading.

 

Gabrielle Greiner

Humanitarian Toolbox Volunteer

 

 

 

 

Crisis Check-in and Operation Dragon Fire

Monday, May 9, 2016

In our ThatConference 2015 recap in September, one of the marquis projects we talked about was CrisisCheckin, the “first responder’s phone book”, which was conceived based upon the challenge that disaster site coordinators and leaders often face in trying to manage and deploy resources.  CrisisCheckin is being developed with several scenarios in mind, but one of our primary use cases is was defined and tested as part of Operation Dragon Fire (ODF), which focuses on enabling data sharing during disasters and medical emergencies. 

Initially the use case was focused on people-related resources, but based upon early potential user feedback, it has been expanded to include physical resources such as blankets, equipment, and medical supplies as well.  Much of the work starting at ThatConference was been focused on integrating this additional feature set, conducting exercises with target users, and developing issues and milestones from the feedback we have received.  Over the last seven months, we have had continued development work from volunteers including during codeathons at CodeMash and Grace Hopper Open Source Day.  As part of our partnership with National Organizations Active in Disaster (NVOAD), we recently conducted an ODF virtual test with the NYC VOAD and an exercise with the CDC and San Mateo County Health System.

During the NYC VOAD virtual test in March, we got valuable feedback from participants that included representatives from TeamRubicon, The Salvation Army, and NY Disaster Interfaith Services.  One of the core feature requests that will be integrated for future milestones is to enable organization-based check-ins so that entities with their own structured resource deployment processes can register their capabilities and resources without complications that may come from each individual representative having to register.  Participants also provided input on design and approaches to visualizing the data, which is particularly challenging because of temporal, location-based, and dynamic nature of the data set, but it is a critical element achieving the goal of providing the response community with visibility in to the types and location of their peer resources.

Earlier this month, the CDC and San Mateo County Health System conducted “Silver Dragon X”, a full scale exercise to increase public health and safety readiness to respond to a health-related emergency.  The exercise tested fire departments and community volunteer response teams to conduct door-to-door inspections and deliver key information in the community within a designated period of time.  As part of the exercise, CrisisCheckin was tested at two field locations.  Users provided detailed feedback on usability, the mobile form entry experience, and priority data types.  Users also experienced a common disaster scenario challenge during the exercise: limited or no connectivity on mobile devices.  Enabling asynchronous data capture is a key capability for activities that involve field data capture and a central database.  Capability enhancements and bug reports are being integrated to the CrisisCheckin issues list for the next sprint.

To date, we have 76 contributors provide 839 commits and close out 114 issues.  Thanks you all who have contributed so far!  There are still plenty of opportunities to participate in this project.  If you are interested in helping us build a valuable and easy to use tool for disaster responders, check out the project overview and issues list on GitHub and sign-up to volunteer!

-Harmony Mabrey

Humanitarian Toolbox Core Team Member

 

How to Host a Hackathon

Monday, April 18, 2016

Introduction

Are you interested in the work that goes into hackathons, or perhaps just curious to see the work that goes into Humanitarian Toolbox? This blog post is the beginning in a weekly series of topics relevant to Humanitarian Toolbox and the work that goes into it. Each week our team will be supplying a new entry on the different conflicts and challenges that come from our tech charity, and will give you a better look of how our events come together. 

Our first topic on hackathons aims to collect and share all that our team has learned so far from planning and executing a successful coding event. Every event we take what we’ve learned and use it to improve our scheduling and planning, with success. Each new event sees improvements in areas like building more software, constructing more features, and gaining more satisfaction from our volunteers.  Ultimately, we aim to improve as we learn more from each later event.

Early Planning

While we can move fast, ideally, we should start planning for an event 3 months prior to the dates. We can provide more leeway in those cases where the event is for a private company, and we will have more support and we will need to do less of the demand generation for volunteers.

All of these actions should be completed by 30 days before the event:

  1. Estimate the attendance for the event. As the size of the event grows, we will need more features or applications for volunteers to work on. We want to maximize the amount of work that gets done, and that means minimizing the integration issues between feature or application teams.
  2. Pick the app / project that will be the focus of the event. Depending on the expected attendance, we may work with more than one application. When we have multiple applications, we may want to consider a ‘primary’ and a ‘secondary’ focus. That depends on the size of the estimated attendees, and whether a member of the requesting organization can and will attend.
  3. Secure the venue. This may be a checkbox item for those events that are hosted by a corporate partner, or are co-located with a conference.
  4. Secure food and other logistics. Other logistics include internet access, building security protocols, lodging, travel.
  5. Recruit volunteers. It’s important to remember that we need volunteers outside of developers. Our most successful events have had help with the logistics, scrum master, UX design, and most importantly, domain experts from the requesting organizations.
  6. Build (or update) the project backlog. This will be done with the HTBox coordinators to manage expectations around customer rollout. There are several sub-tasks associated with this task to ensure that our developers are as productive as possible:
    1. Review the existing issues and update the priorities.
    2. Label existing issues. Pay special attention to the “Jump In” tag. Also, update based on “bug” or “feature” tags.
    3. Add any new requirements in cooperation with the requesting organization.
    4. Define a milestone for the event.
    5. Assign issues to that milestone. These can also be subdivided for P1, P2, and P3 goals. A successful event should be able to manage all the P1 issues even if the attendance drops. Stretch goals could be P2 and P3 issues for the milestone.
  7. Define initial milestones. By 30 days before the event, our most engaged volunteers should be able to begin working on some of the features. This task also has a number of sub-tasks:
  8. Clean up stale milestones. Often earlier events may have left some unfinished tasks in the existing milestones. These can confuse volunteers: Some volunteers assume they should work on these issues; others assume those issues should be dropped.
  9. Define milestones for before and during the hackathon event. We should define weekly scrum milestones leading up to the event.  These should include tasks for onboarding volunteers (fork the repository, clone and build the code), and simple tasks to help developers become familiar with the project (scoped bug fixes).
  10. Assign issues to the milestones. This is the first pass assignment and will likely be refined each scrum. Historically, we have had higher velocity during the event than before. However, there may be advantages to defining slightly aggressive milestones leading up to the event in order to encourage work.

March to Event

Starting one month before the live event, we want to start building momentum. The purpose of building this momentum is to make the in-person event a “sprint to the finish” rather than a launch event.

  1. Assist with onboarding volunteers. This has generally meant teaching .NET developers about Git, GitHub, Github Desktop, and the Fork / Pull Request model. We have also had to help developers learn how to pull upstream changes into their local fork. Pro tip: Just explain the fork / pull model. Experience has said no on asks until they’ve made days of work on a local cloned copy only to find that they do not have commit privileges.
  2. Stress the automated unit tests. It has really helped volunteers have confidence. They can make changes and run the existing unit tests to feel confident that they haven’t introduced regression bugs. I’d like to start from a position that we won’t merge a PR without new tests, but that may not be practical. The carrot is that we will help them create the tests.
  3. Encourage feature teams to open their pull request early. We can comment on the code as they are working. It can help us ensure that we can avoid work going in the wrong direction. Tag that PR with the ‘WIP’ tag. (It stands for ‘Work in Progress’). That tells reviewers to comment, but not merge the PR.
  4. Schedule online standups / scrum meetings. We should touch base with the volunteers each week during this period. We can answer questions, encourage more involvement, and create a sense of community. HT Box project leads will also attend these meetings. Have also experimented with recording the weekly meetings each week.
  5. Refine milestones after each mini-sprint. During each online meeting (or offline afterward), the HTBox principals should update the board for the next sprint. This may include reprioritization (with the requesting organization), and pulling issues into or out of milestone sprints. 
  6. Setup a schedule to review and merge pull requests. Volunteers are giving us their time, and the sooner we respond to their pull requests, the ‘stickier’ those volunteers become. We do all have busy schedules, but we need to ensure that we can respond to a pull request within 24 hours or so. (Note that for really large PRs the review may take longer. When that happens, the reviewer should add a comment that they’ve started the review.)
  7. Setup slack channel. We’ve all used Slack with different organizations. We’ve all had positive experiences. We’ve found this is a good way to get volunteers communicating with each other.

Finally, right before the event, we need to define the final milestone and update the backlog with the issues we want to complete during the event.

At the Event

The event is the key momentum builder. We want all the participants to have a great time, and feel that their time was well spent. Here are the keys we’ve found so far:

  1. Welcome and ice breaker. Get people talking as soon a possible when they arrive. We’ve never done a formal ice breaker activity, and we believe the developers would not respond well, but we need to do what we can to get teams to gel quickly.
  2. Get permission to use pictures and names from volunteers. (See next section).
  3. Introduce the ‘customer’. This has had two very good effects. First, developers know who can answer feature questions. Second, and more importantly, it puts a face on the problem and the work. It’s been energizing for the volunteers. When the customer is not there in person, schedule a skype call at the event start.
  4. Take some B roll shots that can be used later in PR activities. Where applicable, get a short interview from the customer and some volunteers.
  5. Continuously manage pull requests. The HTBox core team will be spending their time reviewing and merging pull requests. This activity will grow as time goes on. By the end of the event, we’ll be spending all our time merging and updating the core repository. As the pull requests start coming more quickly, we will need to make sure people re-base their pull requests so that merges are easier. (You did explain rebase when you introduced git, right?)
  6. Recognize team members. We need to be the cheerleaders during the event. I suppose we could go too far with recognizing volunteers, but we haven’t seen any evidence of this yet.
  7. Remember to mark issues as closed (If the PR doesn’t properly identify the issue or work item.) Communicate progress toward the milestone.
  8. Consider recruiting a project leader. We can’t scale if we are the only possible project leads. One of the HTBox principals should be always involved, but when we can identify potential leaders, we can scale.

Post Event

After the event we want to capitalize on the event. We want to capitalize in two ways. First, we want to keep the volunteers engaged after the event. Second, we need to publicize what happened and grow awareness of what we did.

  1. Review the issues list. The end of the event is the end of another sprint. We need to groom the board just like we do for other sprints.
  2. Define new milestones. We want the existing volunteers to stay engaged. We need to define the next milestones.
  3. Assign issues and tasks to milestones. This will give the volunteers guidance on what to work on as they stay engaged.
  4. Write Blog post. This is the first public announcement. We need to publicize our success. Make sure to highlight many of the volunteers. (See previous section for permission). Add the photos or videos from the B roll. It needs to go live within 3 days of the event.
  5. Press Outreach. After the blog post has been written, we should create the short press release and announce what we’ve done, in the markets where the event occurred, and the home market for the app’s test deployment. This can refer to the blog post for more details.
  6. Encourage continued involvement. Immediately after the board is filled, we can continue to engage volunteers online and encourage more involvement. If we have identified a potential project lead, we can help engage that person to transition the day to day project leadership.
  7. Work with requesting organization to encourage a (test) deployment. Assuming we’ve met our goal, we should push for a deployment that can create a second press story, and a chance to reach out to those volunteers that have helped to show how their work has been used.

 

Conclusion

While this is the sum of our knowledge from the hackathons that we have hosted so far, we strive with each hackathon to improve upon our guide.  We’ll revisit this document after each in-person event in order to share and expand on our body of knowledge and to use as a resource for the future. 

-Bill Wagner

Humanitarian Toolbox President

allReady: Update on "Go Live" Plans & Thank You

Friday, April 15, 2016

Thank You!

allReady started as an aspirational vision to harness the energy and generosity of volunteers to “put disaster response out of work” by helping every community and family be prepared and ready to reduce and avoid the impact of disasters big and small.

That vision - coupled with support and contributions from the initial jumpstart with Microsoft’s Developer Division, to code-a-thons at multiple technology conferences and technology companies to individuals from around the world – has become a thriving, actively developed open source solution that’s nearing “going live” to support its first major preparedness campaign.

We want to thank everyone of you who has supported the project with code, time, expertise, support and visibility.  Without you allReady would still be a sketch on a whiteboard and not about to support of an important campaign to keep families safe in their homes.

allReady to “Go Live” in June

As announced during our recent Standup on March 19th, we have identified our next major milestone for the allReady project to “Go Live” and help a community be prepared in a big way. The Northwest Region of the American Red Cross (we’ll call it the Seattle Region for reference below) will be holding a large preparedness event in their territory on Saturday, June 11. Per Regional Preparedness Manager, Allison DeDonato:

“This event will be a preparedness education expo in partnership with Puget Sound Energy (PSE), the primary energy provider in the Seattle area. The Red Cross, along with local Fire Departments and community partners, will come together to promote community preparedness and accept reservation requests for smoke alarm installations. There will be four event locations, each a Lowe’s (hardware) store. Three locations will be in King County, WA and one will be in Snohomish County, WA.

We have held two similar events in the past with PSE that each generated an attendance of approximately 5,000 people. This is what we are expecting for this event too. Our goal is to get a minimum of 25% of the attendees (1,250) signed up for a (free) smoke alarm installation.”

This is great opportunity to showcase a year’s worth of work by demonstrating how impactful a volunteer-built application can be. Equally meaningful, we’ll be bringing allReady back to where it all began as a gesture of thanks to Microsoft contributions and support.

allReady will not be expected to take appointment reservations. Instead, the Region will use another open source web application called getasmokealarm.org (GitHub Repository). getasmokealarm will be set-up at public-facing kiosks in all four stores. In addition, attendees can make requests by SMS by texting alarm to 844-811-0100 (feel free to try it while it’s in demo mode - the feature will go live on or about April 15).

So, what is expected of allReady?

  1. allReady must be able to accept the request data generated by getasmokealarm via API.
  2. allReady should feature the Seattle Region campaign and provide access to getasmokealarm from its home page and campaign pages.
  3. allReady must be able to register volunteers who want to assist with installations. While the Seattle Region expects 1,250 installation requests, it is safe to assume that some attendees and, perhaps some Lowe’s employees, will want to volunteer to assist the campaign.
  4. allReady must be able to construct and schedule installation itineraries and assign them to registered volunteers. Once the June 11 event ends, that’s when the real work begins: satisfying more than 1,000 requests. Typically, up to three smoke alarms are installed per home. That means the Region may need to install as many as 4,000 alarms in 6-8 weeks. The itinerary workflow is discussed in the Standup video and detailed in the whiteboard images.
  5. allReady must also be able to create single-day, “rally” events in which a geographic area is selected for canvassing by 20-50 volunteer teams.
  6. allReady must be able to provide a dashboard-like view of the campaign’s progress. Possible items for inclusion could be a quantitative display and map showing pending and satisfied requests, average installations per day and top volunteers.

During the Standup it was emphasized that UX design will become a priority as we move toward this milestone. Upon viewing the video of the Standup, Allison replied to Jim:

“The direction that the team is taking the project is pretty much the ideal situation for us. To be honest, I couldn’t think of anything that needed to be added to the conversation. I especially appreciated the focus on the “requesters” and volunteers. Since you are a Red Crosser, I am sure you understand that consumer and volunteer experiences are the most important aspects of any project we are working on.”

Finally, while Seattle will be the first beneficiary of our work, a number of states & regions of the Red Cross will be eager to get their hands on allReady including Idaho, Montana, North and South Dakota, Nebraska, Kansas Minnesota, Iowa, Missouri, Wisconsin, Illinois and Maine. That’s a lot of impact we can have together.

How You Can Help allReady Go Live

If you live in cold environs like us, June may seem a long way away. Yet, the Seattle event is just 2 months from now. Tony Surma and James Chambers are leading the ongoing posting & managing of tasks and contributions in our repository at GitHub in the “June Go Live” milestones.  There you can see the prioritization of the needed features and bug fixes to go live.  Besides directly contributing code, you can also help by reaching out to engage additional contributors to accelerate development and grow the focus on UX and testing.

 

Thank for all your continued good work.  We’re allReady excited for June!

- Jim McGowan & Tony Surma

Jim McGowan is the Director of Planning and Situational Awareness for the American Red Cross, North Central Division headquartered in Chicago.

‚ÄčTony Surma is co-founder of Humanitarian Toolbox.

Update on allReady Development at Microsoft Connect(); //2015

Wednesday, November 18, 2015

See the latest on the allReady project and the Microsoft technologies it's built with in the "In the Code 2" video series which is part of Microsoft's Connect(); //2015 Conference this week. 

Humanitarian Toolbox and ThatConference 2015

Thursday, September 24, 2015

With the wrap-up of ThatConference 2015, Humanitarian Toolbox is pleased to announce that the collaboration codeathon between ThatConference and Humanitarian Toolbox has been an overwhelming success in the development of applications for the Red Cross and National Organizations Active in Disaster (NVOAD).

Over the weekend preceding ThatConference, 22 attendees volunteered their time to help build software for two Humanitarian Toolbox apps: AllReady and Crisis Check-in.

AllReady, an app that connects volunteers certified to install smoke detectors with homes that require smoke detector installation, was initially developed by Microsoft at the Visual Studio 2015 launch event. At ThatConference 2015, development on AllReady continued with the support of our Red Cross subject matter expert, Jim McGowan, who assisted in providing advice on the features that would be useful for app users.

Crisis Checkin, a “first responder’s phone book” was developed to make it easier for coordinators and leaders at disaster sites to manage and deploy people to more effectively provide relief to those affected. We’re currently enhancing the application to enable organizations to check in physical resources, like blankets, bucket trucks, potable water and so on. Crisis Checkin’s development at ThatConference 2015 was supported by our NVOAD representative, James McGowen, who also helped in refining application requirements and offered advice on useful features and options for their staff and volunteers.

The productivity of the ThatConference codeathon on the development of these apps can be seen from their results. After an intensive two day codeathon, our team of volunteers implement 11 features across both Crisis Checkin and AllReady. Along with this, there were over 100 commits to implement those features.  We had four accepted open pull requests that volunteers were carrying forward and will represent in new features shortly.

This is the third year that Humanitarian Toolbox has hosted this codeathon as a collaboration with ThatConference, and it’s always been a productive event. We would like to thank the principal organizers, Clark Sell along with Keith Burnell for their hard work in the organization and planning of this event. We would also like to thank all the volunteers and their hard work in turning this event into such a success.

Bill Wagner, Humanitarian Toolbox President, on the event:
“We’re thrilled with the support and generosity of the community of developers at ThatConference. They have consistently turned out to help us build software for Humanitarian Toolbox. More lives are saved because of their dedication, hard work, and professional skills.”

Thank you! 

Your HTBox Team

allReady project launched at Visual Studio 2015 release event

Monday, July 20, 2015

As part of the Visual Studio 2015 release event on July 20th, 2015 our newest project "allReady" was launched.

allReady is focused on increasing awareness, efficiency and impact of preparedness campaigns as they are delivered by humanitarian and disaster response organizations in local communities.  As preparedness and resiliency of a community increases, the potential for impactful disasters (both large and small) is greatly decreased.  The rule of thumb in the industry is that an hour or dollar spent before a disaster is worth 15-30 afterwards.

However preparedness activities, like ensuring working smoke detectors are in homes, are often not as visible or emotionally salient as saving children from a burning building - for example.  The goal of allReady - in part - is to grow awareness and engagement of communities and volunteers in preparedness campaigns to grow their impact and - aspirationally - "put disaster response out of business" through communities that are fully prepared and resilient to inevitable disasters.

To learn more about the need for allReady, the technologies, and how the app came together, please view our Project Page, the readme file on our GitHub repository and watch the In the Code video series.

The genesis for this application and the need it fulfills came from our team working with a number of members of community and humanitarian organizations including Jim McGowan of the American Red Cross who we would like to thank for supporting our efforts and the efforts of the teams at Microsoft as a subject matter expert, the provider of the aspiration to "put disaster response out of business" and a great collaborater in the early and often messy stages of starting a new application.

Lastly, we're thankful for Microsoft and their many engineering teams that came together to jumpstart the development of the project as part of the Visual Studio 2015 release event and then turn over the project to us so that it can be maintained and improved by the technical community at large and ultimately deployed in support of organizations delivering preparedness campaigns everywhere.  They have given the app a great start and strong delivery of a 'first sprint of many' that sets us and the community up to build the project going forward.

To stay up to date on the project or to sign up to contribute to allReady please fill out our quick sign up form.

What is Humanitarian Toolbox?

Monday, June 1, 2015

We updated our About section to include Our Vision for what Humanitarian Toolbox is and strives to be.  You can read it below:

Humanitarian Toolbox (HTBox) is a charity supporting disaster relief organizations with open source software and services.  We are developers, designers, testers, and industry professionals who want to contribute our unique skills in disaster relief aid. Whether it is through creating apps that map the spread of disease or maintaining software that helps to optimize the delivery of relief supplies, Humanitarian Toolbox has a goal of creating software and programs for relief organizations to have ready in times of need.

What makes HTBox unique is our focus on sustainability through the use of Open Source software. Developers want to give to charity using their skills – building software. But how do you build the right thing for the right folks? HTBox deals with the requirements gathering part of the process so that developers can concentrate on development. And it’s not only for developers – there are lots of skills needed to build software beyond development.

Open Source lifts barriers for contributors and users of software, making it an ideal choice volunteer developers looking to make a difference and the organizations they need to help.  Anybody can access the software built by HTBox, whether they want to contribute to it or just take it out for a spin. Our repositories are publicly available on GitHub at https://github.com/htbox

The projects that HTBox is primarily involved with are those benefiting disaster relief organizations.  Some projects are developed from scratch, working closely with the organizations' leaders to build something unique. HTBox gathers the requirements for these project from the relief organizations, break them down into work items in GitHub and then runs code-a-thons and test-a-thons to get the software written with the help of our volunteers as well as continues to engage volunteers online via our repositories.

Other projects are build from software dveloped within a humanitarian organization during a crisis.  When the crisis is over, often the people involved in creating it move on or the software languishes on the shelf. Instead of deteriorating, HTBox takes on these projects so they can be maintained and ready for future usage.

Because much of the custom software used in disaster relief becomes outdated or is not maintained after its initial use, HTBox focuses on sustainability, applying professional software processes on the various projects to keep them current and always improving. There are many contributors to HTBox projects that work on their own time weekly, picking up work items from the repository and contributing new code. As the software is always maintained and improving, organizations are able to leverage the solutions from HTBox whenever new disasters strike.

For volunteers who want to start contributing to HTBox, we recommend signing up so that we can keep you up to date with the latest. Also you can head over to GitHub and take a look at our projects. If there are any items that you think you want to do, go for it! You’ll find work items marked “Jump In”, which means we’re looking for someone to get developing on it.

Our volunteer base is not limited to developers! It takes a lot of different skills to build great software, and we're always on the lookout for all skillsets including but not limited to designers, testers, requirements and project leaders.  Together the impact of our solutions is greatest when together we have the greatest diversity of contributors and volunteers supporting them.

Lastly, if you're interested in donating to HTBox, we are a registered 501(c)3 charity and thankful for any donations you can make to support out mission to help those in need through open source software.

TechWell Supporting Humanitarian Toolbox

Thursday, February 5, 2015

Everyone at Humanitarian Toolbox (HTBox) is grateful to TechWell Conferences for their generous support. We've written before that they have helped test our code by holding a two-day Test-a-thon during their conferences for testing and quality assurance professionals.

In 2015, they will continue to support HTBox by holding Test-a-thons at both STAREAST in Orlando and STARWEST in Anaheim. The work performed at these events greatly increases the quality of the software we produce and ultimately will help the users of our software.

TechWell recently increased their support to HTBox by donating $50 of each conference registration they received during the month of December 2014—$2,000 in total. It's been a fantastic show of support from an organization that is already donating time and space during their learning events. Most importantly, this will aid in our 2015 disaster relief efforts.

We couldn't be happier for TechWell’s support and we hope to see you at one of their upcoming testing events this year.

 

ThatConference Codeathon recap

Tuesday, August 26, 2014

We are back from ThatConference after hosting another successful codeathon. I'm always thrilled to see the participation we get from our friends in the upper midwest. A couple dozen developers gave up their entire weekend to write code for Humanitarian Toolbox on the Saturday and Sunday before ThatConference. 

I also must thank Falafel Software for their generous sponsorship that enabled us to host the event again. We greatly appreciate the support.

We worked on two different applications while there: Crisis Checkin and the Humanitarian Data Bus.

Crisis Checkin

We spent two days working on the mobile applications for Crisis Checkin, using the Xamarin toolkit.We had a UX designer at the event, so we made the most of the opportunity. At the end of the two days, we now have UI screens for all the major interactions on all the major mobile platforms. We have an API design for the server side code, and we're ready to start implementing the WebAPI services.

Humanitarian Data Bus

The Humanitarian Data Bus is a new project. The purpose of this application is to provide a common interchange mechanism for disaster relief organizations. There's a large amount of data that different organizations collect during recovery and rebuild. This application will enable those different organizations to share that data. It will mean that everyone involved has better information, and therefore makes better decisions during the recovery and rebuild operations. 

The overall architecture was created, and the initial shell of the application was coded. It's had a strong kick start, and we'll be getting that code on our github page soon. When it appears, we'll be ready for more work and more pull requests.

 

Again, I want to thank our hosts at ThatConference. They did a wonderful job to make our codeathon a success. They provided space, food, and got the word out to interested developers. We couldn't have done it without your support.

Crisis Checkin Application approaching Beta

Tuesday, March 18, 2014

I'm very excited with the progress we've made in the crisis checkin application in the last year. A gropu of volunteers, donating their own time, built the first version of the web-based crisis checkin application.

We're ready to start having disaster organizations start working with the application and give us feedback. 

This is a great milestone for us. We've built our first app, and we're putting real bits in front of the people that respond to disaster events. All of you that have spent time on the application have helped us reach this important goal. There's more that we need to do. The beta is just the first time that disaster workers will use the app. We'll get feedback and address it. We'll be ready to launch more apps.We've had a lot of support from partners, disaster experts,developers, sponsor organizations, and other volunteers. Thank you!

If you want to pitch in, please join us.

You can read more in our news section.

Salt Lake City Hackathon recap

Tuesday, January 28, 2014

Last weekend, we were in Salt Lake City for a Humanitarian Toolbox hackathon, sponsored by our great friends at Pluralsight. We spent our time working on the crisis checkin application. 

Salt Lake City has a great developer community. I was impressed with the turnout, the skills, and the progress we made.

Everyone had the app installed and running on their machine by mid-morning. The team helped us find and diagnose some challenges for new contributors. We've updated the getting started page on the project wiki, and it should be easier for new developers to join in.

After that, the group formed four different feature teams. We added quite a few features:

  • We created a new Cluster Coordinator role. This is an important milestone for our partners in relief organizations.
  • We created the ability for an administrator or cluster coordinator to email all volunteers that are present on a given day.
  • We added a feature test project and framework. We also created some tests for the main scenarios.
  • We made lots of progress on Xamarin based mobile apps for iOS and Android
  • We made lots of progress on a WIndows phone mobile app.
  • We made significant progress on upgrading to ASP.NET MVC version 5. This will make it much easier for us to integrate OAuth into the application, and enable volunteers to register using facebook or linked in.

Richard Campbell and I had a great time with everyone. It was great to spend some time developing with old friends that we've known from conferences over the years. It was equally great to meet new friends and spend time developing our application.

Most of all, I'm thrilled that the folks who attended have continued to work on the application after the event. I've been receiving pull requests from several of the attendees that wanted to finish features they were working on at the end of day.

Thanks again to Pluralsight for helping us organize the event, feeding all of us, and having some of their development team join us and drive our application forward.

Agile Development East Test-a-Thon

Friday, December 6, 2013

A couple weeks ago, I was at Boston for Agile Development East, along with Microsoft people for a Visual Studio 2013 Launch Event. While there, we hosted another volunteer hackathon for the Humanitarian Toolbox.

I continue to be happy with the response we're getting.  Agile Development East is a testing and project management conference, although it's growing a more developer centered audience.  We had a great response from all those communities. Some project managers approached us about running projects for us. We had testers spend some time on the apps doing exploratory testing.  Our release is getting closer.  They found a few, but far fewer than at the earlier StarWest event.

We had a number of new developers approach us and talk to us about contributing. That's helping us get these first applications ready for use by humanitarian organizations. 

We also had a few community leaders from the Boston community approach us about running projects.  We've got enough of a backlog to do that. We've also learned enough that we're getting close to scaling Humanitarian Toolbox out to local community groups worldwide.  We've learned quite a bit about keeping ongoing development happening after our in person events. To be fair, we've made some mistakes, but we have learned from them.  We're getting more organized, and we're growing the skills to run these distributed projects that are moved forward in volunteer efforts.

I also recorded a new .NET Rocks show, talking about Humanitarian Toolbox, and the new support for Typescript in Visual Studio 2013.

StarWest Test-a-thon

Tuesday, October 22, 2013

Two weeks ago we had the opportunity to work with the dedicated Testing professionals at StarWest. The organizers invited us to bring some of our in-progress apps to a test-a-thon. Conference attendees gave their time to work through the scenarios we've completed and give us feedback.

This was our first chance to have a set of testing professionals do a thorough round of exploratory testing. Unlike all our testing to date that has been developer-authored unit tests and integration tests, the StarWest volunteers brought a different perspective, that of a testing professional.

They found many issues, they gave us several enhancement requests by approaching the app from a different perspective and suggested some new workflows. We'll take those new suggestions to our subject matter experts and see what they think. They also spent quite a bit of time doing negative testing, trying to exploit areas of the app to do things that shouldn't be allowed. Sometimes they were probing for authorization errors, sometimes probing for data exploits.

We feel good about where we are because the list is manageable given that this was the first time anyone had probed the app. Most of the items represent new features, not broken features, and there are only a small set of security issues. Overall, the test professionals made a great contribution to the application. They have given us a set of issues and a set of enhancement ideas that will make the final application much better. It's a strong and important contribution.

Many thanks to StarWest attendees, to the TechWell team for all of their support and to Microsoft for sponsoring the Humanitarian Toolbox at Star West. We should also mention the efforts by volunteers from Neusdesic who participted in the testathon for the duration. It was a worthwhile and valuable experience; we will definitely do this again.

Thanks to everyone at the Grace Hopper Open Source Day

Wednesday, October 9, 2013

We want to recognize and thank the attendees of the Grace Hopper Open Source Day who supported our project this last Saturday for the awe inspiring amount of focus and dedication they gave to building out mobile clients for our Crisis Checkin solution.

As David Washington summarizes in his blog post, the attendees built common data model specs, user scenario documents and starter apps for iOS, Android and Windows Phone.  3 apps in 6 hours!

The team far exceeded our expectations and we look forward to how these will be carried forward and in the future deployed for use by response organizations in the field.  You can see the results yourself (as well as contribute if you like) at the project repository on github - https://github.com/HTBox/crisischeckin.

 

Thanks again to those who were part of Grace Hopper Open Source day and to David Washington for representing the Humanitarian Toolbox at the event!

Hackathon at the Grace Hopper Conference

Sunday, October 6, 2013

We at the Humanitarian Toolbox are thrilled to participate in the Grace Hopper Conference Open Source Hackathon Day.  We’ll have a team adding mobile support to the crisis checkin app. I’m really excited about this for several reasons. I can’t be at the event, but David Washington will be on site and acting as the project lead.  He’s done a fantastic job already by organizing the volunteers and making sure that everyone that attends will be able to contribute as soon as they arrive.

Based on early registrations, we’ll have up to 20 people or more participating.  We’re hoping to get a great kick start on the three main mobile platforms we want to support (iPhone, Android, Windows Phone).  This is great because it adds a lot of diversity to our application. In addition to the web, we’ll have native mobile support for our users.  I also like the symbolism of adding platform diversity for the crisis checkin app at the Grace Hopper Conference. The Grace Hopper conference celebrates women in computing, and we’ve had a low percentage of women joining our Humanitarian Toolbox hackathons so far. We want to have more participation, and the Grace Hopper conference is a great way to start.

I’m also thrilled that there’s at least 20 people signed up. That’s a great crowd, and a great group to add features to the crisis checkin app. I’d love to see everyone that helps this weekend continue to stay involved.

Have fun this weekend, and know that we appreciate everyone’s involvement.

-Bill Wagner

New website live at www.htbox.org

Sunday, September 1, 2013

We're live with our new website today at http://www.htbox.org rebuilt on a new platform with a new visual design and support for mobile access.

Started at the hackathon at That Conference, the new website is built upon N2CMS, an ASP.Net MVC based content management system, that allows us to keep the content up to date and build new features with less development effort.  Some of the upcoming new features for the website including listings for projects, contributors and response organization requests as well as a full featured blog with rss feeds and syndication of blogs from project leads onto our website.

We've moved to the new address at www.htbox.org which we will use for all links and materials going forward as www.humanitariantoolbox.net was always a spelling challenge - even for those of us who typed it a lot!

Just like the projects in the toolbox, our website is being developed openly and the source can be found at http://github.com/htbox/htbox-website.  If you see something that isn't working or have ideas for new features please add an issue to the repository and we will prioritize it for development - or of course you could help us build it if you like as well!

Introducing the Humanitarian Toolbox

Saturday, December 8, 2012

Today we at NetHope, CrisisCommons and GeeksWithoutBounds are proud to announce, in partnership with Microsoft and DotNetRocks the launch of the Humanitarian Toolbox.

The Humanitarian Toolbox is an initiative intended to help bring the expertise and good will of the software development community to the humanitarian world. Ever since the devastating images of the East Asia Tsunami in 2004, developers around the world have helped humanitarian organizations address some of the most complex problems through the power of technology.

Over the past few years, this effort has culminated in the organization of hackathons and code camps that focus on working on problem statements defined by humanitarian organizations. Those of us from the humanitarian community have seen the potential these efforts hold, but sadly often these efforts have not been sustainable and little happens in-between the hackathon weekends.  One of the main reasons for this has been a lack of infrastructure to coordinate these efforts, which often are distributed around the world.

This is the reason we have teamed up with Microsoft, which has generously offered their Team Foundation Services as the infrastructure backbone for the Humanitarian Toolbox. By being able to break the problem statements into individual chunks of work and to clearly define each of them through storyboards, larger problems can now be addressed by this volunteer community of software developers. By having an infrastructure that also enables distributed software development also means that people can continue to work on problems even after they participate in a hackathon.

We are therefore reaching out to the broad software development community, looking for developers, designers, testers, database administrators, project managers, scrum masters and UX masters who want to give some of their time to share their expertise in software development to create solutions that will help save lives and reduce suffering. It is your chance to leave a footprint on this earth and a legacy of good.

We from the humanitarian community are very excited to bring some of our complex problems and get you to help us solve them leveraging your valuable software development expertise. Visit our website, sign up to be notified when new problems get defined, follow us on Twitter and help us bring the humanitarian community into the information age.