BluePrint: Sunflower

Introduction

Sunflower is a template that will be used by the Sahana Software Foundation (SSF) as a community management and coordination tool. It's development started during the Sahanathon in 2012.

Stakeholders

• The Sahana Community - Since this is a community management and coordination tool, it is a means for the community to see what everyone is interested/is working on.
• People using Sahana Eden - They will be able to report a problem/seek assistance regarding Sahana Eden.
• Organisations for fundraising - It will be a tool to give stats about the work going on in Sahana Eden which would be useful in getting funds.
• Deployments - Information about how and where is Sahana Eden being used.

Goals

• To publish information about all Sahana deployments
• To allow for better task management across deployments & projects (eg GSoC)
• To give the Sahana Community an opportunity to ​Eat our own dog food
• To help us keep better track of who's in our community and what they are working on
• To provide a solution that other digital humanitarian groups can use for their own coordination platform

Description

Sahana Sunflower will help the Sahana Software Foundation manage information about:

• projects
• deployments
• volunteers
• opportunities
  • grants
  • proposals
• organizations
  • peers
  • beneficiaries
• contacts
• tasks (potentially including bugs/feature requests)

It will also be used to promote our work to the general public. One potential use is to generate iframes with deployment information and maps that can be embedded in the SSF website.

User Stories

• Volunteers will use Sunflower to manage community tasks so that they know what needs to be done.
• Newcomers to the Sahana Community will use Sahana Sunflower to find out what they can do to contribute to Sahana Software Foundation projects.
• People interested in Sahana software will use Sunflower to find out how Sahana software is used by different organizations around the world.
• Active deployments can use Sunflower as a destination for posting tasks related to their specific project.
• SSF contributors can use Sunflower to track the status of internal projects, update directories or contacts and organizations, and log information about opportunities for grants and jobs.
• Users can view news feeds from peer organizations and thought leaders.
• User Organizations would maintain an up to date profile (contacts, details about deployment), etc.
• The SSF Community would use it as a directory of the SSF community’s individual contact information, affiliations and locations, as well as information they have about contacts they believe would like to be reached out to by the SSF community in the event of a disaster in their local community.
• It would also serve the community as a directory of organizations and groups that engage in remote, crowdsourced information management volunteering such as the OSM Humanitarian team and other organizations that are relevant for global, technology focused disaster management solutions.

Requirements

Non-Functional

Data

Data models for Sunflower objects can be found here: ​https://docs.google.com/a/sarapisfoundation.org/spreadsheet/ccc?key=0ArhSktWsQi1VdE5lQncyYWNESUxsdXdDYUI3ZEg1dEE&usp=sharing

Metrics

Sunflower should be able to produce the

• Number of active (tasks, emails to list, wiki updates, trunk commits) contributors
  • Daily Active
  • Weekly Active
  • Monthly Active
  • Yearly Active

Functional

Personal Profiles

A personal profile should record:

• Name
• Country
• Projects/Deployments worked on + role
• Github Repo
• IRC Handle
• LinkedIn Profile
• Tasks Logged
• Tasks Resolved
• Comments
• Links to trunk contributors
• Links to messages on mailing list
• Irc Messages in Channel?()
• Wiki updates
• What access people have (Sunflower Admin, Mailing List Admin, Has CI Server Access, Facebook, Twitter...)
• What groups/teams people belong to (eg. Board, GSoC Mentors, GCI Student...)

Subscription

• A person who is subscribed to a task/project/organisation/etc receives notifications via email about it.
• The updates can be for new records or updates in the records.
• The frequency of the updates can be
  • Immediately
  • Hourly
  • Daily
  • Weekly
  • Never
• These notifications also show on the SSF homepage when the person is logged in.
• The notification settings are editable. These settings are -
  • Tasks/projects/organisations/etc for which updates are required. (The filter for notifications)
  • The frequency of updates as mentioned above.
  • The mode of notifications (email/no email)

Task Management

• Review Permissions
• Subscription of tasks -
  • Using teams -
    • Tasks can be assigned to some team (Eg - "A-team" for automated testing team).
    • All people that belong to this team are subscribed to receive updates about these tasks.
    • The people can update their subscription, filtering the tasks and frequency of updates.
  • Marking as "I'm Interested"
    • A person can mark himself/herself as interested in the task.
    • All the people interested in the task are visible to all, so that one may wish to contact any of them for exchanging ideas, etc.
    • All the people interested get updates of the task using the subscriptions.

• Settings to have new tasks automatically assigned to specific teams.
• Different types of tasks - Bug Reports / Help Tickets
• Manage workflow of Help Ticket -> Bug Report
• Filter lists for different users
• Make it simpler to log bugs
  • http://eden.sahanafoundation.org/ticket/1307
  • Less fields / progressibely show fields (easier to log for people)
  • No login required - but allow user to specify who’s login it in a field
  • Add a default link to log a bug in Sunflower - which copies the current URL to the “Source” field
  • Log a bug when an error is encountered
  • If not already logged for this bug

Points

There have been suggestions that we determine a way in which to recognise top contributors - one way of doing this would be to give people "Points" (Sunflower seeds?) for completing tasks. This could work something like:

• All contributors can vote on the number of points a task is worth (0-5). The value of the task is the average of those votes. If there are no votes, a task gets 1 point.
  • Tasks are often assigned value by the person who creates them. I think that's a good way to establish not just their difficulty but also their priority level. Additionally, it would be nice if the person who completes the task also indicates the amount of time they put into that task. Both factors could be recorded to create more useful information about community contributors and their contributions.
• When a task is completed, the contributors that the task is assigned to gets the average value of their votes (although their own vote is ignored)
• On the homepage the top contributors based on points accumulated over the past month are displayed
• We can also keep historic point talleys over time
  • I think it's useful to think about the types of rewards that could be offered to people with lots of points.
  • I also think this would be a good reason to incorporaespeciallyte badges into EDEN, specifically ​http://openbadges.org/ which could be used as a reward mechanism as well as a way to share information about people's skills and experiences.

Use-Cases

• View a list of Sahana Volunteers
• Show a Volunteer Profile page with a list of the tasks that they have completed
• View a list of tasks needing to be done for Sahana
• View a map/table/chart of Sahana Deployments
• Log a task that needs to be done in Sahana
• View a list of internal Sahana contacts.
• View a list of peer organizations.
• View a list of opportunities (grants, jobs, etc) and their status.
• Get notifications on new/edited tasks & projects
• Be able to control the notifications you receive by task & project (all tasks for a specific project). Automatically be subscribed to your own tasks & projects and those assigned to you.
• ...?

Design

User Interface

• Use a bootstrap theme
• Use datalists (​http://demo.drm.tl/eden/default/index/newsfeed) and summary pages (​http://demo.lacrmt.sahanafoundation.org/eden/stats/people/summary) to present data

Homepage

​Edit

• "News" could be implemented in a couple of different ways:
  • Using custom code to pull data together from Projects, Deployments & Events (MH: My choice)
  • Use a dedicated data-model just for news (would require updating)
  • Use the update functionality (as on the CRMT homepage)
    • Syndicating news feeds from specific organizations RSS feeds, which is how news comes into the NYCPrepared EDEN.
• Register as Contributors would disappear when logged in
• You could toggle between contributors & deployment layers on the map
• You could toggle between all tasks & tasks for beginners
• Do we want to switch the boxs for tasks & news?

Deployments Page

Image{https://docs.google.com/drawings/d/1qDEE1gyWDFT3ixKSSe_gKR5-BJn_GgoWEN2X5jHd8-o/pub?w=960&h=720) ​Edit

Contributors

Summary page of Contributors (probably use the "Volunteer" data model - would volunteer be a better term?):

• Datalist showing Contributors + photos
• Map of Contributors
• Chart of Contributors per country

Also include:

• Picture (when they register?)
• Bio
• What groups/teams they belong to (PMC, Board, Interns, GSoC Students 2013)

Deployments

Summary page of deployments (could these be a filtered type of project?)

• Datalist
• Chart
• Map

Projects

These would be things like GSOC projects & other internal projects (Communication Strategy, Blog Update, etc). Summary page:

• Datalist
• Chart
• Map

Tasks

Summary page:

• Datalist
• Chart

Events

Summary page:

• Datalist
• Chart
• Map
• Calendars

Organisations

Does it make sense having a list or all organisations here? Or just partners? Summary page:

• Datalist
• Chart
• Map

Report a Bug

Users

Public

All users will be able to do the following (whether or not they are logged in):

• View All Information (Without registering)
• Add a Task / Bug Report (Without registering)
• Create and edit their own profile (This will require registration - but not approval)

Contributors

Any person who has registered in and had their account approved by an admin will be able to edit:

• All Projects
• All Tasks
• Their own profile information

NOTE: If the public are able to register and create their own profile, then there will need to be another process for them to request to become contributors, then admin can grant them the contributor Role

Peer Organisation

Any person who has registered as a part of an organization and had their account approved by an admin from the organisation will be able to edit:

• All Projects
• All Tasks
• Their own Profile Information
• Their Organisation Profile

Admin

Admins will be able to do everything (including deployments)

Implementation

Current Implementation

• The current implementation is a template built on top of Sahana Eden.
• Currently, it supports the following -
  • Contributors - Using the hrm module.
  • Tasks Lists - Using the project_task table, where a task can be assigned to just one person.
  • Deployments - Using the project_project table, filtered by sector name as "Deployment".
  • Projects - Using the project_project table, filtered by sector name as "Project".
  • Disaster Organisations - Using the org module.
• The current implementation can be found in the trunk at private/templates/SSF ​here.

Planned Implementation

• Goals for my(Name : Somay Jain, ​Github Repo, IRC : Somay) implementation as a proposal for GSoC'14 -
  • Personal Profile
    • Including a pr_person_details table to include the details in the profile for the user, which will be linked to pr_person.
  • Subscriptions
    • Using Subscriptions to give updates to the user via the mode selected and on the the homepage.
  • Task Management
    • Include visibility of everyone who is subscribed to the task, possibly with another tasks to subscribed users table.
  • Homepage, Views -
    • Using Bootstrap to customize views.
    • Information from multiple modules on the homepage - Eg : tasks, updates, newsfeed, contributors/deployments map, etc.
    • Will define custom layouts and controllers for each module.
  • Metrics of contributions -
    • Include trunk commits URLs.
    • Include tasks logged/resolved.
    • Include links of wiki pages edited.
    • These metrics will have to be entered manually by the user as part of building his/her profile.
  • Pages for each module -
    • Use summary pages and datalists for each module mentioned above.

Future Extensions

• Metrics - Making the metrics being automatically updated
  • Emails links on the list.
  • Trunk commits URLs
  • Tasks logged URLs
  • Tasks resolved URLs
  • Links of wiki pages edited.

• Diff viewer -
  • Include a diff viewer on the task page to display the patch(if any) added as an attachment.
  • The viewer should be able to support inline comments, preferably like Github viewer does.

References

• Subscriptions and Notifications
• Layouts and Menus
• Themes

---

BluePrint