Difference between revisions of "Collab mockup"
Line 17: | Line 17: | ||
** sugar still has lack of critical mass of participants who contribute on regular bases thus coordination of development efforts is a critical point and we need to track and schedule such efforts in more formal(then posting emails to sugar-devel@ for example) manner<br>e.g. every core team member will all time know what other members are working on and what the progress of current tasks | ** sugar still has lack of critical mass of participants who contribute on regular bases thus coordination of development efforts is a critical point and we need to track and schedule such efforts in more formal(then posting emails to sugar-devel@ for example) manner<br>e.g. every core team member will all time know what other members are working on and what the progress of current tasks | ||
** groupware brings benefits for other developers as well<br>if some developer doesn't have enough time to implement request he was working on, he can just expose it via UI(in comparing with sending email to sugar-delvel@ which could not be fair every time) and coordinator/requester/other-developers can track such events | ** groupware brings benefits for other developers as well<br>if some developer doesn't have enough time to implement request he was working on, he can just expose it via UI(in comparing with sending email to sugar-delvel@ which could not be fair every time) and coordinator/requester/other-developers can track such events | ||
+ | ** tracking what contributors do has also social aspect - any sugar user can see how much particular contributor does for sugar community thus encourage people do more | ||
* Place like collab.sugarlabs.org could be the first point where interested in contributing/requesting people can go. It could the right place to have database of all sugar contributors and having sustainability features like donate buttons per contributor. | * Place like collab.sugarlabs.org could be the first point where interested in contributing/requesting people can go. It could the right place to have database of all sugar contributors and having sustainability features like donate buttons per contributor. |
Revision as of 11:05, 6 January 2010
![]() |
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. Site also could be lightweight and only contain groupware component and links to other resources like wiki or track.
All mentioned below purposes could be implemented fully or partially on collab.sugarlabs.org.
Purposes
- Let any casual user request a feature using convenient and friendly tool
existed model still works but either not so friendly to non-technical users(like track) or too common(like wiki and mailing lists)
- Mix in groupware component to sugar development model keeping in mind its casual and decentralized nature
- sugar still has lack of critical mass of participants who contribute on regular bases thus coordination of development efforts is a critical point and we need to track and schedule such efforts in more formal(then posting emails to sugar-devel@ for example) manner
e.g. every core team member will all time know what other members are working on and what the progress of current tasks - groupware brings benefits for other developers as well
if some developer doesn't have enough time to implement request he was working on, he can just expose it via UI(in comparing with sending email to sugar-delvel@ which could not be fair every time) and coordinator/requester/other-developers can track such events - tracking what contributors do has also social aspect - any sugar user can see how much particular contributor does for sugar community thus encourage people do more
- sugar still has lack of critical mass of participants who contribute on regular bases thus coordination of development efforts is a critical point and we need to track and schedule such efforts in more formal(then posting emails to sugar-devel@ for example) manner
- Place like collab.sugarlabs.org could be the first point where interested in contributing/requesting people can go. It could the right place to have database of all sugar contributors and having sustainability features like donate buttons per contributor.
Implementation ideas
The major idea of this proposal is having several modes. Every mode will provide only useful components for particular audience. For example requesters mode should be friendly as much as possible for newcomers and especially for non-technical newcomers and full featured groupware for experienced contributors.
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