Brian Fitzpatrick remembers, “In order to really expand beyond the small group of people that CollabNet was paying to work on [Subversion] we needed to find a way to be inclusive of other people.” The Subversion team started their transition by identifying and removing every team practice which contributed to second class citizens. They established a set of rules for the team to make sure it became an open team and stayed that way.
Make All Decisions Publicly
When Jim, Karl, Brian, and Ben talked they made decisions about the project. Often without realizing it. There was just a general feeling that the four of them made a quorum. Ben said, “we thought it was silly to have ‘trivial’ dialog on the mailing list.” They tried it anyway and they immediately “started attracting some unbelievable volunteer developers.”
No Phone Calls
Karl Fogel:
“All conversation should be held in a public forum by default.”
The team continued to have personal conversations, but they don’t make decisions about Subversion. Phone calls are a very useful way of communicating with individuals. They aren’t very useful for communicating with teams. The core team didn’t stop talking with each other; they just stopped making decisions without the rest of the group.
Use the Tools Well
Karl Fogel:
“Use the tools and the metadata in the way that they are meant to be used.”
Another part of creating a useful body of information for the team is making sure everything has useful metadata. This particularly applies to using threads well on the Subversion mailing lists.
The Subversion team uses their mailing list as a discussion forum. Patches are submitted, problems are addressed, and features are discussed. From the start they enforced the use of threads for these discussions. Every mailing list post was grouped by subject.
Don’t Repeat a Conversation, Link To It
Karl Fogel:
“Don’t say something unless you have something new to say.”
Making major decisions on the email list created an archive, but the Subversion team wanted to make sure that archive remained useful over time. To make this possible the Subversion team created a strict rule to reference information rather than repeat it. If something had already been discussed by the team they didn’t want to repeat the discussion. By consolidating their information the Subversion team created an environment that fostered open collaboration.
No Code Owners
Many teams use an owner or an author comment on source code files to establish who has responsibility for that file. The Subversion team forbids them. Karl explains, “If you put a name at the top it makes other people feel like they have to ask permission before they make changes in that file.”