The way we develop Storm (and other projects as well, for that matter) allows people to start contributing fairly easily. Here is an overview on the procedure so that anyone interested can jump in and contribute more closely (patches are still welcome), or at least understand what's going on in certain situations (e.g. when you see review or review requests flying somewhere).

Right now, there is a limited number of people with direct write access to the central 'trunk' branch (i.e., members of the Storm team in Launchpad):

There are no upfront constraints about getting people into that list, being just a matter of interest and track record.

On the other hand, there's little benefit in being in that list, since Storm uses Bazaar for version control, which allows anyone to push branches which will even be seen associated with the Storm project at Launchpad (without any human intervention), and that's pretty much what interested developers have to do to get non-trivial features merged (including the core developers, of course).

So, to illustrate how the process of developing a feature and doing code reviews works, let's say that Jolson wants to contribute a new backend to make Storm "communicate" with DBF files. Here's a possible story about that,

• Jolson gets excited about a new file format he's just discovered: DBF.
• Jolson creates a local branch based on Storm's trunk, using the following command:

  bzr branch https://launchpad.net/storm dbf-support

This will create a local branch named "dbf-support".

• After that, Jolson starts hacking wildly into the branch,

using TDD to make sure that all changes are properly tested, and committing often to create a good track of what's going on.

• Excellent. Jolson is happy. He has the feature he wants, and life is a joy. Time to publish his branch:

  bzr push lp:~jolson/storm/dbf-support

To do that, the only thing Jolson needs is an account in Launchpad and an SSH key registered, which he has. This command will associate the branch with his user in Launchpad, and with the project.

• Jolson goes to https://bugs.launchpad.net/storm, and files a new bug: "Storm is nothing without DBF", explaining to whoever reads the ticket how DBF support is a life-critical feature in Storm.

• Finally, Jolson associates the branch he developed with the bug just opened by clicking on "Add branch" in the left navigation tab of the bug page.
• Now he clicks "Edit Descriptions / Tags" and adds the "review" tag to the ticket.
• At this point Jolson is mostly done, except for one thing: non-trivial features are reviewed by two other developers before being merged on the trunk. So Michel and Jamu grab the branch, and look carefully about what was done. They point out some very minor problems and, understanding how important the feature is for Storm, they approve the branch otherwise.
• Jolson fixes the minor points mentioned, and push the branch to the same place with the latest changes, adding a comment afterwards to let everyone know that the branch is available.
• Kevin grabs the branch, and merges into trunk.
• Profit!

That's basically it. There are variations on details, of course. We're not *too* rigid about where the review happens, for instance (sometimes via mail, or interactively on more tricky issues), but we do try to follow more or less the same logic for every change.

For details on getting started with development, see StartingDevelopment