NOTE: This ideas list is under development and will likely be changed up through the official announcement of GSoC projects. Please also visit the Google Summer of Code @ Open Source Center page for other sub-org information and details.
Information about how to contribute and apply to GSoC, please look at our instructions here GSoC and Outreachy applicants, start here! · Discussion #4213 · ushahidi/platform · GitHub.
Potential mentors for all project ideas on this page are available to answer your questions! Connect with us on Chat with general questions, or contact any of the Ushahidi Mentorship Team (subject to change!):
Project 1. Improve performance in the Ushahidi Platform Client
- Is there a way to split up the bundle and only import what is needed for each view or use case. For example, can the code for the settings-view and analysis-view be separated?
- Do we have any unused dependencies? Remove them
- Some of our dependencies are really heavy, can we find replacements that are lighter?
Difficulty level: Intermediate to difficult
Project 2: Ushahidi Platform Voice integration
Currently, the Ushahidi platform supports data collection via SMS, Email, Twitter, and smartphone apps.
Even with these different available alternatives, there are circumstances where reporting is still not feasible or sufficiently convenient. Some individuals may not have the required literacy skills to write their report, or may not be able to operate the necessary devices in order to input data. During a natural disaster, infrastructure may fail, leaving no internet or cellular connectivity working in the area.
A type of data that is currently not being enabled for Ushahidi Platform deployments is voice.
Voice has the advantage of being accessible to individuals regardless of their literacy skills and can be less cumbersome to produce than typing into a device. Also, there have been instances of natural disasters where the only remaining infrastructures were landlines and radios.
- This project’s aims to complete an experimental / proof-of-concept exercise
- The purpose is to explore the idea and possibly try it out with a small controlled group of end-users.
- We suggest (not enforce) receiving the voice data from a voice phone API , such as i.e. Twilio Voice .
- Other alternatives (i.e. based on radio technology) welcome to be mentioned in the application.
- Due to the experimental nature of this project, there is a certain latitude here and we are glad to hear of any specific implementation ideas in your application.
- Rather than re-inventing the wheel with the speech-to-text transcription, it’s expected to interface with one or several of the different speech-to-text services available out there.
- The minimal necessity at this point is for the service to be able to deliver a single message per report to the Ushahidi Platform.
- This is similar to the functionality currently provided by the SMS data source.
- As opposed to the more complex mode of operation, which we refer to as structured data capture. In that case, several messages are to be received from the reporter for each submission, in order to fill a survey form. This would usually require a more sophisticated, conversational (IVR system) approach.
Skills: PHP, systems design, HTTP API
Difficulty level: Difficult
- Github repository: GitHub - ushahidi/platform: Ushahidi Platform API version 3+
- Google Cloud Speech-to-Text service documentation: Speech-to-Text documentation | Cloud Speech-to-Text Documentation
- Amazon Transcribe: Amazon Transcribe – Speech to Text - AWS
- Watson Speech-to-Text: Watson Speech to Text | IBM
- … other Speech-to-Text services
- Twilio Voice API: Twilio Voice API Overview - Twilio