In August 2016 a number of SSF community members met in Thailand to discuss various issues related to the SSF. This gathering was funded by the SSF’s Council and the President.

The people who attended were:

• Devin Balkind
• Nuwan Waidyanatha
• Dominic Konig
• Lutz Frommberger
• Biplov Bhandari

We organized a two day “barcamp” style meeting where we brainstormed topics, consolidated them into central themes and then discussed them at length. Notes were taken and, through them, we arrived at action items for the following year. A selection of notes and action items from those meetings are below. Some notes have been removed for the sake of clarity, brevity and privacy.

1. Opportunities

• No specific business opportunities to discuss.
• We’ve been offered organized and facilitated corporate volunteers sourced and managed by Benetech. There is a project they want to use Sahana for related to medical inventory. Devin is currently managing this opportunity.
• We need to expand our board. We had a few ideas.
• Mentorship is Dominic’s prefered model of spreading EDEN.

2. Templates

A good way to explain how EDEN templates work is to think of it as a set of layers:

• Basic System (All systems)
• Functionality (ex. SAMBRO)
• Location (localization)
• Deployment (organization specific)

The reason for this design choice is to reduce the time spent configuring deployments.

We want to develop a “Web Setup” that would enable people to go through a GUI to install templates onto EDEN systems. This would change how we manage our releases. We’d no longer deploy from trunk. We’d have releases and then scripted migrations. This would also require an upgrade interface in the web setup as well.

Our top priority templates for development are:

• Volunteers: Volunteer Management
• Resilience: DRM (Projects) + CRM (Community Resilience Mapping)
• Situational Awareness: 4W

Next set would be:

• Incident Management: SAFIRE
• Inventory Management: Inventory and Requests
• Alerting: SAMBRO

3. SaFiRe

Everyone is excited about the prospect of Sahana EDEN developing a “First Response” set of functionalities. This would enable an EOC to run Sahana EDEN to manage incidents, dispatch units, etc. While there is already a massive amount of proprietary competition in this field (they could be decades ahead of us in terms of sophisticated) their solutions are very expensive and inaccessible to developing world governments. There is no open source solution at this point. We could be that solution.

Some notes on that development:

• Event  – location, type, timeframe, zero hour. Multiple incidents.
  • Incident Reports
  • Situation Reports (from responders)
  • Resources Used
  • Resources Available/Nearby

• Incident – related to event. Multiple reports can be filed under one incident.
• Issue alert
• Units: where they are, what they’re doing, contact info/link, dispatch capability
• Scope
• Dispatch Process
• Hazard and Risk Mapping
• Critical Infrastructure
• Elevation
• Historic Data
• Demographic Data
• Crime and Fire Data

4. Community engagement / community building

• We need to focus on building an implementer community instead of a developer community. Developers will come when there are enough implementers demanding the software.
• We should re-focus the website communications on attracting implementers and providing them documentation and marketing materials. Structure proposed:
  • 100-200 word explanation for how it technically
  • Common uses of the system – templates
    • Scenario Description (What is Incident Management?)
    • Features (screenshots)
    • Implementation Stories
    • What you need to be successful
    • Common workflows
    • Hardware and infrastructure
    • Checklists ?
  • Featured deployments
  • How to implement Sahana (Best practices)
    • Where to get data
    • How to maintain data
    • Which workflows and user roles do you need?
    • Politics of deployments 
  • Offer a contact form with a few questions that generate feedback
  • Offer Support
    • Free One-hour Webinars (collect their info – use Hangouts or Skype)
      • Vendors come up with common standard webinar
      • Presented by service providers (?)
      • Post webinar next steps
    • Mentorship Program
    • Paid Services
      • Guided Demos
      • Virtual Trainings
      • Hosting
      • In-Person Workshops 
      • Startup package to install modules and configure
      • Custom Development
    • Service Providers
• Colloquium Workshops (ex. privacy)
• Newsletter w. topics
  • Technical columns
  • Business columns
  • Organization news
  • Use cases
  • Emergency responses
• Simple interface for Github wiki (just the basics with deep links to wiki)

5. Mentorship Program

A Mentorship program would focus on helping teams implement EDEN effectively for their specific use case. It would involve putting a core developer into the team as an advisor who can give guidance and best practices, but NOT to implement the software themselves. Instead, instructing them how to do it so they can build capacity going forward.

• Describe a “Mentorship Program for Implementers”
  • Build an “online academy”, potentially using an Learning Management System like Moodle.
    • 100 level – Sahana introductory
    • 200 level – Implementation
    • 300 level – development
    • 400 level – projects
  • Develop a set of “Implementation Guidelines” that people can use to improve how they deploy their systems.
  • Develop a Certification (or set of certification/badges) for people with demonstrable skills pertaining to implementing Sahana EDEN systems.
  • Implementing “Web Setup” as has been proposed by SSF members would change the way systems are deployed, so development of the Mentorship Program should take place after Standard Templates and Web Setup are implemented.
  • We need to figure out the logistics of such a program: budget, job descriptions, who could fund it, etc.

Steps/Outcomes

• Starts with an assessment of their needs.
• Discuss with them about their team
• Training implementers for specific deployments – for their specific project
• Facilitate implementation of project. Not leading it. Not project management.
• Direct engagement and participation alongside your team
• Mentor is in the team regularly (weekly), listens to issues and gives advice.
• Their responsible for the system working, we’re responsible for skilling up the team. Workshop outcome is a product delivered by a vendor/provider.

Different types of projects/implementation require different types of mentorships.

• If turn around time in short such as in a disaster response scenario, then an intensive approach is appropriate with daily workshop lead by a mentor.
• If it’s a longer term engagement then weekly meetings between mentors and implementors can be enough. This would be a lot more advice and guidance. Example could be implementing an incident management system over the course of many months.

6. SSF Operations

• Organize and publicize communication channels for SSF
  • We should put together a listserv for implementers
  • There is a Sahana user group is on sourceforge. We should promote new comms channels there and then shut that down.
    • https://sourceforge.net/p/sahana/mailman/
  • We could put together a user list again on Google Groups but need a moderator
  • IRC channels exist but are usually for technology people. They are often empty which is frustrating for people and doesn’t look good for the org/project.
  • The EDEN IRC is good for tech stuff
  • Meetings IRC channel for general discussion
  • We could create a channel for users/implementers
  • If we start promoting IRC channels on the website we should have a schedule to make sure people are on the channels.
• New Meeting Schedule
  • We should establish monthly meetings with open agendas.
  • Good time is 9am EST, 3pm Germany 9pm China
  • Quarterly board meetings (please!!)
• Task: Make sure the board list can receive non-member emails

 

7. CoE (Renamed Sahana Research & Action)

• CoE description is too broad and outdated
• Countries need a lot of handholding to adopt systems.
• Current approach is to get SLAs with governments to support their CAP efforts
• CoE’s focus can be supporting implementation in Asia, with focus in South East Asia.
• A big selling point for CoE is that it has and can build relationships with difficult to reach government agencies such as meteorologists in Myanmar and Emergency Managers in Nepal.
• CoE could be the model for a zone-based support system in which CoEs exist in different regions: Americas, Africa, Asia, etc
• There are shared task that could be part of such a strategy. CoEs could be responsible for:
  • Maintaining the location’s data repository.
  • Localizations support – translation network
  • Regionally appropriate documentation
  • Region contact directories
  • Building a regional disaster response capability within the CoE
  • Building regional awareness of Sahana among local developers
  • Build relationships with academic institutions. They could develop code.
  • Generate leads for local vendors and use local vendors to develop projects that CoE gets funds to implement.
  • CoE shouldn’t be a vendor. It should purchase development services from vendors and/or get code developed within academic institutions.

This concludes the notes from the event. If you’d like complete access to the unabridged notes, please contact us.