Table of Contents
Pre-Award Archive: Sahana Software Foundation GSoC 2013 Ideas Page
Eden Project Ideas
Vesuvius Project Ideas
For an additional overview, and students who have expressed interest, see Vesuvius - Google Summer of Code 2013 Ideas
Native Synchronization between Vesuvius Instances
| Platform | Vesuvius |
| Mentors | |
| Preferred communication | emails, Skype(Chamindra), G+ (Greg) |
| Brief description/Usage Scenario | Instances of Vesuvius (say, in different cities or hospitals) can currently interchange missing/found person data using the PFIF protocol, but that exchange is lossy and requires a Google Person Finder go-between. The proposed task would implement direct lossless two-way interchange. The should be multiple exchange channels to support fault tolerance (e.g. if there is no network or just a USB connection) |
| Skills needed | PHP, SOAP |
| Blueprints | GSoC 2013 - Native Synchronization between Vesuvius Instances |
| Acceptance conditions | Demonstration of exchange of missing person and displaced/shelter person data between Sahana instances. Confirmation that all specified data has been exchanged. Help documentation for a user on the WIKI. Good code quality including well commented code, secure code |
| Other resources |
Portable App Dynamic Creation
| Platform | Vesuvius |
| Mentors | Chamindra de Silva |
| Preferred communication | email, skype |
| Brief description/Usage scenario | Some times it is valuable in the middle of a disaster to get a portable program + data instance of the hosted site to take to disaster zone that might not be connected. However to do this normally you would have to create a new portable version that is the same as the hosted one and then syncronize the data into it. What I propose is the automation of this task from a module in Sahana that compiles a portable instance on the fly to take to the field. This would work with data synchronization instance. This scenario is based on an actual requirement during Hurricane Sandy |
| Skills needed | PHP, MySQL import/export |
| Acceptance conditions | Demonstration of the creation of a dynamic portable application from a site. Proper documentation |
| Blueprints | GSoC 2013 - Portable App Dynamic Creation |
| Other resources | Somewhat-related idea: Data syncronization |
Vesuvius Installer
| Platform | Vesuvius |
| Preferred communication | email, G+ |
| Brief description/Usage scenario | As part of the 2011 GSoC, our student built an installer (using Symfony and YAML) to install the other branch of Sahana ~ Mayon. Part of his work was to also port the installer to Vesuvius. Alas, this part of the project was not completed before the summer ran out. As such, we have the most of the installation process defined, have partially (somewhere between 60-80%) coded the installer, and tested it to some degree. However, there still is work to be done debugging a barrage of error messages from the installer as well as updating the installation procedure to take into account a few additional features we would like the installer to handle in its initial configuration of the Vesuvius environment. |
| Skills needed | PHP, YAML, CSS, MySQL import/export |
| Acceptance conditions | End to End installer that sets up a Vesuvius instance with a properly configured database and an initial set of data. Another requirement is that there must be 0 PHP errors and 0 PHP notices during the process of installation. |
| Blueprints | GSoC 2013 - Vesuvius Installer |
| Other resources |
Demo Instance(s) of Vesuvius
| Platform | Vesuvius |
| Mentors | Ramindu Deshapriya |
| Preferred communication | IRC, G+, Email |
| Brief description | This would be a “kick the tires” instance for the benefit of potential adopters. It would include access as admin, hospital admin, and hospital staff. It would be a limited-lifetime instance that would periodically be rebooted and set to default database contents. A more sophisticated version would provide a separate instance per customer, perhaps with some simple startup customization, e.g., to set the title string to something chosen by the customer. This would be hosted on an SSF site (rather than NLM). |
| Skills needed | PHP, shellscripts/cron jobs |
| Blueprints | GSoC 2013 - Demo Instance(s) of Vesuvius |
| Acceptance conditions | |
| Other resources | Somewhat-related idea: Installer |
| Comments | Chamindra: Can we make this a turnkey Link VM? Louiqa: This seems more like a task not a summer project? Perhaps combine with [another project like the Disaster-Specific Resources Pages]? Glenn: Louiqa, this idea also requires developing the default database contents, maybe with a wizard so that the adopter can select what sort of example content (if any) should be preloaded. Probably needs a guide document or video too. There's some interest in defining less-expansive tasks this year, to get a more complete and polished result rather than a 2/3rds done result. |
Disaster-Specific Resource Pages
| Platform | Vesuvius |
| Mentors | Ramindu Deshapriya, Glenn Pearson |
| Preferred communication | IRC, G+, Email |
| Brief description/Usage scenario | For an instance of Vesuvius that is deployed to support multiple disasters over time: Develop an infrastructure to allow instances of resource pages to be customizable for specific disasters, in association with multiple languages. |
| Skills needed | PHP, MySQL |
| Blueprints | GSoC 2013 - Disaster-Specific Resource Pages |
| Acceptance conditions | |
| Other resources | |
| Comments | Louiqa: Perhaps combine with the previous one? Chamindra: Possibly also the ability to migrate selectable resource data (e.g. hospital locations, staff) between the different disasters |
Expand Options when Setting Hospital Policy
| Platform | Vesuvius |
| Mentors | Glenn Pearson, Ajay Kanduru (SOLR) |
| Preferred communication | TBD |
| Brief description/Usage scenario | Add to the settings that individual hospitals should be able to customize. For example, for hospital triage treatment zones, specify the count and individual zone names and color-codes; this would be exposed in the website UI (e.g., as filters, tied into SOLR search engine) and through web services. You will be expected to unit-test web services. (Subsequently, NLM programmers will incorporate these new services into the mobile apps on various platforms.) |
| Skills needed | PHP, basic SQL; SOLR helpful |
| Blueprints | GSoC 2013 - Expand Options when Setting Hospital Policy |
| Acceptance conditions | |
| Other resources |
Improved Hands-Free Mode & Printing
| Platform | Vesuvius |
| Preferred communication | TBD |
| Brief description/Usage scenario | The non-interactive mode of viewing person-search results on-screen could use further improvements, e.g., to smoothness of scrolling; to ability to print this screen format. |
| Skills needed | Javascript |
| Blueprints | GSoC 2013 - Improved Hands-Free Mode & Printing |
| Other resources | |
| Acceptance conditions | |
| Comments | Louiqa: Looks interesting. Is this a generic capability or are you thinking of many smaller customizations? |
Embeddable Widget
| Platform | Vesuvius |
| Mentors | Glenn Pearson |
| Preferred communication | TBD |
| Brief description/Usage scenario | A “widget” aka “gadget” is a piece of web code that a third-party chooses to embed in their own web site, that occupies a rectangular space on the web page. In concept, a Vesuvius widget would be similar to the Google Person Finder widget, in that it would support reporting someone missing or found, commenting on such a report, or searching. The goal is to create a iFrame widget template, which at deployment could be made specific to a given disaster and Vesuvius instance, and whose content can be controlled (post-deployment) from the Vesuvius host. |
| Skills needed | PHP, HTML, Javascript, CSS |
| Blueprints | GSoC 2013 - Embeddable Widget |
| Acceptance conditions | |
| Other resources |
Simplify ImageStats Code
| Platform | Vesuvius |
| Mentors | Ajay Kanduru |
| Preferred communication | TBD |
| Brief description/Usage scenario | ImageStats is a Java program that extended the PL web site (NLM's version of Vesuvius). it was used in the recent Google Code In to tag skin color samples and facial boundaries from images. While fairly straightforward in concept, ImageStats was quickly built with many dependencies on third party libraries and functions. Now open-source, ImageStats could be redone to make it simpler, more stand-alone, and easier to maintain. |
| Skills needed | Java |
| Blueprints | GSoC 2013 - Simplify ImageStats Code |
| Other resources | |
| Acceptance conditions | |
| Comments |
(Ideas that were listed here but are now dropped due to anticipated support problems:
- “EAP2”: Redo Web Page for Reporting a Missing Person, with Notes
- Expanded User Profile
- SOLR Optimizations and Advanced Search
)
Kilauea Project Ideas
Some information pertaining to Kilauea ideas can be (temporarily?) found on the Vesuvius Ideas page.
Add, Edit, Import Locations and Staff
| Platform | Kilauea |
| Mentors | |
| Preferred communication | IRC #sahana; e-mail to discuss@sahanafoundation.org |
| Brief description/Usage scenario | Breaking dependency between RMP (Mayon) and RP (Kilauea) - currently Kilauea relies on Mayon to provide staff and shelter lists. While this option should remain, we need to make the Registry Program the ability to operate independently. Adding the capabilities to Kilauea/RP to manually add, edit, or import lists of locations and staff/volunteers from other sources. |
| Skills needed | PHP |
| Blueprints | |
| Acceptance conditions | |
| Other resources | |
| Comments |
Create Standalone Version
| Platform | Kilauea |
| Mentors | |
| Preferred communication | IRC #sahana; e-mail to discuss@sahanafoundation.org |
| Brief description/Usage scenario | Creating a fully functional standalone version packaged on a USB stick. Again - the dependency to having a Mayon/RMP generated list of sites and staff preloaded onto the stick needs to be revised and adding capabilities for synchronization with online server. |
| Skills needed | PHP |
| Blueprints | |
| Acceptance conditions | |
| Other resources | |
| Comments |
Mobile Check In / Check Out
| Platform | Kilauea |
| Mentors | |
| Preferred communication | IRC #sahana; e-mail to discuss@sahanafoundation.org |
| Brief description/Usage scenario | Allowing for mobile phone check in at shelters (both staff and the sheltered). Possible additional use of QR codes scanned for check ins and check outs. |
| Skills needed | PHP |
| Blueprints | |
| Acceptance conditions | |
| Other resources | |
| Comments |
Merge Kilauea and Vesuvius Trunks
| Platform | Kilauea / Vesuvius |
| Mentors | Ramindu Deshapriya, Dilantha Silva, Alexandros Katechis |
| Preferred communication | IRC #sahana; e-mail to discuss@sahanafoundation.org |
| Brief description/Usage scenario | Full merging of Vesuvius and Kilauea code bases into single trunk. Deployment settings (like Eden) will determine front-end functionality (missing persons, shelter registration, staff registration, etc.). This would imho greatly broaden the potential user base for both of these products, which otherwise will remain highly customized for a single customer and likely not adopted by other organizations. |
| Skills needed | PHP |
| Blueprints | agasti:vesuvius:gsoc2013:vesuviuskilaueamerge |
| Acceptance conditions | |
| Other resources | |
| Comments |
Template for Project Ideas
Project Idea Title
| Platform | Vesuvius |
| Mentors | [Names of people willing to mentor this project] |
| Preferred communication | [IRC/Nick; e-mail to discuss@, sahana-eden@, Sahana-agasti@; private e-mail to me@domain.com; skype to my.name] |
| Brief description/Usage scenario | [One paragraph narrative description of project and how it matters in a real world use context] |
| Skills needed | [Any specific useful skills or knowledge (other than basics).] |
| Blueprints | [Links to blueprints or detailed descriptions] |
| Acceptance conditions | [Provide conditions for which this project will be accepted as completed[ |
| Other resources | [Links to references, supporting material, relevant standards, partner organizations, examples of use cases…] |
