Collab mockup

NOTICE: This page is a draft in active flux...
Please contribute to these contents and discuss issues on the discussion page.

Preamble

This mockup describes how collab.sugarlabs.org site could behave and doesn't correlate with possible implementations. Particular implementations could be various, reusing existed infrastructure like wiki/track/launchpad, using existed groupware web based software or creating project from scratch.

Workflows

Observer/Populator

every anonymous user can brose requests using criteria like tags, component, user etc.
find out information where particular implemented request could be found(in what sugar release, activity version etc.)
after authorization, logged in user can (de)populate every active request by giving his vote and leaving comments(comment could be inplaced or on external resources like wiki, depends on implementation)

Requester

The major workflow for collab.sugarlabs.org.

login to requester mode
check user groups to participate in e.g. group of users for particular region, school etc.
check if willing request was already created
if yes, just add yourself to requesters list of found entry to increase its weight
if no, create new one
- short description
- full description(could be inplaced or on external resources like wiki, depends on implementation)
- properties like component, willing(could be changed later by coordinator) priority, tags, contribution-types(could be set by experienced coordinator)
- willing deadlines/schedules(could be changed later by coordinator)
- status of newly created request will be new and request will not be visible by default(but visible after explicit willing) for contributors until coordinator accepts it
wait for replies from coordinator or interested contributors, site should provide:
- list of your requests
- convenient notification method of incoming replies

Coordinator

Coordinators are appointed to filter all incoming requests to:

find out duplicates
tweak request properties e.g. if requester is not experienced in some cases
set priority, deadlines and schedules
could appoint/invite contributors

Each group of users should have one or several coordinators. Every subgroup inherits coordinators from parent group e.g. group of school users will inherit area and global coordinators.

Possible workflows:

login to coordinator mode
check incoming queue of newly created requests
accept/retain/deny/tweak new requests
inspect deadlines/schedules of ongoing requests

Contributor

Every request has one or several types of participation:

coding
artwork: icons, images etc
media files: audio and video
creating documentation
translation

Contributors workflowas could be:

login to contributor mode
since it's a separate mode, it could have all features that powerful groupware software has, depends on particular implementation

Data Model

Related resources