5,705
edits
Changes
Jump to navigation
Jump to search
Best Collaboration Practices (view source)
Revision as of 14:12, 31 October 2010
, 14:12, 31 October 2010Created page with "{{Draft}} 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 experi..."
{{Draft}}
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.
== Introduction ==
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.
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.
== Introduction ==
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.