5,705
edits
Changes
Jump to navigation
Jump to search
Line 94:
Line 94: − + − − As the last [[#Organizational|premise]] says, the major idea is not creating concrete vertical organizational structures for Sugar ecosystem but giving [[#Core_Team|fruitful ideas]] and [[#Doer's_environment|useful instruments]] to Sugar [[#Sugar_universe|doers]] to let them gain an [[#Common|experience and knowledge]] during the process of implementation, and [[#Sugar_distribution|spreading]] the results within Sugar community. − − Line 108:
Line 104: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
User:Alsroot/Sugar Architecture (view source)
Revision as of 13:36, 31 October 2010
, 13:36, 31 October 2010no edit summary
Most of them are being developed and supported by individuals (mostly activities), the rest are using management model which is most useful for them. All of them are self organized structures and have their own release schedules and roadmaps, though [[#Tracked_projects|tracked project]] work in close interaction with the Platform Team.
Most of them are being developed and supported by individuals (mostly activities), the rest are using management model which is most useful for them. All of them are self organized structures and have their own release schedules and roadmaps, though [[#Tracked_projects|tracked project]] work in close interaction with the Platform Team.
== The whole picture ==
=== Questions ===
== Questions ==
'''To designers'''
'''To designers'''
* Should Platform Team be a home team for distributors instead of Deployment Team?
* Should Platform Team be a home team for distributors instead of Deployment Team?
* Should incremental Sugar distribution releases of the same LTS release contain new users visible features?
* Should incremental Sugar distribution releases of the same LTS release contain new users visible features?
== The whole picture ==
As the last [[#Organizational|premise]] says, the major idea is not creating concrete vertical organizational structures for Sugar ecosystem but giving [[#Core_Team|fruitful ideas]] and [[#Doer's_environment|useful instruments]] to Sugar [[#Sugar_universe|doers]] to let them gain an [[#Common|experience and knowledge]] during the process of implementation, and [[#Sugar_distribution|spreading]] the results within Sugar community.
== Best Collaboration Practices ==
Initially, this text was based on [http://wiki.meego.com/Proposal_for_Best_Practices_for_working_in_a_MeeGo_team MeeGo community's practice]. Please, share your experience.
In the following, Sugar Labs Teams, groups of people who are working together on a Sugar [[#Sugar_universe|project]] or particular [[Features]], are shorted to ''team''.
While most of this is obvious to people who have been working 'in the open' before, this is a list of Do and Don'ts to help teams to work in the open and for a standard for teams to be held against. Some teams may be exempted from these best practices, an example could be security teams, etc.
The primary idea is that everything (common sense limiting) should be publically available so that everyone can be an equal participant in the process, limited only by their personal skills, time and resources.
=== Communication ===
''Do's:''
Have your team communication be:
* on a dedicated meego.com mailing list (archived, listed), and/or on forums.meego.com
* or on a IRC channel or Jabber MUC chat room (logged, listed, publically accessible and except for good reason, non-moderated)
* This encourages participation by outsiders and transparency in the team work.
* In English except if your team purpose is specific to a certain language/location.
Have your team meetings be at, in order of preference, best to worst:
* Nowhere! Don't have one! It is very difficult to get people across many timezones together, so take this into consideration when making a meeting agenda
* IRC meetings in #sugar-meeting on irc.freenode.net, logged and managed by the IRC meeting bot, and announced with agenda publicly at least 48 hours in advance.
* A physical location with public minutes, ideally recorded and publically downloadable, preferably during a conference with a large number of Sugar community members in attendance, or in a co-ordinated hackfest or summit.
'''Don'ts:'''
Have your team communication be:
* on private mailing lists - this discourages participation by non-team members
* without minutes or public record - it makes decisions of the past difficult to locate and understand for others
=== Membership ===
''Do's:''
* Have your team pick up new members based on merit - it encourages good work and motivates non-team members to contribute and prove their skill.
* Ensure that your team is structured in a way to allow evaluation of merit - make public patch review standard practice, have your team do review publicly on a mailing list, and encourage discussion and feedback.
''Don'ts:''
* Have your new members be chosen alone on affiliation with a company - it ties your team to a certain company and discourages participation by non-team members.
* Allow newcomers to be given commit access to the core repository the day they join
* - instead, have newcomers walk the same gauntlet of creating bugs in Trac, submitting patches and undergoing code review which everyone else goes through. Consider it an effective trial period with public review, and an opportunity to grow a mentoring program.
=== Contributions ===
''Do's:''
* Treat non-team member contributions with same processes, reviews and respect as team member contributions.
''Don'ts:''
* Ignore non-team member contributions - this discourages participations by non-members and effectively reduces their ability to prove their skill.