wiki:BluePrint/Sunflower

Version 27 (modified by somayjain, 11 years ago) ( diff )

--

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.

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

<Outline the requirements here> <Group requirements in subsections, e.g. functional, non-functional, interoperability etc.>

Data

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

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.

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...)

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

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

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

Homepage

https://docs.google.com/drawings/d/1Qx5ZVP7CuKoJ1Q-7RUVPRrJ0yzXm0U4Wg9tZvvxN-a8/pub 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?

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

<Leave open for a list of implementation>

References


BluePrint

Note: See TracWiki for help on using the wiki.