People
Voluntari.ly is setup as a programme under the Pam Fergusson Charitable Trust (PFCT). The core team consists of Andrew Watkins as Product Lead (50%) and Walter Lim as Design Lead (100%). Both joined the team in late January.
The team relies on volunteer effort in the form of developer contributors. These include:
Completed onboarding:
- Anne Bilek
- Jasmine Kamante
Currently onboarding:
- Eteroa Lafaele
- Kayla Allison
- Heba Farooq
In addition we have two University of Auckland students supporting the application as part of their year 4 projects.
- Darcy Cox
- Cyrus Raitava-Kumar
We continue to expand the contributor base.
On 4th May is planned a working bee day at Datacom where we will work with a group of staff taking the project forward – particularly in respect of cloud deployment and allowing volunteers to sign into the application using their corporate credentials.
Later in May we plan with Auckland University a weekend of code that will introduce 40+ masters students to the project.
Our goal is to have 5-10 regular contributors supporting the development over the next few months coupled with bursts of work from hackathons and days of code using a wider group of volunteers.
Processes & Tools
In February an initial technical advisory group met to discuss the options for the software stack to use to build the application. It was agreed to use a common modern stack consisting of MongoDB, Express, React and Node (MERN). This provides us with a single language (javascript) from front to back coupled with a framework supporting a layered pattern of service APIs and Component based web application. All the components are open source and have no licensing costs.
The complete code base is available on Github at https://github.com/voluntarily/vly1
The voluntarily application is open source using the Mozilla Public License 2.0. Being open source is a key requirement for us to make use of volunteer contributors to the project.
In addition as an Open Source project we have been provided with a free license to use Atlassian software tools : Confluence – Documentation Wiki, and JIRA – issue tracking system. These are available at: https://voluntarily.atlassian.net
We now have a basic process for onboarding volunteer developer contributors which includes a brief overview of the project, introduction to the code base and an initial task to accomplish.
The road map, major functions, and individual feature task have been placed into the Jira project. https://voluntarily.atlassian.net/secure/RapidBoard.jspa?rapidView=2&projectKey=VP
Developer documentation, architecture, design, processes etc are all in the wiki https://voluntarily.atlassian.net/wiki/spaces/VP/overview
Our initial test deployment of the product is onto Amazon Web Services (AWS) Elastic Container Service (ECS) using Docker images for the application and Mongo Atlas Cloud Service for the database.
Visual Design and Customer Experience
Consultation on the functionality required and patterns of use started with a Hackfest in Dec 2018 that outlined the core problems we wish to solve, personas for key stakeholders: volunteers, teachers, corporates, agencies etc. Along with a range of use case scenarios. These gave us our outline functional design and requirements list.
Walter has created designs for the way the application will look and work on the screen. These have been tested with likely users to help us improve the operation and flow, language etc.
The design has evolved since in consultation with teachers and others through multiple school meetings. [list?]
[Point to example screen shots.]
Product
The core purpose of the Voluntari.ly is better learning outcomes for young people by bringing adults with expertise to meet schools and teacher's needs through Science, Technololgy, Engineering, Arts and Mathematics (STEAM) activities. However, it is not limited to that.
The current road map for the product leads to an online service that creates relationships between three groups - People requesting help - usually teachers, People offering Activities - content providers, and Volunteers - mainly corporate volunteers.
Activity listings are of things to do - e.g. a day building and launching rockets. While we don't hold the content directly the listing is an index to available content and carries metadata which makes discovery and selection easier: appropriate age range, relevant curriculum subjects, space, equipment required etc.
Requests or opportunity listings are of things that need volunteers or help. for example 'We would like to run the Rocket Day activity at our School in May and need 10 adult volunteers to help, 1 day commitment - no special skills' or "We will be building a programming autonomous model cars and need 5 volunteers. 3 hour commitment, Skills: simple C++, Coding
Requests can be for events - activities taking place at a time/place or over a period requiring people to be present; or for conversations - adult to adult or adult to student calls or emails to help with questions, or needing specific skills e.g. "Our year 12 Engineering project are working on a safety helmet design and have questions about plastics and moulding"
Volunteers can maintain a profile of their skills, their previous volunteering efforts and achievements. They can view available requests, be 'tapped' with requests that they may be able to help with, and can make themselves available to be contacted on various subjects e.g 'I am available for 2 hours a week to give help in creating data visualisations"
Organisations providing volunteer days can be setup in the system so that their staff can sign in directly using their corporate network credentials and request listings pages can be provided as embedded components that can be incorporated into intranet pages. Listings can be filtered to focus request listings on topics or regions favoured by the organisation.
Onboarding processes for volunteers take them through the steps necessary to be ready to work with children of different age groups. This includes police vetting and orientation information about the school experience. Event management processes ensure that volunteers know where to go, remember when they need to be places, handle attendance check-in and/or no-shows even call for backup.
Feedback from all parties is crucial to the effectiveness of the system. Using feedback we can improve the experience of volunteers - so that they want to participate again, of the schools and students - so that they learn more, and of the activities and content products - so that they are more effective and have better learning outcomes.
Minimum Viable Product (MVP)
The MVP is the simplest possible system that can start to be used in the real world. It may not have many features but those that are present work and people can use the system for real outcomes. This is then the starting point for iterations as we learn more about the requirements of the system and the best way for it to operate.
For Voluntari.ly our MVP target contains sufficient features to be able to list a request and have volunteers sign up and volunteer for requests
- Basic Organisation (school & company) creation with profile page
- Person (Teacher/Volunteer) Registration and profile page
- Teacher create request page
- Requests listings page
- Volunteer for a request
- Teacher request management page - lists available volunteers
- Email communications and notifications
- Deployed and operating in cloud at http://Voluntari.ly
- Volunteer admin and school ready process.
Stretch goal is company single sign on support.
Diversity
The Voluntari.ly application has been designed to be multi-lingual from the start. It will launch in English and Māori.
0 Comments