Foreword
This is a proposal for a MeeGo project policy of how best practices of working should be like for MeeGo groups, teams, WGs and appointed groups of people (an example could be architects).
The proposal was brought about due to perceived problems of open development in the project. Instead of pointing fingers and pointing out flaws, a constructive path was taken instead, this proposal. To help to create the vision of a MeeGo project working as described in valhalla's post:
"Yet MeeGo operations are expected and designed to be completely transparent - R&D in the public internet". "Herding the teams to go public will be a big task for Imad, me and others, no doubt. So, this is where we need your help. Please make this happen with us by maintaining constructive dialogue, together finding out the MeeGo way-of-working and being patient and encouraging with newbies not to scare them back inside corporate firewalls"
In the following, team/group/WGs/appointed groups of people is shorted to
'team'. MeeGo project is defined as any direct work going into the open MeeGo project.
Contact person for proposal: Carsten Munk, maemo.org distmaster, Stskeeps on IRC.
Introduction
Imagine a team distributed all over the globe, coming from very different backgrounds, company affiliations, etc. This team picks up new members from the set of people contributing to the part of the MeeGo project the team is responsible for.
Now, imagine how this team would work together and how to make their work easier picking up new members - and encouraging new contributors.
This is how a typical MeeGo team would be like.
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 by public decision by TSG, an example could be security teams, etc. In the following, publically accessible is defined as 'read-only', with write access decided within the team.
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.
Policy scope
The scope of this policy of best practices is any team organised underneath the MeeGo umbrella which works with the public MeeGo project.
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 #meego-meeting on irc.freenode.net, logged and managed by the IRC meeting bot, and announced with agenda publicly at least 48 hours in advance.
- Teleconference with public minutes, ideally recorded and publically downloadable.
- A physical location with public minutes, ideally recorded and publically downloadable, preferably during a conference with a large number of MeeGo 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
- company chatrooms - this discourages participations by people from other companies.
- without minutes or public record - it makes decisions of the past difficult to locate and understand for others
Information sharing
Do's:
Have your team do information sharing through one of more of these tools, not only limited to these public tools:
- For (D)VCS, use meego.gitorious.org
- For wiki, use wiki.meego.com
- For bugtrackers, use bugzilla.meego.com
- For file sharing and repositories, request a sharing area or repository from the meego.com infrastructure team
- For pastebins, use a public one!
Don'ts:
Have your team use:
- non-publically collaboration spaces such as private wikis, private pastebins, private (D)VCS, private file sharing areas, private bugtrackers, private repositories
- - it discourages participation by non-team members, ability to locate information, documentation, source code. It makes your team unable to work together if they are at different companies
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.
- Do talk to your manager if your team is currently working internally only on the MeeGo project and think your team work should be be done in the open.
- 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 new employees to be given commit access to the core repository the day they join
- - instead, have new employees walk the same gauntlet of creating bugs in Bugzilla, submitting patches and undergoing code review which everyone else goes through. If it's hard for external contributors to get commit access, it should be hard for new employees too. 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.
References